Nsnotification 还是委托？答案

【问题标题】：Nsnotification or delegation?Nsnotification 还是委托？
【发布时间】：2012-11-01 13:47:27
【问题描述】：

我刚刚研究了这两者，它们似乎都是很好的交流方式，但 nsnotification 似乎更容易处理。在什么情况下您希望使用委托而不是 nsnotification，以及 nsnotification 而不是委托？

【问题讨论】：

【解决方案1】：

我通常在子系统内的类之间使用委托，但在不需要直接链接在一起且严格的通知顺序并不重要的子系统边界使用通知。当一个类需要直接代表它完成某些事情时（如 UITableView 所做的那样），我也会使用委托，而当动作必须不是直接代表通知者而是为了它们自己的目的而发生时，我也会使用通知。

通知对于松散耦合的系统很有用，例如当您完成登录到服务器并且一堆其他子系统需要知道它可以继续执行他们应该执行的任何任务时。这些系统可能并不都需要与您的登录子系统有直接关系，但它们都需要因此做“某事”。通知也不像代表那样规定实现的形式，因为通知者不应该关心。

委托在一个更紧密耦合的系统中是很好的，在这个系统中可以指定实现（比如说'现在做这个，然后这个，然后那个'），通常是通过实现一个委托必须遵守的协议。如果您尝试了解各种代码如何协同工作，那么委派也更容易理解，因为这种关系被更清楚地识别出来。

这里也有一个很好的post。

【讨论】：

【解决方案2】：

是的，我同意 NSNotifications 比您自己的委托协议和方法更容易实现。我真的不知道这两种方法的相对“成本”（时间或内存使用）是多少，但我使用其中一种方法的标准如下。

如果不止一个班级需要知道您在第三个班级中正在做的事情，那么我会使用通知，因为它是“广播”，并且任何注册通知的对象都可以获取信息。

我使用通知的另一次是如果我有两个对象，例如视图控制器，它们在控制器链中或在链的不同分支上相距很远，因此很难获得对所需控制器的引用以自己为代表。

否则，当两个控制器“靠得很近”时，例如当一个控制器创建下一个控制器以准备推送或转场时，我使用委托将信息从推送的视图控制器获取回执行推送的视图控制器。

此外，如果控制器需要根据另一个对象中发生的情况执行多项操作，那么再次委托会更好，因为您可以拥有一个包含许多方法的委托协议（例如 UITableViewDelegate）。

【讨论】：

【解决方案3】：

顺便说一句：两者都是很棒的概念。通知更容易处理——尤其是在不加思索地使用时很容易编写无法维护的代码。

在大多数情况下，一个好的架构应该能够在没有它们的情况下生存。

我见过一个更大的 iPad 项目，其中使用通知来弥补架构设计中的缺陷：太可怕了。代码在 2 个月后完全无法维护。

我的经验：它们是一个非常方便的工具 - 如果其他工具出现故障，请使用它们

【讨论】：

【解决方案4】：

委托在许多 iOS 视图中都很重要，例如 UITableView。 UITableView 有一个 UITableViewDelegate 和一个 UITableViewDataSource。两者都是提供有关表内容的信息所必需的。通知无法做到这一点。

其他一些使用委托的地方：

每个应用都有一个应用委托：UIApplicationDelegate
UIEditView 有委托告诉它如何表现。
UIAlertView 有一个委托将用户的操作传回给应用程序。

【讨论】：

这不能回答 OP 的问题。

【解决方案5】：

当事件的接收者数量有限（可能为 1 或 2）以及您想要控制事件的传递方式时，委托通常很有用。例如，如果让我们说 UIApplicationDelegate 示例，在 applicationDidFinishLaunch 完成之前您不能调用 applicationDidForeground，因此您可以确保接收者在交付下一个事件之前已确认每个事件。如果您必须交付必须遵循生命周期的事件，例如开始、结束、开始、完成等。委托会更好。

在我看来，通知大多类似于布尔事件，即使您可以随其传递数据，如果您必须广播某个事件而不管接收者是谁，它们都会很有用。通常这在您必须传达信息更改时很有用

【讨论】：

【解决方案6】：

首先，我不得不说，委托比通知要快得多。如果在您的项目中有 100 个委托，那很好，但是当您收到 100 个通知时，很容易在设备上变得很慢。但是，委托有限制：您的对象只能有一个特定类型的委托。并且在通知的情况下，观察员的人数一般不受限制。此外，委托方法很可能在同一个线程上执行，除非您使用特定方法在不同线程上执行它们。

【讨论】：