UITableViewDataSource 的设计原理答案

【问题标题】：Rationale for design of UITableViewDataSourceUITableViewDataSource 的设计原理
【发布时间】：2011-01-05 18:13:26
【问题描述】：

我正在为杂志查看器设计一个 API 接口。像 iGizmo（适用于 iPad）。显示杂志的视图与 TableView 非常相似。可以将文章视为部分，将页面视为单元格。

因此，我想以与 UITableView 相同的方式公开 DataSource 和 Delegate。但是我不完全确定为什么苹果以这种方式设计 TableView 委托/数据源，它总是在每个方法中提供 TableView 作为参数。

我试图合理化它，但我没有为这种 api 设计找到任何好的借口。我正在考虑在我的 API 中省略 tableView/magazineView 参数。

您认为这种 API 设计背后有什么好的理由吗？

像下面这样写方法不是更容易更清晰吗？

– cellForRowAtIndexPath: 
– numberOfSections
– numberOfRowsInSection:
– sectionIndexTitles
– sectionForSectionIndexTitle:atIndex:
– titleForHeaderInSection:
– titleForFooterInSection:

【问题讨论】：

标签： objective-c cocoa-touch

【解决方案1】：

有趣的问题。虽然这是一个猜测，但我怀疑它的存在，因此单个数据源类可以作为具有不同要求的多个表视图的委托。（即：它可以检查提供的 tableView 并做出相应的响应。）

因此，如果您没有预料到此要求，您很可能会从方法签名中省略等效参数。

再一次，如果您可能想要访问“调用”的 magazineView，您可以将参数留在其中 - 并不是说传递指针是非常低效的资源。

【讨论】：

完全正确，一个数据源可能为许多视图提供内容，而一个委托可能是许多视图的委托。此外，在某些情况下，委托或数据源可能需要检查调用它的视图以确定如何响应。
@Jonah，@middaparka，我同意，但是您是否曾经以一个实例为多个 tableview 提供服务的方式实现数据源？为什么不创建同一个数据源类的两个实例。这样的 API 设计似乎忽略了 objc 是一种 OO 语言这一事实。
我将编写一个数据源来提供某个模型的特定视图，当然可能会重用该数据源实例来支持多个视图，例如不同方向的不同表视图，但我同意数据source 通常不需要考虑请求数据的对象。另一方面，我的代表会一直检查调用者的身份，例如，我可能会使用单个类作为他们的集体代表来管理 NSURLConnections 的集合。
@Piotr 必须同意 Jonah 的观点，因为这种设置最可能的用途是对同一数据有两种不同的视图，这是一个合理经常发生。