这样设计是否合理的问题
Closed this issue · 4 comments
曾经也碰到过类似的问题, 我采用的是递归来操作，**和你差不多，但是我遇到过问题，你在这里好像也会出现
假如有这两条路径:
Root.A.a1
Root.B.b1
我现在需要新增一个需求，功能f1， 我要放在A里面，那么现在路径变为
Root.A.a1
Root.A.f1
Root.B.b1
此时运行时完美的，但是，此时会出现这么一个问题
如果产品需要把f1 放到 B里面去
而且，而且，而且
如果用户在 Root.A 里面 如果用户曾经点击过此功能, 那么就不B就没有badge,如果没有，就需要显示
理想路径变为:
Root.A.a1
Root.B.f1
Root.B.b1
但是如何计算 A & B 的badge
A = a1 + f1???
B = b1 + f1???
f1到底如何计算？？？
你说的这个问题，我是这么理解的:
Root.A.f1的父路径为Root.A
Root.B.f1的父路径为Root.B
所以:
Root.A的badge = Root.A.a1 + Root.A.f1
Root.B的badge = Root.B.b1 + Root.B.f1
这边需要注意的是不要把路径拆开来看，f1不是路径，因此不能说f1是A的子路径。应该是这么看待的:
Root.A.f1是Root.A的子路径
显然，在这个理解下
Root.A.f1不是Root.B的子路径
Root.B.f1才是Root.B的子路径
Root.A.f1和Root.B.f1是两个互相独立或者说互不相关的路径。
在RJBadgeKit框架下，可以这样解决你的问题:
- observePath:@“Root.A.f1”
- statusForKeyPath:@“Root.A.f1”判断状态决定是否要观察新设路径“Root.B.f1”（假设这边需要，转第3步）
- unobservePath:@“Root.A.f1”
- observePath:@“Root.B.f1”
不知道我的理解对不对，欢迎继续讨论～～
感谢回复讨论
你这总做法，的确可以，
但是对于 Root.B.f1 来说，其状态就变得不那么纯粹了；
随着不断的迭代，开发以及维护成本都会变得很高很高；
其实我个人有个想法就是，按照没个功能来 “组合”，类似于树的概念来处理，那么对于某个节点来说，只要identifier 唯一，那么无论怎么变换都可以；
欢迎继续讨论
我是希望有清晰的路径导向，每个业务的入口正常情况下不应该出现交叉，这个是我为什么选择root.xx.xx格式的原因，这个格式下看路径就能知道它的父路径以及从属关系。
你提到的想法我之前也有考虑过，就是每一个节点作为一个路径，比如A为一个路径，然后a1和f1它的子路径, 注册的时候可以NSDictionary的格式:
A-{a1, f1}
B-{b1, f1}
如果触发了f1则A和B同时收到通知
其实，这两种方案的实质区别是父路径和子路径的对应关系，我的想法是：
一个父路径可以对应多个子路径 -> 1父:N子
一个子路径只能对应一个父路径 -> 1子:1父
就像subView一样，一个view可以有多个子view，但是一个子view只能有一个父view
你的方案其实是1子:N父或者说N父:N子的关系，这种方式确实自由度更高，但是关系会容易乱，维护起来也复杂，所以相比较而言我还是更倾向于独立清晰的路径导向。
你说的这个case是会有某个场景下大量用到吗，因为我这边没有遇到你说的那种场景，所以我的思维可能局限在这边了，欢迎继续交流指正～～
其实各有利弊，使用场景也多吧， 在以前开发阶段，遇到的场景还比较多