On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote: > > 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.
I'm not really sure what you're talking about with "anonymous object that calls +defaultCenter." Every NSNotificationCenter call site gets a reference to the notification center by calling the class method. > > > 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. If you only ever use the default center, you never have to worry about which notification center to listen to. There is a very large gulf in software design between "one" and "many." Every time you want to cross that gulf you have to make decisions. More decisions lead to more bugs. > > > 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. How? You need to update the sender to send to the correct notification center. > > > 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, You already know that information. It's in the object property of the NSNotification object. > also, there is more than > one sender for the notification, so I would have add more code specific > to a number of objects. Then put it in the userInfo. That's what it's there for. > This way the receiver is coupled to the subclass No it's not. > 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! And when you're scratching your head wondering why you're not getting notifications delivered to your objects, because they're being sent to a different notification center than the one you're listening to… Either that or I'm sorely misunderstand how you propose to use subclasses of NSNotificationCenter. --Kyle Sluder _______________________________________________ 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
