使用UIViewController保持单一职责原则(SRP)的方法

3
遵循苹果的指南,我为我的iPhone应用程序的每个屏幕创建一个UIViewController的子类。然而,我发现这些类变得非常大,无论是在代码行数还是成员变量数量方面。
根据定义,它们最终需要负责许多不同的事情(例如视图生命周期、在视图和模型之间进行调节、有时触摸处理、控制逻辑、管理警报和其他UI状态)。
这不仅违反了单一责任原则,而且还导致大量的代码几乎不可能进行单元测试。
您会将哪些职责/问题分配到新的类中?在UIViewController子类的情况下,您认为哪些职责是良好分离的好候选项?
2个回答

1

这是一个有趣的问题,我也在努力寻找如何正确地分离责任。这完全取决于上下文,但由于测试UIVieController的子类可能很麻烦,我尽量将尽可能多的内容移动到模型类中。这是Skinny Controller, Fat Model的精神。

当涉及到表格时,我创建了一个基本的模型类来处理所有的表视图内容,基本上封装了创建新的导航基础Core Data项目时所得到的内容。然后在控制器中,我只需将调用转发到我的表模型即可。

我试图尽可能地保持控制器方法的简洁性。根据上下文,我可能会有几个模型类,每个类负责特定的部分。

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

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

这样我就可以进行单元测试,以确保获取特定数据项的正确控制器,而无需涉及父控制器。


0

在我的项目中,我正在创建类别、抽象父级并使用我在Java世界中学到的各种模式来减少复杂性和代码重复。但归根结底,每个屏幕仍然有一个视图控制器,因为每个屏幕至少有一件独特的事情。由于我放置在它们周围的基础设施,控制器中可能没有太多剩余的代码。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接