Objective-C 库中回调的选择器或块

Question

问题

我们正在用 Objective-C 开发一个自定义的 EventEmitter inspired 消息系统。对于侦听器提供回调，我们应该要求blocks 还是selectors，为什么？

作为使用第三方库的开发人员，您更愿意使用哪个？哪一个似乎最符合 Apple 的发展轨迹、准则和实践？

背景

我们正在用 Objective-C 开发一个全新的 iOS SDK，其他第三方将使用它来将功能嵌入到他们的应用中。我们 SDK 的很大一部分将需要将事件传递给侦听器。

我知道有五种在 Objective-C 中执行回调的模式，其中三种不适合：

• NSNotificationCenter - 不能使用，因为它不能保证观察者会收到通知，并且观察者无法阻止其他观察者接收事件（就像 JavaScript 中的 stopPropagation() 一样）。
• Key-Value Observing - 看起来不太适合架构，因为我们真正拥有的是消息传递，并不总是“状态”绑定。
• Delegates and Data Sources - 在我们的例子中，通常会有很多听众，而不是一个可以正确称为委托的听众。

其中两个是竞争者：

• Selectors - 在此模型下，调用者提供一个选择器和一个目标，它们被共同调用以处理事件。
• Blocks - 在 iOS 4 中引入，块允许传递功能而无需像观察者/选择器模式那样绑定到对象。

这似乎是一个深奥的意见问题，但我觉得有一个客观的“正确”答案，我在 Objective-C 中经验不足，无法确定。如果这个问题有更好的 StackExchange 站点，请移到那里帮助我。

更新 #1 — 2013 年 4 月

我们选择 blocks 作为为我们的事件处理程序指定回调的方法。我们对这个选择非常满意，并且不打算删除基于块的侦听器支持。它确实有两个显着的缺点：内存管理和设计阻抗。

内存管理

块最容易在堆栈上使用。通过将它们复制到堆上来创建长寿命块会引入有趣的内存管理问题。

调用包含对象上的方法的块会隐式增加self 的引用计数。假设您有一个用于类的name 属性的设置器，如果您在块内调用name = @"foo"，编译器会将其视为[self setName:@"foo"] 并保留self，这样它就不会在块被释放时被释放还在。

实现 EventEmitter 意味着拥有长寿命的块。为防止隐式保留，发射器的用户需要在块外创建对self 的__block 引用，例如：

__block *YourClass this = self;
[emitter on:@"eventName" callBlock:...
   [this setName:@"foo"];...
}];

这种方法的唯一问题是this 可能在调用处理程序之前被释放。所以用户在被释放时必须取消注册他们的监听器。

设计阻抗

经验丰富的 Objective-C 开发人员希望使用熟悉的模式与库进行交互。委托是一种非常熟悉的模式，因此规范的开发人员希望使用它。

幸运的是，委托模式和基于块的侦听器并不相互排斥。尽管我们的发射器必须能够处理来自许多地方的侦听器（只有一个委托是行不通的），但我们仍然可以公开一个接口，允许开发人员与发射器进行交互，就好像他们的类是委托一样。

我们还没有实现这一点，但我们可能会根据用户的请求。

更新 #2 — 2013 年 10 月

我不再从事引发这个问题的项目，我非常高兴地回到了我的 JavaScript 故乡。

接手这个项目的聪明的开发者们正确地决定完全停用我们自定义的基于块的 EventEmitter。 即将发布的版本已切换到ReactiveCocoa。

这为它们提供了比我们之前的 EventEmitter 库提供的更高级别的信号模式，并允许它们比我们基于块的事件处理程序或类级方法更好地将状态封装在信号处理程序中。

Answer 1

就个人而言，我讨厌使用委托。由于objective-C的结构，如果我必须创建一个单独的对象/添加一个协议只是为了收到你的一个事件的通知，它真的会让代码变得混乱，我必须实现5/6。出于这个原因，我更喜欢块。

虽然它们（块）确实有其缺点（例如，内存管理可能很棘手）。它们易于扩展、易于实现，并且在大多数情况下才有意义。

虽然苹果的设计结构可能会使用 sender-delegate 方法，但这只是为了向后兼容。最近的 Apple API 一直在使用块（例如 CoreData），因为它们是 Objective-c 的未来。虽然它们在过度使用时会使代码混乱，但它也允许更简单的“匿名代表”，这在目标 C 中是不可能的。

最后，归根结底是这样的： 您是否愿意放弃一些较旧、更过时的平台，以换取使用区块与委托？委托的一个主要优势是保证可以在任何版本的 objc-runtime 中工作，而块是该语言的最新添加。

就NSNotificationCenter/KVO 而言，它们都是有用的，并且有其用途，但作为代表，它们并不打算被使用。两者都不能将结果发送回发件人，在某些情况下，这至关重要（例如-webView:shouldLoadRequest:）。

Answer 2

我认为正确的做法是实现两者，将其用作客户端，然后看看什么感觉最自然。这两种方法都有优点，它实际上取决于上下文以及您期望如何使用 SDK。

选择器的主要优点是简单的内存管理——只要客户端正确注册和注销，它就不需要担心内存泄漏。使用块，内存管理可能会变得复杂，这取决于客户端在块内执行的操作。对回调方法进行单元测试也更容易。 Blocks can certainly be written to be testable，但从我所看到的情况来看，这并不常见。

块的主要优点是灵活性——客户端可以轻松引用局部变量而无需将它们设为 ivars。

所以我认为这仅取决于用例——对于这样一个通用的设计问题，没有“客观正确的答案”。

Answer 3

好文章！

在我个人看来，由于编写了大量 JavaScript，事件驱动的编程感觉比让委托来回更简洁。

关于监听器的内存管理方面，我尝试解决这个问题（大量借鉴 Mike Ash 的 MAKVONotificationCenter），调动调用者和发射器的 dealloc 实现（as seen here），以便安全地移除监听器两种方式。

我不完全确定这种方法有多安全，但我的想法是尝试它直到它崩溃。

Answer 4

关于库的一个特点是，您只能在一定程度上预测它会被如何使用。所以你需要提供一个尽可能简单和开放的解决方案——并且用户熟悉。

• 对我来说，这一切都最适合委派。尽管您是对的，它只能在侦听器（委托）上具有，但这意味着没有限制，因为用户可以编写一个类作为委托，它知道所有需要的侦听器并通知他们。当然你可以提供一个注册类。这将调用所有注册对象的委托方法。
• 方块也一样好。
• 您将选择器命名为目标/动作，简单而强大。
• 对我来说，KVO 似乎也不是最佳解决方案，因为它可能会削弱封装性，或者导致错误的思维模型对如何使用库的类。
• NSNotifications 可以很好地通知某些事件，但不应强迫用户使用它们，因为它们非常不正式。如果有人收听，您的班级将无法知道。

关于 API 设计的一些有用的想法：http://mattgemmell.com/2012/05/24/api-design/