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

Question

我们正在Objective-C中开发一个自定义的EventEmitter灵感消息系统.对于听众提供回调,我们是否需要块或选择器以及为什么？

作为开发人员,您更愿意使用哪个第三方库？哪个最符合Apple的轨迹,指导方针和做法？

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

我知道在Objective-C中做回调有五种模式,其中三种不适合:

NSNotificationCenter - 无法使用,因为它不能保证订单观察者会收到通知,因为观察者无法阻止其他观察者接收事件(就像stopPropagation()在JavaScript中一样).
键值观察 - 似乎不是一个很好的架构适合,因为我们真正拥有的是消息传递,而不是总是"状态"约束.
代表和数据源 - 在我们的例子中,通常会有许多听众,而不是一个可以正确称为代表的听众.

其中两个是竞争者:

这可能看起来像一个深奥的意见问题,但我觉得有一个客观的"正确"的答案,我只是在Objective-C中缺乏经验来确定.如果这个问题有一个更好的StackExchange站点,请帮助我将其移动到那里.

更新#1 - 2013年4月

我们选择块作为为事件处理程序指定回调的方法.我们对此选择感到非常满意,并且不打算删除基于块的侦听器支持.它确实有两个值得注意的缺点:内存管理和设计阻抗.

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

调用包含对象上的方法的块会隐式提升self引用计数.假设你有一个name类的属性的setter ,如果你name = @"foo"在一个块中调用,编译器将其视为[self setName:@"foo"]并保留,self以便在块仍然存在时不会释放它.

实现EventEmitter意味着拥有长期存在的块.为了防止隐式保留,发射器的用户需要创建对块外部的__block引用self,例如:

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

这种方法的唯一问题是this可以在调用处理程序之前释放.因此,用户必须在取消分配时取消注册其侦听器.

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

幸运的是,委托模式和基于块的侦听器不是互斥的.虽然我们的发射器必须能够处理来自许多地方的侦听器(只有一个委托不起作用),但我们仍然可以公开一个接口,允许开发人员与发射器进行交互,就像它们的类是委托一样.

我们还没有实现这一点,但我们可能会基于用户的请求.

我不再致力于产生这个问题的项目,我很高兴地回到了我原生的JavaScript之乡.

接管这个项目的智能开发人员正确地决定完全退出我们的基于块的自定义EventEmitter.即将发布的版本已切换到ReactiveCocoa.

这使得它们比先前提供的EventEmitter库具有更高级别的信令模式,并且允许它们比基于块的事件处理程序或类级方法更好地封装信号处理程序内的状态.

Answer 1

就个人而言,我讨厌使用代表.由于Objective-C的结构如何,它真的使代码混乱如果我必须创建一个单独的对象/添加协议只是为了通知你的一个事件,我必须实现5/6.出于这个原因,我更喜欢积木.

虽然他们(块)确实有它们的缺点(ex内存管理可能很棘手).它们易于扩展,易于实现,并且在大多数情况下才有意义.

虽然apple的设计结构可能使用sender-delegate方法,但这只是为了向后兼容.最近的Apple API一直在使用块(来自CoreData),因为它们是objective-c的未来.虽然它们在使用时可能会使代码混乱,但它也允许更简单的"匿名代表",这在目标C中是不可能的.

最后,它实际上归结为:你是否愿意放弃一些较旧的,更加过时的平台来换取使用块与代表？委托的一个主要优点是它可以保证在任何版本的objc-runtime中工作,而块是该语言的最新版本.

至于NSNotificationCenter/ KVO来讲,他们都是有用的,并有自己的目的,但作为代表,他们不打算使用.也不能将结果发送回发件人,在某些情况下,这是至关重要的(-webView:shouldLoadRequest:例如).