【发布时间】:2010-12-28 00:43:49
【问题描述】:
它们各自的优缺点是什么?
我应该具体在哪里使用它们?
【问题讨论】:
标签: iphone objective-c delegates protocols nsnotifications
它们各自的优缺点是什么?
我应该具体在哪里使用它们?
【问题讨论】:
标签: iphone objective-c delegates protocols nsnotifications
这里的经验法则是有多少客户希望收到事件通知。如果它主要是一个对象(例如,关闭视图或对单击的按钮进行操作,或对下载失败做出反应),那么您应该使用委托模型。
如果您发出的事件可能同时对许多对象感兴趣(例如屏幕旋转、内存使用情况、用户登录/注销),那么您应该使用NSNotificationCenter。
【讨论】:
DidFireMissle),而如果您需要返回信息,则需要委托(例如,-(BOOL)shouldFireMissle)。
他们的目的不同:
通知用于向发送者未知的多个接收者广播消息。
委托用于将消息发送给代表发件人行事的单个已知收件人。
【讨论】:
通知通常更适合通知 UI 其他线程上发生的更改。出于稳定性和性能原因,Apple 的文档强烈反对在可能的情况下跨线程使用委托。在 Mac 上,他们建议使用绑定,但由于它们在 iPhone 上不存在,通知可能是您的下一个最佳选择。
【讨论】:
考虑到性能是一个好主意(委托对于少量通知对象更好,通知中心对于大量对象更好,或者是吗?运行分析器)但我认为一个更重要的因素,因为你在谈论目标-C 和不太可能谈论代码库中真正高性能的部分(可能是用 C 编写的)正在减少模块之间的编译时依赖性。
没有什么可以阻止您拥有一组代表而不是单个代表。
我可能仅将 NSNotificationCenter 用于我制作的任何网络堆栈组件的状态以及任何自定义设备状态监控界面。但是对于大多数耦合,与应用程序的全局状态无关,我认为在大多数情况下使用 Objective-C 中的普通接口契约比使用 NSNotificationCenter 更清晰,并且对于追随你的人来说更容易遵循。事实上,我从未将 NotificationCenter 用于我自己的自定义事件,而是更喜欢使用委托以方便其他人阅读我的代码来理解代码。
最后,当然,对于发往/来自标准 API 的通知,您别无选择,必须使用 Apple 为给定事件禁止的两种方法中的任何一种。
【讨论】:
通知更适合解耦 UI 组件。它允许您插入任何视图,而无需对控制器或模型进行任何修改。绝对更适合松散耦合的设计。
但是对于委托和通知之间的性能,您需要考虑调用的频率。
委派可能更适合更频繁的事件,通知更适合不太频繁但更多接收者的事件。选择什么取决于项目。
【讨论】:
这两者之间的一个选项是使用观察者模式,没有NSNotificationCenter。看看我的 Objective-C 实现here。
【讨论】: