什么时候数据源和委托应该是不同的对象？

Question

在什么情况下数据源和委托需要有不同的对象？我遇到的大多数应用程序都强调有self.currentView.delegate = self。它仅仅是为了可读性和分割代码吗？

Answer 1

数据源只是一种具有不同名称和不同职责的委托。文档中的 Apple explains this nicely：

数据源就像一个委托，除了，而不是 用户界面的委托控制，它是对用户界面的委托控制 数据。

分离两个角色允许开发人员在适合他们时为每个角色指定不同的对象，而不是强迫他们为两个相关但不同的任务使用单个对象。为这两个角色使用不同的对象从来都不是必要，但有时会很方便。

考虑一个包含一个表格的视图控制器，该表格可以在多个“模式”之间切换，其中每个模式显示具有不同细节的相同项目。实现这样一个表的一种方法是在视图控制器中做所有事情，但你最终会得到如下代码：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *theCell = nil;
    switch (self.selectedMode) {
        case kFirstMode: {
            // set up the kind of cell required for mode 1
            break;
        }
        case kSecondMode: {
            // set up the kind of cell required for mode 2
            break;
        }
        //...and so on...
    }
    return theCell;
}

你已经闻到负面代码审查的味道了，对吧？

另一种可以说是更好的方法是为每种模式创建单独的数据源对象。当用户切换模式时，您只需换入一个知道如何显示所选模式的数据的新数据源。当不同的模式显示完全不同的数据项而不是相同项的不同方面时，这种方案效果更好。

Answer 2

指向自我（作为“视图控制器”）当然很受欢迎，我相信这是因为在一个地方编写所有代码“更容易”。

如果您遵循任何架构设计模式，大多数人都会希望您创建具有单一职责的对象。这意味着你的班级只负责一件事，而且只负责一件事。

您可以在此处阅读有关此模式的更多信息： http://en.wikipedia.org/wiki/Single_responsibility_principle

将其付诸实践，您将拥有一个仅负责视图布局的视图控制器和一个仅负责加载数据的附加数据源类。

遵循这些设计模式通常意味着您的代码更整洁、更易于维护，cyclomatic complexity 更少。

符合任何类型的“数据源”协议（委托）的类也是可重用的。这意味着您可以跨多个视图控制器使用相同的数据逻辑，而无需重复代码。

Answer 3

我认为您可能不了解数据源和委托。

您的数据源只是您希望项目使用的数据，即 UIITableView、UICollectionView、UIPicker 等。

上面提到的这些元素具有您可以响应的委托。大多数时候，数据源和委托的代码存在于您的实现文件中，通常是某种 UIViewController 实现。

您可以创建另一个对象来处理控件的委托，但我的意见是在大多数情况下只是添加另一个不需要的层。

希望对你有帮助。

Answer 4

委托：将对象的职责委托给另一个对象。 例如：我们在 UITableView、UITextField 和 UITextView 中使用了委托，这样它就可以告知特定事件的更改和更新。

数据源：数据源的职责是在请求时向另一个对象提供数据。 例如：数据源模式与表视图和集合视图一起使用。告诉他们要显示的行数和单元格数。

Answer 5

根据文档：

协调控制器提供以下服务：

• 响应委派消息和观察通知
• 响应操作消息
• 管理拥有对象的生命周期（例如，在适当的时间释放它们）...

但是，重要的是要认识到，在特定情况下，您可以打破这种模式。但目的应该证明手段是正当的。那么什么时候需要呢？每当您作为程序员认为它比将所有回调集中在一个地方更干净时。

来源：Apple Docs、Wiki - MVC