19

问题

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

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

背景

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

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

  • NSNotificationCenter - 不能使用，因为它不保证顺序观察者会被通知，并且因为观察者无法阻止其他观察者接收事件（就像stopPropagation()在 JavaScript 中那样）。
  • Key-Value Observing - 似乎不太适合架构，因为我们真正拥有的是消息传递，并不总是“状态”绑定。
  • 委托和数据源——在我们的例子中，通常会有很多侦听器，而不是一个可以正确称为委托的侦听器。

其中两个是竞争者：

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

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

更新 #1 — 2013 年 4 月

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

内存管理

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

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

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

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

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

设计阻抗

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

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

我们还没有实现这个，但我们可能会基于用户的请求。

更新 #2 — 2013 年 10 月

我不再从事产生这个问题的项目，我很高兴地回到了我的 JavaScript 故乡。

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

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

4

4 回答 4

7

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

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

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

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

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

于 2012-06-13T21:28:56.713 回答
1

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

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

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

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

于 2012-06-14T18:01:04.520 回答
1

很棒的文案！

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

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

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

于 2013-04-15T14:02:51.597 回答
0

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

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

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

于 2012-06-13T21:19:40.347 回答