使用 UIViewController 维护单一职责原则 (SRP)
遵循 Apple 的准则，我为 iPhone 应用程序的每个屏幕创建一个 UIViewController 子类。然而，我始终发现这些类变得非常大，无论是在代码行数还是成员变量数量方面。
根据定义，它们最终负责许多不同的问题（例如视图生命周期、视图和模型之间的中介、有时触摸处理、控制逻辑、管理警报和其他 UI 状态）。
这不仅违反了单一职责原则，而且还导致大量代码几乎无法进行单元测试。
您倾向于将哪些责任/关注点划分到新的类别中？在 UIViewController 子类的情况下，您认为什么样的职责适合干净分离？
Sticking to Apple's guidelines, I create one subclass of UIViewController per screen of my iPhone application. However I consistently find that these classes become very large, both in terms of sheer lines of code and number of member variables.
By definition they end up being responsible for quite a number of different concerns (e.g. view life cycle, mediating between views and models, sometimes touch handling, control logic, managing alerts and other UI state).
Not only does this violate the Single Responsibility Principle but it also results in large swathes of code which are near impossible to unit test.
What responsibilities/concerns do you tend to divide off into new classes? What kinds of responsibilities do you think make good candidates for clean separation in the case of UIViewController subclasses?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个有趣的问题，我也在努力解决如何正确分离责任的问题。这一切都取决于上下文，但由于测试 UIVieController 的子类可能很痛苦，所以我尝试尽可能多地转移到模型类中。本着瘦控制器，胖模型的精神。
当谈到表时，我创建了一个基本模型类来处理所有表视图内容，基本上封装了创建新的基于导航的核心数据项目时所获得的内容。在控制器中，我只是将调用转发到我的表模型。
我试图使控制器的方法尽可能小。根据上下文，我可能有几个模型类，每个模型类负责一个特定的部分。
我还研究了使用控制器工厂来获取某些数据模型的详细控制器的可能性。
这样我就可以进行单元测试，以确定我是否获得了特定数据项的正确控制器，而无需涉及父控制器。
This is an interesting question and I also struggle on how to properly separate responsibility. It all depends on the context but since testing subclasses of UIVieController can be a pain I try to move as much as I can into model classes. In the spirit of Skinny Controller, Fat Model.
When it comes to tables I have created a base model class for handling all the table view stuff, basically encapsulating what you get when you create a new Navigation Based Core Data project. The in the controller I just forwards the calls to my table model.
I'm trying to keep the methods of the controller as small as possible. Depending on the context I may have several model classes, each responsible for a specific part.
I have also looked into the possibility of using controller factories for getting detail controllers for certain data models.
This way I can unit test that I get the proper controller for a specific data item without having to involve the parent controller.
在我的项目中，我创建类别、抽象父项，并使用我在 Java 世界中学到的各种模式来减少复杂性和代码重复。但归根结底，我仍然每个屏幕都有一个视图控制器，因为每个屏幕上至少有一个在某种程度上是唯一的东西。由于我在控制器周围放置的基础设施，控制器中可能没有留下太多代码。
With mine, I'm creating categories, abstract parents and using a variety of patterns I've learned in the Java world to reduce complexity and code duplication. But when it comes down to it, I still have one view controller per screen because every screen has at least one thing on it thats unique in some way. There just might not be much code left in the controllers thanks to the infrastructure I've placed around them.