遵循 Apple 的指导方针，我为 iPhone 应用程序的每个屏幕创建了一个 UIViewController 子类。然而，我一直发现这些类变得非常大，无论是纯粹的代码行数还是成员变量的数量。
根据定义，它们最终要负责许多不同的问题（例如视图生命周期、视图和模型之间的中介、有时是触摸处理、控制逻辑、管理警报和其他 UI 状态）。
这不仅违反了单一职责原则，而且还导致大量代码几乎不可能进行单元测试。
您倾向于将哪些职责/关注点划分为新的类别？在 UIViewController 子类的情况下，你认为什么样的职责是干净分离的好候选？
这是一个有趣的问题，我也在为如何正确划分责任而苦苦挣扎。这一切都取决于上下文，但由于测试 UIVieController 的子类可能会很痛苦，我尝试尽可能多地移动到模型类中。本着Skinny Controller，Fat Model的精神。
当涉及到表格时，我创建了一个用于处理所有表格视图内容的基本模型类，基本上封装了您在创建新的基于导航的核心数据项目时获得的内容。在控制器中，我只是将调用转发到我的表模型。
我试图使控制器的方法尽可能小。根据上下文，我可能有几个模型类，每个模型类负责一个特定的部分。
我还研究了使用控制器工厂获取某些数据模型的详细控制器的可能性。
UIViewController *detailController = [self.controllerFactory controllerForItem:item];
[self presentModalViewController:detailController animated:YES];
通过这种方式，我可以对特定数据项获得正确的控制器进行单元测试，而无需涉及父控制器。
使用我的，我正在创建类别、抽象父级并使用我在 Java 世界中学到的各种模式来降低复杂性和代码重复。但归根结底，我仍然每个屏幕都有一个视图控制器，因为每个屏幕上至少有一件东西在某种程度上是独一无二的。由于我在控制器周围放置了基础设施，控制器中可能没有太多代码了。