经过NSNotifications。好的?坏的?NBD？

Question

我正在考虑将NSNotification对象作为var传递给方法的后果。

似乎很难跟踪带有通知的逻辑流发生了什么(没有一些很好的注释和方法/对象命名)，因此将通知传递给另一个方法/class/lib/project只会使调试或智能地响应错误变得更加困难。

但这感觉就像是有很多隐藏的潜在的问题。

我知道还有很多人喜欢通知。

那么，在将实际的NSNotification对象作为方法之间的变量传递方面，有人有一些优点/缺点/更好的实践吗？

为了清楚起见，下面是一些伪代码：

[[NSNotificationCenter defaultCenter] postNotificationName:kSuperImportantNotification object:self userInfo:soMetaDict];

..。稍后在代码中：

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(importantThingHappened:) name:kSuperImportantNotification object:nil];

..。稍后在代码中：

- (void) importantThingHappened:(NSNotification *)notification {
    [respondingInterestedClass executeSomethingWith:notification];
}

..。在"respondingInterestedClass"：

- (void)executeServicesDiscoveredBlock:(NSNotification *)notification {
    // ... do something with the NSNotificaiton object.
}

谢谢

Answer 1

撇开通知的使用方式和时间不谈，而只关注那些完全是正确选择的短暂的用途.

一旦收到通知，通知对象就是一个状态容器，它以对系统方便的格式包含一些状态集。您可以通过将键/值对插入字典并将其作为userInfo (如果需要)传递给它，这样就可以将任何想要的东西放入其中，但它仍然是系统状态。

在设计良好的代码中，存在着难以克服的障碍，通过这些障碍可以很好地定义数据的格式和封装的消息传递。例如，在系统中，模型类不会是UIView的子类，也不会直接处理用户事件。

而通知也应被同等对待。当收到通知时，将其解压到任何您想要的内部和特定的体系结构表示中，并传递给您。

或者，考虑：

- (void) somethingChangedNotification:(NSNotification *)changed
{
    [myModelGoop applyChange:...];
}

@implementation MyModelLayer
- (void)applyChange:(....)change
{
}

在上面，您当然可以将通知对象传递到模型层。但这只是将系统特定的实现细节推入您的模型。

当您有未通过NSNotification触发的更改时，会发生什么？要么将更改封装到一个假的NSNotification实例中(因为发布通知可能会产生副作用，取决于观察对象)，要么您必须重构上面的内容，以便不再在模型层中接收通知。

最好尽早摆脱对系统封装的依赖。

为此，NSNotification实例应该从处理通知的方法中传递从不。

Answer 2

这取决于你在做什么，通常这是什么时候使用什么：

• 一对一关系和松散耦合：代理
• 一对一关系和紧密耦合：直接方法调用
• 一对多关系和松散耦合：Notifications
• 一对多关系和紧密耦合：KVO

因此，您不应该在所有类型的通信中使用通知，即使不需要通知，很多开发人员也会大量使用通知。

这么说，将通知对象传递给方法处理程序是完全可以的，但不要将它传递到其他地方。