问题
我们正在 Objective-C 中开发一个受 EventEmitter 启发的自定义消息系统。对于侦听器提供回调，我们应该需要块还是选择器，为什么？
作为使用第三方库的开发人员，您更愿意使用哪个？ 哪个看起来最符合苹果的发展轨迹、指导方针和做法？
背景
我们正在Objective-C中开发一个全新的iOS SDK，其他第三方将使用它将功能嵌入到他们的应用程序中。 我们的SDK的很大一部分将需要将事件与侦听器进行通信。
我知道在 Objective-C 中进行回调有五种模式，其中三种不适合：
- NSNotificationCenter - 不能使用，因为它不能保证顺序观察者会收到通知，并且因为观察者无法阻止其他观察者接收事件（就像 JavaScript 中的
stopPropagation()那样）。 - 键值观察 - 似乎不太适合架构，因为我们真正拥有的是消息传递，并不总是"状态"绑定。
- 委托和数据源 - 在我们的例子中，通常会有很多侦听器，而不是一个可以正确地称为委托的侦听器。
其中两个是竞争者：
- 选择器 - 在此模型下，调用方提供共同调用以处理事件的选择器和目标。
- 块 - 在iOS 4中引入，块允许功能传递，而无需绑定到观察者/选择器模式等对象。
这似乎是一个深奥的观点问题，但我觉得有一个客观的"正确"答案，我在Objective-C方面太缺乏经验而无法确定。 如果这个问题有更好的StackExchange站点，请帮助我将其移动到那里。
更新 #1 — 2013 年 4 月
我们选择块作为为事件处理程序指定回调的方法。我们对这个选择非常满意，不打算删除基于块的侦听器支持。它确实有两个明显的缺点：内存管理和设计阻抗。
内存管理
块最容易在堆栈上使用。通过将长期块复制到堆上来创建长生存期块会引入有趣的内存管理问题。
在包含对象上调用方法的块隐式增加self的引用计数。假设您有一个用于类的 name 属性的 setter，如果您在块内调用 name = @"foo"，编译器会将其视为[self setName:@"foo"]并保留self，以便在块仍然存在时不会释放它。
实现事件发射器意味着拥有长寿命的块。为了防止隐式保留，发射器的用户需要创建对块外部self的__block引用，例如：
__block *YourClass this = self;
[emitter on:@"eventName" callBlock:...
[this setName:@"foo"];...
}];
此方法的唯一问题是，在调用处理程序之前可能会释放this。因此，用户在解除分配时必须取消注册其侦听器。
设计阻抗
经验丰富的Objective-C开发人员希望使用熟悉的模式与库进行交互。委托是一种非常熟悉的模式，因此规范开发人员希望使用它。
幸运的是，委托模式和基于块的侦听器并不相互排斥。虽然我们的发射器必须能够处理来自许多地方的侦听器（只有一个委托是行不通的），但我们仍然可以公开一个接口，允许开发人员与发射器进行交互，就好像他们的类是委托一样。
我们尚未实现这一点，但我们可能会根据用户的请求实现。
更新 #2 — 2013 年 10 月
我不再从事产生这个问题的项目，我非常高兴地回到了我的故乡 JavaScript。
接管这个项目的聪明开发人员正确地决定完全停用我们自定义的基于块的事件发射器。即将发布的版本已切换到ReactiveCocoa。
这为它们提供了比我们以前提供的 EventEmitter 库更高级别的信令模式，并允许它们比基于块的事件处理程序或类级方法更好地封装信号处理程序中的状态。
就个人而言，我讨厌使用委托。由于 objective-C 的结构，如果我必须创建一个单独的对象/添加一个协议只是为了收到您的一个事件的通知，它确实会使代码混乱，并且我必须实现 5/6。出于这个原因，我更喜欢块。
虽然它们（块）确实有其缺点（例如，内存管理可能很棘手）。它们易于扩展，易于实现，并且在大多数情况下都有意义。
虽然 Apple 的设计结构可能使用发送方-委托方法，但这仅用于向后兼容。最近的Apple API一直在使用块（例如CoreData），因为它们是objective-c的未来。虽然它们在落水时使用时会使代码混乱，但它也允许更简单的"匿名委托"，这在目标 C 中是不可能的。
不过，最后，它真的归结为： 您是否愿意放弃一些较旧、更过时的平台，以换取使用区块与委托？ 委托的一个主要优点是它保证在任何版本的 objc-runtime 中工作，而块是该语言的最新添加。
就NSNotificationCenter/KVO而言，它们都是有用的，并且有其目的，但作为代表，它们不打算被使用。两者都不能将结果发送回发送者，在某些情况下，这是至关重要的（例如-webView:shouldLoadRequest:）。
我认为正确的做法是实现两者，将其用作客户端，看看什么感觉最自然。这两种方法都有优点，这实际上取决于上下文以及您希望如何使用 SDK。
选择器的主要优点是简单的内存管理 - 只要客户端正确注册和注销，就不必担心内存泄漏。使用块，内存管理可能会变得复杂，具体取决于客户端在块内执行的操作。对回调方法进行单元测试也更容易。块当然可以编写为可测试的，但从我所看到的情况来看，这不是常见的做法。
块的主要优点是灵活性 - 客户端可以轻松引用局部变量，而无需使它们成为ivar。
所以我认为这只取决于用例——对于这样一个通用的设计问题没有"客观的正确答案"。
很棒的文章！
在我个人看来，从编写大量JavaScript开始，事件驱动编程感觉比来回委托要干净得多。
关于侦听器的内存管理方面，我试图解决这个问题（大量借鉴Mike Ash的MAKVONotificationCenter），同时切换调用方和发射器的dealloc实现（如此处所示），以便以两种方式安全地删除侦听器。
我不完全确定这种方法有多安全，但我们的想法是尝试它，直到它破裂。
关于库的一件事是，您只能在某种程度上预测它将如何使用。 因此，您需要提供一个尽可能简单和开放的解决方案，并且用户熟悉。
- 对我来说，所有这些都最适合授权。虽然你是对的，它只能有侦听器（委托），但这意味着没有限制，因为用户可以编写一个类作为委托，它知道所有想要的侦听器并通知他们。当然，您可以提供一个注册类。 它将在所有注册对象上调用委托方法。
- 块一样好。
- 您命名的选择器称为目标/操作，简单而强大。
- 对我来说，KVO 似乎也不是一个最佳解决方案，因为它可能会削弱封装，或者导致如何使用库类的蛙式思维模型。
- NSNotizations很高兴告知某些事件，但不应强迫用户使用它们，因为它们非常非正式。 并且您的班级将无法知道是否有人收听。
关于API设计的一些有用想法：http://mattgemmell.com/2012/05/24/api-design/