6

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

4

6 回答 6

4

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

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

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

这里也是一个关于这个主题的好帖子。

于 2012-11-13T04:49:18.697 回答
2

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

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

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

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

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

于 2012-11-13T04:53:19.020 回答
1

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

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

  • 每个应用程序都有一个应用程序委托：UIApplicationDelegate
  • UIEditView 有委托告诉它如何表现。
  • UIAlertView 有一个委托将用户的操作传回给应用程序。
于 2012-11-13T04:37:29.093 回答
1

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

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

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

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

于 2012-11-13T06:45:35.693 回答
1

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

于 2012-11-13T05:00:21.147 回答
1

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

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

于 2012-11-13T04:49:26.877 回答