通过 [[NSNotificationCenter defaultCenter] postNotificationName] 方法直接传递对象是否危险？答案

【问题标题】：Is it dangerous to directly pass object via [[NSNotificationCenter defaultCenter] postNotificationName] method?通过 [[NSNotificationCenter defaultCenter] postNotificationName] 方法直接传递对象是否危险？
【发布时间】：2016-02-11 15:39:37
【问题描述】：

我正在编写一个 SDK 并寻找通过 NSNotification 发送对象的最佳实践。

Apple 和包括this 在内的一些线程表明postNotificationNamer 中的object 参数应该是通知的发送者，在大多数情况下，self。您的自定义对象应通过 userInfo NSDictionary 传递。来自 Apple 文档：

使用给定的名称、发送者和信息创建通知并将其发布给接收者。

例如，不恰当的做法是：

[[NSNotificationCenter defaultCenter] postNotificationName:@"myNotification" 
                                                    object:myObject];

推荐的方式是：

NSDictionary* userInfo = @{@"myMessage": myObject};
[[NSNotificationCenter defaultCenter] postNotificationName:@"myNotification" 
                                                    object:self 
                                                  userInfo:userInfo];

这两种方法我都试过了，都很好用。问题是，使用以前的方法有风险吗？就我而言，我对通知的发送者不感兴趣，但使用后一种方法会在我要发送的实际对象周围引入一个额外的包装器 (NSDicionary)。

【问题讨论】：

标签： ios nsnotificationcenter

【解决方案1】：

使用 object 参数并不危险，但请记住，NSNotificationCenter 在内部使用该参数来决定某些事情。因此，如果您的代码依赖于以特定顺序或特定队列运行的事物，它可能表现出意外。

这是来自NSNotificationCenter Class Reference的相关引用：

您要将其通知添加到操作队列的对象。

如果传递 nil，通知中心不会使用通知的发送者来决定是否将块添加到操作队列中。

我会建议您按预期使用 userInfo，但这并不危险。

【讨论】：

【解决方案2】：

后者更灵活。虽然您现在可能不在乎发件人，但情况可能会改变。而且您以后可能会发现需要传递其他信息。

最好提前做好。第一次就正确完成不需要额外的努力，当您的需求发生变化时，必须返回并重构一堆代码将需要付出很多努力（并且容易出错）。

另外，使用后一种方法意味着您的代码与在其他框架中的执行方式一致。一致性使代码更易于阅读和维护。您不必考虑“好吧，在这种情况下，我在这里得到了对象，但在这种情况下，我在那儿得到了它”。

【讨论】：