Objective-C: block vs. 选择器 vs. 协议(protocol)

Question

我经常发现自己正在编写可在整个项目中重复使用的“实用程序”类。

例如，假设我有一个“通讯录” View 。我可能想使用我的地址簿来选择向谁发送电子邮件，或者将谁添加到 session 请求中。

我会开发这个 View Controller ，以便电子邮件 Controller 和 session Controller 都可以使用它，并通过某种回调机制让调用者知道用户要么完成了从通讯录中选择某人，要么他们取消。

在这种情况下，基本上可以采取四种(合理的)方法；

• 在 AddressBookController 上创建“AddressBookDelegate”协议(protocol)和相应的委托(delegate)属性。然后使用协议(protocol)中定义的消息来传递结果(类似于 UIActionSheetDelegate)。

• 在 AddressBookController 上创建一个“非正式”“AddressBookDelegate”协议(protocol)和一个对应的委托(delegate)属性，但委托(delegate)属性的类型将是“id”，并在运行时使用“respondsToSelector:”检查是否委托(delegate)实现了我们需要的方法(似乎大多数框架的东西已经开始这样了)。

• 向 AddressBookController 传递一个代表委托(delegate)的 id，以及两个 SEL，它们指定当用户选择用户或取消请求时要调用的方法。我看到的好处是；假设一个 Controller 同时支持发送电子邮件和设置 session (我知道在这个例子中这似乎是糟糕的设计......但可以想象一个更通用的情况，这对于实用程序类来说似乎是完全合理的) - 在这种情况下你可以根据您是将用户添加到电子邮件中，还是将用户添加到 session 中，向 AddressBookController 传递不同的 SEL……这是对 iVar 的巨大改进，以指示 Controller 的“状态”。

• 向 AddressBookController 传递两个 block ；一个在用户从通讯簿中选择某人时运行，另一个在用户取消请求时运行。

这些 block 对我来说非常有用，而且更加优雅，我发现自己几乎不知道什么时候不使用它们。

我希望 StackOverflow 社区中更有经验的成员能够帮助他们就这个主题提出想法。

Answer 1

执行此操作的“传统”方式是使用协议(protocol)。在将@protocol 添加到语言中之前使用了非正式协议(protocol)，但那是在我之前，至少在过去几年中，非正式协议(protocol)已被劝阻，特别是考虑到@optional 说明符。至于通过两个 SEL 的“代表”，这似乎比宣布正式协议(protocol)更丑陋，而且在我看来通常不合适。 block 是非常新的(尤其是在 iOS 上)，随着这些事情的发展，虽然我们还没有看到关于最佳尝试和真实风格的大量文档/博客，但我喜欢这个想法，这似乎是其中之一things block 最适合:整洁的新控制流结构。

基本上我想说的是，这些方法中的每一种都在年龄上有所不同，除了风格之外没有比最后一种更好的方法，这显然很重要，这也是创造这些东西的最终原因.基本上，选择你觉得舒服的最新东西，应该是 block 或正式协议(protocol)，你的困惑很可能来自阅读相互冲突的资源，因为它们是在不同时间编写的，但从时间的角度来看，它是清楚地看到哪个取代了其他。

[Controller askForSelection:^(id selection){
  //blah blah blah
} canceled:^{
  //blah blah blah
}];

可能比定义两个额外的方法和为它们定义一个协议(protocol)(正式或其他方式)或传递 SEL 并将它们存储在 ivars 中等要简洁得多。