在 objective-c 中使用 Controller 作为各种协议(protocol)实现的委托(delegate)是正常的做法吗？我说的是在使用 iOS SDK 时，还是让单独的类来接管委托(delegate)是个好主意？或者它只是最适合场景的情况？我对 Objective c 中的最佳实践非常好奇，因为我正在学习孤立地编写它并且没有“现实世界”专家可以求助。
最佳答案
“ Controller ”侧重于所有权和门面。外部对象将与 Controller 而不是受控对象对话。通常应该直接与 UITableView 对话的唯一对象是 UITableViewController。控制者通常拥有被控制的对象，并且控制者的生命周期至少应与被控制的对象一样长。
“委托(delegate)”侧重于行为、策略和观察者。一个对象向它的代表请求行为指导(我应该显示这个数据吗？应该是什么颜色？我可以做这个 Action 吗？)。当有趣的事情发生时，一个对象会告诉它的委托(delegate)人(我很感动。我即将完成某事。我遇到了一个问题。)一种特殊的委托(delegate)人回答数据问题(第 3 行有什么数据？)。这些称为数据源。
在系统的其余部分通常与“ Controller ”对话的地方，与“代表”对话通常是不合适的。因此，例如，拥有一个指向 UITableViewController 的指针并从系统中的其他地方向它发送消息通常是合适的。有一个指向 Controller 的tableView的指针是不合适的；你应该通过 Controller 工作。另一方面，如果您有一个指向对象的指针，通常不适合请求它的delegate。如果需要，您可能设计了一些不正确的东西。 (最值得注意的例子是 [[NSApplication sharedApplication] delegate]，这几乎总是错误的交谈对象。AppDelegate 是应用程序的委托(delegate)，而不是全局变量的垃圾场。)
如果一个对象有一个 Controller ，那么 Controller 几乎总是委托(delegate)。根据我上面的规则，当一个对象既是 Controller 又是委托(delegate)时，它就是 Controller 。
单个对象可以代表多个事物，特别是如果大多数事物都是短暂的(例如警报 View )。 UIViewController 被委托(delegate)处理一些事情并不罕见。
关于iphone - Objective-c 中的代表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6343275/