On 12 Sep 2013, at 17:58, Kyle Sluder <k...@ksluder.com> wrote: > Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil in > horror. > > First, NSNotificationCenter is a singleton. If you subclass it, you now must > have two notification centers.
It has the facility to have different Centers (default etc.), so it's not a true singleton, although I see what you mean. It doesn't have to be a subclass, just a class, but I think that either subclassing NSNotificationCenter or have a Category on it is better than having an anonymous object that calls [NSNotificationCenter defaultCenter], since at least it keeps all the notification code in one place. > Which one is the right one to subscribe to? Do you only move notifications > over to it that need to be cached? Or all related notifications as well? That problem exists anyway, you have to know it's the default center for instance. This is just using related ones by virtue of the fact that the rest of the code doesn't use the subclass, only those that need to. > This decision needs to be made on both ends of the notification. No, just at the receiver, the sender need do nothing, in fact its unchanged. > Congratulations, you have taken an object whose purpose is to promote loose > coupling, and successfully turned it into a tool that tightly couples the > sender and the listener. > > The correct approach does not put the cache in the notification center, but > rather in the sender or the userInfo dictionary. > > --Kyle Sluder This is just not true! It's the opposite as far as I can see. If I hold the the data at the sender then from the receiver I have to "know" who sent the Notification in order to retrieve it, also, there is more than one sender for the notification, so I would have add more code specific to a number of objects. This way the receiver is coupled to the subclass which is not a lot different that the base class, and it could be coupled to that anyway, so I don't see the problem. it works like a treat and is really easy to adapt so I'd say the proof is in the pudding! All the Best Dave _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
