一个有争议的委托式事件通知模式

Question

我留下了继续高级开发人员的代码，在那里我遇到了一个不仅奇怪的编码模式，而且让我对很多事情感到好奇。然而，我所谈到的模式有这样的：

1. 有一个UIViewController视图作为子视图附加了一个扩展UIView的实例。
2. 此自定义UIView类引用了上述UIViewController。
3. UIViewController中定义了一系列负责处理UIView事件的方法。
4. 由于此UIViewController作为参考存在，我们的自定义视图会通过此引用调用这些事件处理方法！

在这样的代码系统中，内存含义是什么？这与委托模式有何不同？在什么情况下使用这种编码好吗？

Answer 1

虽然这种模式有点好奇，但我会毫不犹豫地谴责这一点，而没有更多关于这个子视图正在做什么以及它需要通知视图控制器的信息。诚然，这里有一个微弱的代码味道，如果我冒险猜测，我敢打赌，这个视图很可能会做一些现在通常放在视图控制器中的东西。

通常，在添加具有任何显着复杂性（或可能在不同视图中重用）的子视图时，可以考虑iOS 5功能“视图控制器包含”（请参阅​​“{3}}部分 View Controller Programming Guide 或WWDC 2011 video Creating Custom Container View Controllers）。

如果使用故事板，您可以使用iOS 6中引入的特殊“容器视图”控件实现大部分功能，该控件位于Interface Builder的“对象库”（位于标准Xcode布局右侧面板的底部）中。如果以编程方式执行此操作，只需确保调用Implementing UIViewController Containment中“管理自定义容器中的子视图控制器”部分中列出的相应方法。

使用视图控制器包含时，您具有父视图控制器（主视图控制器）和子视图控制器（管理子视图的视图控制器）。在这种情况下，设计自定义协议非常常见，通过该协议，子视图控制器通知其父视图控制器特定事件。但是，您可以使用内置的delegate属性，而不是添加自己的自定义parentViewController属性，当您采用上述“视图控制器包含”模式时，该属性会自动填充。

说完所有这些之后，我可能会让实际问题驱动现有的代码库是否需要重构。也许代码早于iOS 5，但它是我们在当天可能做的事情的可靠实现。如果它起作用的话，底线写得很好，并且明确界定了责任的划分，你可能决定单独留下足够好的东西。如果它有点含糊不清（因为没有讨论UIViewController Class Reference可能会提示），也许只需在子视图和视图控制器之间引入一个正式的协议来使接口显式化。是否需要对代码进行更激进的重构（使用视图控制器包含等内容），我们很难根据目前提供的有限信息提供建议。