海量父子模式和委托模式答案

【问题标题】：Massive Parent-Child and delegate pattern海量父子模式和委托模式
【发布时间】：2015-09-13 05:06:10
【问题描述】：

我正面临一个复杂的设计问题。由于硬设计的图形，我不能将 Apple 导航模式用作UINavigationController 或其他模式。这是应用图

黑色箭头：协议方向 蓝色箭头：父子模式方向

我创建此流程是因为我想保持单个 ViewController 内的代码清晰和隔离：我认为它们是模块，它们可以在其他应用程序的某个地方使用。 RootViewController 是MainVCs 职位经理。它决定哪个是必须显示的当前视图控制器，并根据其状态（由委托方法修改）对其进行配置。单个MainVC 不知道RootVC 存在，它使用协议调用Root。单个ChildViewController 不知道它的MainVC 存在，它使用协议等调用Main。

代码清晰易懂，这是我的目的，但是当我必须从ChildViewControllerN 对骨架（RootVC）进行修改时，无数个ChildViewController 的孩子，无数个@ 的孩子987654333@，我必须将协议传播到RootViewController。

我的第一个问题是：这种模式正确吗？你怎么看？

我的第二个问题是：是否有一个限制点，我没有使用委托模式，而是使用KVO 之类的东西？

添加我读了一篇关于composite pattern 的大学讲座，上面写着：

复合对象知道其包含的组件，即它的子对象。组件是否应该维护对其父组件的引用？ 取决于应用程序，但拥有这些引用支持责任链模式

所以，根据链，我可以维护父级的引用，但我必须为这种引用声明一个自定义接口。但是，这样做我会减少协议的数量，但是第二个问题仍然没有答案

【问题讨论】：

标签： ios objective-c design-patterns composite delegation

【解决方案1】：

意见：

当我超越单一级别的父/子关系时，我倾向于停止使用委托并转向NSNotification。我经常直接转到NSNotification 以减少依赖关系。我更喜欢 KVO，因为它是显式的，而随着项目的进展，KVO 更难调试。

（示例：如果在分配时刻和 KVO 交付之间在主线程上解除分配侦听器，那么后台线程上看似简单的变量分配会导致难以诊断的崩溃。）

【讨论】：

NSNotification 是一个选择，但我不喜欢它，因为观察者可以将自己移除为 keyPath 的观察者。我不会，我认为possible 接收者总是必须接收消息。我还认为，也许父母不会总是将子消息传播给它的 superparent。
无论你使用什么方法，如果接收者尝试，总能找到忽略消息的方法。不需要在单个对象之间传播；每个观察者独立注册。