您对通知和委托的替代方案的看法：信号？

Question

SO 告诉我这个问题是主观的，可能会被关闭。这确实是主观的，因为我正在征求经验丰富的 Objective-C 开发人员的意见。我应该将其发布到其他地方吗？请指教。

---

对 Objective-C 相当陌生，尽管对编写 OOP 代码的概念相当有信心，但我从一开始就一直在 NSNotification 与 Delegate 的困境中挣扎。我单独发布了一些关于该主题的问题。我想我确实明白了要点。通知是全局广播的，因此不应用于通知密切相关的对象。委托的存在是将任务移交给代表委托对象执行操作的其他对象。虽然这可以用于密切相关的对象，但我发现工作流程很冗长（新类、新协议等），并且“委托”一词本身就让我想到了军队和老板，总的来说让我感到不安。

我来自的地方（AS3）有一种叫做“事件”的东西。他们介于 delegates 和 NSNotifications 之间，几乎统治了 flash notification 的世界，直到最近，Robert Penner 先生出现并表达了他对事件的不满。因此，他编写了一个名为 Signals 的库，现已在 AS3 社区中广泛使用。受到 C# 事件和 Qt 中的信号/槽的启发，这些信号实际上是对象的属性，您可以从外部访问它们并向其添加侦听器。您还可以利用信号做更多事情，但其核心仅此而已。

因为这个概念太简单了，所以我尝试了一下，用 Objective-C 编写了自己的信号类。 我在这里列出了 Signal.h/.m。

使用它来通知 A 类 B 类中的事件的方法可能如下所示：

// In class b, assign a Signal instance to a retained property:
self.awesomeThingHappened = [[[Signal alloc] init] autorelease];

// In class a, owner of class b, listen to the signal:
[b.awesomeThingHappened add:self withSelector:@selector(reactToAwesomeThing)];

// And when something actually happens, you dispatch the signal in class b:
[self.awesomeThingHappened dispatch];

// You might even pass along a userInfo dictionary, your selector should match:
[self.awesomeThingHappened dispatchWithUserInfo:userInfo];

我希望它遵守正确的内存管理规则，但是当信号释放时，它应该自动删除所有侦听器并默默地消失。像这样的信号不应该是通知和委托的通用替代品，但在很多近距离柜台情况下，我觉得信号比其他两个更干净。

我向 stackoverflow 提出的问题是，您对这样的解决方案有何看法？如果您的一名实习生将其放入您的项目中，您会立即将其从您的项目中删除吗？如果你的员工已经完成实习，你会解雇他吗？或者是否已经有类似但更宏伟的东西可供您使用？

感谢您抽出时间，EP。

---

编辑：让我举一个具体的例子来说明我如何在 iOS 项目中使用它。

考虑这种具有嵌套所有权的四种对象类型的场景。有一个视图控制器拥有一个窗口管理器，拥有多个窗口，每个窗口拥有一个带控件的视图，其中有一个关闭按钮。这里可能存在设计缺陷，但这不是示例的重点：P

现在，当点击关闭按钮时，手势识别器会触发窗口对象中的第一个选择器。这需要通知窗口管理器它正在关闭。然后，窗口管理器可以决定是否出现另一个窗口，或者窗口是否完全隐藏，此时视图控制器需要获得碰撞以启用主视图上的滚动。

从窗口到窗口管理器以及从窗口管理器到视图控制器的通知是我现在用信号实现的。这可能是委托的情况，但对于“关闭”操作来说，创建两个委托协议似乎非常冗长。另一方面，因为这些对象的耦合定义得很好，所以它看起来也不像是 NSNotifications 的情况。我也无法通过 KVO 观察到真正的值变化，因为它只是一个按钮点击。监听某种“隐藏”状态只会让我在重新打开窗口时必须重置该标志，这使得它更难以理解并且容易出错。

Answer 1

好吧，在对答案和评论进行了一番腌制之后，我想我已经得出了这样的结论：我从 AS3 借用的 Signal 类在 Objective-C/Cocoa 中几乎没有存在的理由。 Cocoa 中有几种模式涵盖了我想要用 Signal 类涵盖的使用范围。对于更有经验的 Cocoa 开发人员来说，这似乎非常微不足道，但对我来说，很难获得完整的频谱。

我试着把它写得相当简洁，但如果我有错，请纠正我。

Target-Action

仅用于通知您的应用程序用户交互（主要是触摸）。根据我所看到和阅读的内容，没有办法“借用”目标操作系统供您自己使用。

KVO（键值观察）

对于在可访问对象中的值发生更改时接收通知非常有用。对于通知没有附加值的特定事件（例如计时器事件或接口后续事件）来说不太有用。

NSNotification

对于在难以访问的对象中发生值更改或其他事件时接收通知非常有用。由于通知中心的广播性质，这不太适合对象直接引用另一个对象的情况。

与其他三个相比，委派

占用的代码行数最多，但在其他三个不适合的情况下也是最合适的。当一个对象应被通知另一对象中的特定事件时，请使用此对象。不应滥用委托来仅访问所有者对象的方法。坚持使用“应该”、“将”和“做了”等方法。

Signal

这是一个有趣的实验，但我主要将其用于经典的委托情况。我还使用它来规避链接委托（b 的 c 委托，a 的 b 委托，其中 a 启动应该使其到达 c 的事件），而不想诉诸 NSNotification。

我仍然认为对于这种边缘情况应该有一个更优雅的解决方案，但现在我会
只需坚持现有框架即可。如果有人有更正或其他通知概念，请告诉我。感谢您的帮助！

Answer 2

这是一个有趣的想法，但我想我看不出它与 Cocoa 的通知中心有何显着不同。比较和对比：

self.awesomeThingHappened = [[[Signal alloc] init] autorelease];                  // Your signals library
                                                                                  // Cocoa notifications (no equivalent code)

[b.awesomeThingHappened add:self withSelector:@selector(reactToAwesomeThing)];    // Your signals library
[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(reactToAwesomeThing:)
                                             name:@"AwesomeThingHappened"
                                           object:n];                             // Cocoa notifications

[self.awesomeThingHappened dispatch];                                             // Your signals library
[[NSNotificationCenter defaultCenter] postNotificationName:@"AwesomeThingHappened"
                                                    object:self];                 // Cocoa notifications

[self.awesomeThingHappened dispatchWithUserInfo:userInfo];                        // Your signals library
[[NSNotificationCenter defaultCenter] postNotificationName:@"AwesomeThingHappened"
                                                    object:self
                                                  userInfo:userInfo];             // Cocoa notifications

所以，好吧。我认为您并不是想说，逐行的 Cocoa 信号库是不同的；相反，争论认为它是耦合的，它不像委托那么紧密，但也不像通知那么松散。为此，我想我想知道它有多大必要？我想我可以看到有点需要说“这个对象‘A’严重依赖‘B’，但不需要耦合得那么紧密”，但说实话，这似乎是一种罕见的情况。

无论如何，NSNotificationCenter 及其同类以及委托在 Cocoa 应用程序中都是相当标准的。我总是使用经验法则，如果你偏离了标准，即使是事实上的标准，你也应该有充分的理由。如果您有充分的理由既不使用 NSNotificationCenter 也不使用委托，那么您可能有充分的理由使用此信号设置。 （顺便说一句，我对将通知和委托关联起来犹豫不决——它们每个人都有一个角色，并且因不同的原因而存在。）

如果没有特定的用例，很难说更多。我倾向于说，“嘿，它看起来很酷，但看起来它填补了通知已经扮演的角色。”您有什么可以引用的具体用例吗？

Answer 3

您对这样的解决方案有何看法？

我实在看不出有什么好处。对我来说，它似乎是目标/操作+通知的组合（对于单个通知事件，您可以有多个目标/操作，但 t/a 对是在对象本身注册的，而不是全局通知中心）。事实上，它更像是键值观察，只不过 KVO 仅限于可观察的属性。

如果您的一名实习生将其放入项目中，您会立即将其从项目中删除吗？

不，这不是坏代码。事实上，它看起来有点整洁。但我只是没有看到它有明显的好处。

如果你的员工已经完成实习，你会解雇他吗？

当然不是。你不会因为写出好的代码而解雇员工。

是否已经有类似但更宏伟的东西可供您使用？

如果您确实想让这变得简洁，请将 API 更改为使用块。然后你可以这样做：

[object dispatchOnAwesomeThingHappened:^{
  NSLog(@"holy cow, something awesome just happened!");
}];

但是，同样，你只能对对象明确“调度”的内容做出反应。如果您可以在任何任意方法调用之前和/或之后立即附加内容，那就更整洁了。如果您对此感兴趣，那么我会查看 github 上的 Aspect Objective-C。

Answer 4

我认为 NSNotifications 和 Delegates 之间存在差距。 KVO 拥有所有 Cocoa 中最差 API。

至于 NSNotificationCenter 这里是它的一些问题：

• 它很容易出现拼写错误
• 很难跟踪给定对象的观察者，因此很难调试
• 它非常冗长
• 你只能在字典中传递通知数据，这意味着你不能使用弱引用或结构，除非你包装它们。 （参见：非常详细）
• 与 GCD 配合不佳：对队列的有限支持（仅块）

因此肯定需要更好的东西。

我创建了我自己的可观察类，我在每个项目中都使用它。另一种选择是使用 ReactiveCocoa 的 RACSignal。