iPhone Objective-C NSNotification 的放置
我有一个相当复杂的 iPhone 应用程序，其中有许多异步进程发生。为了解决这个问题，我大量使用 NSNotification Center。我的问题是，如果存在这种情况，注册通知的“最佳实践”是什么？现在他们以一种偶然的方式散布在我的代码中。我即将投入生产，我希望它被清理我想在主视图的 viewDidLoad 中使用一个“registerNotifications”方法，它显然可以一次性注册所有通知，如果不是的话，处理此问题的首选方法是什么。 !!
I have a fairly complex iphone application that has many asynchronous processes occurring. To deal with this I'm making heavy use of NSNotification Center. My question is what is the "best practice", if such a thing exists", for registering the notifications? Right now they sprinkled through my code in a hap-hazard way. I'm about to go to production and I want it cleaned up. I though about having a "registerNotifications" method in viewDidLoad of the main view which obviously registers all notifications in one shot. Does this sound reasonable? If not what would be the preferred way of dealing with this. Thanks in advance for your help!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将所有通知放在一个对象中会破坏封装性，这是不好的。您使一个对象的通知操作依赖于另一个对象的正常工作。追踪这一切实际上将是一场噩梦。这也倒退到了通知的整个目的，即创建一个去中心化和模块化的消息传递系统。
通知不应“散布在整个代码中”，而应仅由接收通知的对象进行管理。如果您使用大量通知，您可能需要创建一个具有处理多个通知的专用方法的类，然后让其他类继承该类。这样你就可以实现自动管理。
人们在通知方面犯的最大错误之一是，当他们真正需要注册数据模型时，却注册了控制器。例如，假设您正在从 URL 下载一些数据，并且希望在下载过程中和/或结束时更新界面。如果您的 UI 中有多个视图并且注册了控制器，那么每个视图都必须管理一个通知（可能有多个通知）。但是，如果您设置共享数据模型来接收通知，则您只需要一个通知最多两个通知。我们将转到数据模型，以便数据模型可以自行更新，然后您可以让数据模型发出通用通知，以便任何侦听视图从数据模型进行自我更新。
在所有情况下，使视图控制器依赖于数据模型都可以大大简化设计。
Putting all the notifications in one object destroys encapsulation and that is bad. You make one objects notification operations dependent on another object working properly. It will actually be a nightmare tracking all that. It is also backwards to the entire of purpose of notifications which is to create a decentralized and modular messaging system.
Notifications shouldn't be "sprinkled throughout the code" but they should be managed solely by the objects that receive them. If you use a great deal of notifications you might need to create a class with dedicated methods for handling multiple notifications and then have your other classes inherit from that class. That way you get automatic management.
One of the big mistakes people make with notifications is that they register controllers when they really need to register their data model. For example, suppose you're downloading some data from a URL and you want to update the interface as it progresses and/or when it ends. If you have multiple views in your UI and you register controllers, then every view has to manage a notification (of which there may be more than one.) However, if you set up the shared datamodel to receive the notification you need only have a maximum of two notifications. One will go to the datamodel so the datamodel can update itself and then you can have the datamodel issue a generic notification for any listening views to update themselves from the datamodel.
Making your view controller dependent on the datamodel simplifies design greatly in all cases.
对象应该将自己注册为它感兴趣的通知的观察者。这样做的最佳时机是当对象感兴趣时，否则您必须在不需要通知时处理通知。
An object should register itself as an observer of the notifications it is interested in. The best time to do it is when the object becomes interested, otherwise you have to deal with notifications when you don't want them.