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