NSNotification：对象属性必须是 self 吗？
到目前为止，我一直在使用 NSNotificationCenter 和 postNotification:aString object:anyObjectOfInterestForTheReceiver 方法。但最近我在文档中读到，object 字段只能传递 self。是否有任何我不知道的可怕副作用会说服我将来只传递 self ，或者可以传递任何对象吗？ 谢谢你！
So far I have been using NSNotificationCenter with the method postNotification:aString object:anyObjectOfInterestForTheReceiver. But recently I read in the documentation that the object field should only be passed self. Is there any terrible side effect I am unaware of that should convince me to only pass self in the future, or is it OK to pass any object?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以将任何对象作为通知的
object传递，但约定是object是“正在执行通知的事物”（并且您将其他相关状态在userInfo字典中）。它主要是
self的原因是因为通常执行通知的对象通常想要引用它自己。这样，例如，如果您有许多Foo对象，其中一个完成了一项任务并发送了通知，则任何观察该通知的人都可以查看object来查看其中Foo就是有问题的那个。当您遵循此方案时，观察者还可以选择仅观察来自特定Foo的通知。在发布通知时使用“self”之外的其他内容也是合理的（尽管不太常见）——假设您“代表”另一个对象发送通知。例如，您可以是一个完成
Bar任务的单例控制器对象，并且您可以发送带有对特定Bar作为对象的引用的通知。这比使用单例作为对象更有意义，因为那里没有有趣的差异。再次强调，这只是一个（有用的）约定。当您编写自己的通知时，您需要定义通知的“契约”，即名称、使用什么类型的对象作为
对象以及userInfo中的内容。You can pass any object as the
objectof a notification, but the convention is that theobjectis the "thing that is doing the notifying" (and you put other relevant state in theuserInfodictionary).The reason why it's mostly
selfis because usually the object doing the notifying usually wants to reference itself. That way, for example, if you had manyFooobjects, and one of them completed a task and sent a notification, anyone observing the notification could just look atobjectto see whichFoowas the one in question. The observer can also choose to observe only notifications from a particularFoowhen you follow this scheme.It's also reasonable (though less common) to use something besides "self" when posting a notification-- let's say you're sending a notification "on behalf of" another object. For example, you could be a singleton controller object that completes a
Bartask, and you could send the notification with a reference to the particularBaras the object. That makes more sense than using the singleton as theobject, since there'd be no interesting variance there.Again, this is a (useful) convention only. When you make up your own notification, you get to define the "contract" of the notification, which is the name, what kind of object is used as the
object, and what's in theuserInfo.是的，我能想到一个副作用。让我解释一下。
你所说的方法实际上是在 NSNotification.h 中定义的，如下所示：
第一个参数 notificationName 代表通知的名称。
第二个参数notificationSender代表发布通知的对象。
是的，任何对象都可以是通知发送者，甚至 nil 也可以。
在观察通知（成为特定通知的观察者）方面，我们需要知道 NSNotification 中定义的另一个方法：
正如你所看到的，最后一个参数是 notificationSender（观察者想要接收其通知的对象）。
所以现在，副作用很明显。让我详细解释一下。例如，有三个控制器 A、B、C。控制器 A 发布一条通知 helloEveryone。控制器 B 还发布一条通知 helloEveryone。
在 C 控制器中，如果你放置如下语句：
[[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(helloEveryOne) name:@"helloEveryone" object:nil]
那么你将从控制器 A 和控制器 B 收到两个 helloEveryone 。
如果你放置这样的语句：
[[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(helloEveryOne) name:@"helloEveryone" object:controllerA]
那么你只会从控制器 A 收到一个 helloEveryone
。 只要它能发布通知，就肯定不是一个nil通知发送者，但是使用另一个对象作为通知发送者，可能是一个nil对象。观察者的行为根据通知发送者是否为零而不同。
Yes, there is a side effect I can think of. Let me explain it.
The method you talk about was actually defined in NSNotification.h as below:
The first parameter notificationName stands for the name of the notification.
The second parameter notificationSender stands for the object posting the notification.
Yes, any object can be a notification sender, even nil can be.
In terms of observering the notification(to became a observer of a specific notification), we got to know another method defined in NSNotification:
As you can see, the last parameter is notificationSender(the object whose notifications the observer wants to receive).
So right now, the side effect is apparently. Let me explain it in detail. There are three controllers A, B, C.for example. The controller A post a notification helloEveryone. The controller B also post a notification helloEveryone.
In C controller, if you place a statement like below:
[[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(helloEveryOne) name:@"helloEveryone" object:nil]
Then you will receive two helloEveryone from controller A and controller B.
if you place a statement like this:
[[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(helloEveryOne) name:@"helloEveryone" object:controllerA]
Then you will receive only one helloEveryone from controller A.
The self surely is not a nil notification sender as long as it can post a notification, but use another object as a notification sender, may be it is a nil object. And the observer's behave is different in terms of that whether notification sender is nil or not.
事件是否真的有发件人至关重要。
当您注册观察者时，您可以指定要观察的发件人。如果您让其他人使用您的消息，那么正确传递发送者至关重要，否则绑定到特定发送者的观察者将无法收到您的消息。
It is crucial if the events really have sender.
When you register an observer, you can specify the sender that you want to observe. If you are letting other people using your message, so it is crucial to pass sender correctly or the observer that bound to specific sender will not get your message.