我有一个 UIViewController，随着时间的推移，它添加了很多委托(delegate)事件，这使得 Controller 类变得非常大。 UIViewController 类包含相当多的 View 管理方法，这些方法从事件委托(delegate)方法调用以管理 Controller 正在管理的 UIView。
我现在正在向类中添加更多的 UIActionSheet 委托(delegate)事件。我的 Controller 类越来越大，我想我应该打破 UIActionSheet 委托(delegate)事件并将它们放在一个单独的委托(delegate)类中。然后，这个单独的委托(delegate)类将不得不回调到 View Controller 类中，以使 View Controller 相应地调整 View ，使用 View Controller 中的 View 管理方法。 ( View Controller 访问 View 所代表的单独模型对象)。
我可以看到采用这种突破性方法的利弊。向 Controller 添加越来越多的委托(delegate)事件感觉不对，但是为不同类别的事件创建单独的类然后需要回调到 Controller 似乎也引入了不必要的复杂性和混淆层。大型 Controller 类“简单明了”但感觉不对，而使用大量不同的委托(delegate)类会更加复杂和复杂，但会导致类更小。
谁能提供一些关于这个主题的智慧之言，或许可以为我指出一些关于这个问题的特定 iOS 阅读 Material ？
非常感谢。
最佳答案
我对此事的处理方式是:
- 让它发挥作用
- 让它成为切肉刀
- 回到 1。 (如果您在某个领域有经验，则 1 和 2 都在同一轮)
因此，如果代码工作应用程序看起来不错，但你发现 ups 某些类中有 100 个方法，那么尝试不同的设计模式(如果你还没有)并使用那些切肉刀的想法将代码分离到不同的类，委托(delegate)，必要时将它们封装起来。
http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
以防万一链接到 Cocoa 设计模式建议，我不时研究 Pro objective c design patterns for ios。可能不是最好的书，但它基于 iOS 上下文中的“四人组”设计模式书。
希望这至少在某种程度上有所帮助，
干杯
关于iOS - 处理大型且不断增长的 UIViewController 类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14749167/