ios - 在自定义 View 下确定 Controller 代码的范围是一个好的 Cocoa 设计模式吗？

Question

当我考虑 Cocoa 中 MVC 的所有化身时，我想我可以为应用程序中的每个 View 创建一个自定义类，并用数据源和委托(delegate)填充它 - 主要考虑用于 Controller 的东西。

这样一来，我就可以不再使用臭名昭著的 Massive-View-Controller，而是将代码片段切碎并将它们放在单独的文件中——一个类对应一个 View ——连同它们的数据源和委托(delegate)。

这是个好主意，还是有什么缺点？

Answer 1

我担心你的想法听起来像你最终会得到一堆臃肿的 View 而不是一堆臃肿的 Controller 。

我的建议是考虑 Single Responsibility Principle :一个实体应该只有一个目的或功能。什么是 View 的功能？

它是屏幕区域的代码表示。这意味着它需要做两件事:绘制到它的区域并注册与该区域的交互。任何对这两个子任务不是绝对必要的东西都不应该放在 View 类中。

这就是“愚蠢观点”的思想。它没有逻辑，不需要做出决定。它只是得到一些数据来渲染。当它被点击或点击时，它不知道输入代表什么，也不知道该怎么做。它只知道交互的类型并告诉另一个对象。

另一个对象是 View 的 Controller 。 View Controller 的职责是在 View 和系统的其余部分之间进行调解。它为 View 提供数据。它还接受来自 View 的有关输入的消息，然后根据这些消息的结果重新配置 View 。

然而， View Controller 不一定需要自己计算结果。这通常是 View Controller 开始陷入“巨大”麻烦的地方。 View Controller 应该选择另一个对象来帮助它获取交互产生的新值。

另一个对象的一种可能性是 View 模型，在 MVVM structure 中. View 模型是 View 原始数据的以显示为中心的表示。它将模型中的信息转换为 View 需要的任何格式，并重新转换或更新数据以响应来自 View Controller 的输入。

另一个想法是使用 VIPER 更精细地划分责任安排。这里数据的格式化由“Presenter”处理，而数据的转换是“Interactor”的工作。

在这里有可能进入建筑宇航员领域；如果 View 的需求本质上非常简单，那么盲目地应用复杂的结构可能会让您感到厌烦。但即使您选择不正式应用这些替代模式之一， View Controller 也需要其他对象。您将需要具有其他特定作业的“ Controller ”，它们从 View Controller 获取消息并将数据传回。

重要的是牢记我提到的最初的想法:努力让每个类型做一件事并且把它做好。这将使您的类(class)保持专注；易于阅读、理解和思考；并且可测试。