使用UIViewControllers维护单一责任原则（SRP）

Question

坚持Apple的指导方针，我在iPhone应用程序的每个屏幕上创建一个UIViewController的子类。但是我始终发现这些类在代码行和成员变量数方面都变得非常大。

根据定义，他们最终要对很多不同的问题负责（例如，查看生命周期，在视图和模型之间进行调解，有时触摸处理，控制逻辑，管理警报和其他UI状态）。

这不仅违反了单一责任原则，而且还导致大量代码几乎无法进行单元测试。

您倾向于将哪些责任/顾虑分成新课程？在UIViewController子类的情况下，您认为哪些职责适合清洁分离？

Answer 1

这是一个有趣的问题，我也在努力如何正确分离责任。这一切都取决于上下文，但由于UIVieController的测试子类可能很痛苦，我尝试尽可能多地移动到模型类中。本着Skinny Controller, Fat Model的精神。

说到表我已经创建了一个基本模型类来处理所有表视图的东西，基本上封装了你在创建一个新的基于导航的核心数据项目时得到的东西。我只是将调用转发给我的表模型。

我试图让控制器的方法尽可能小。根据上下文，我可能有几个模型类，每个模型类负责一个特定的部分。

我还研究了使用控制器工厂获取某些数据模型的详细控制器的可能性。

UIViewController *detailController = [self.controllerFactory controllerForItem:item];
[self presentModalViewController:detailController animated:YES];

通过这种方式，我可以进行单元测试，以获得特定数据项的正确控制器，而无需涉及父控制器。

Answer 2

有了我的，我正在创建类别，抽象父母，并使用我在Java世界中学到的各种模式来降低复杂性和代码重复。但是当它归结为它时，我仍然每个屏幕有一个视图控制器，因为每个屏幕上至少有一个东西，它在某种程度上是独一无二的。由于我放置了基础设施，控制器中可能没有太多代码。