Also, I don’t think bloggers were too rough on the Cocoa features. Brent and others pointed out some gotchas and limitations of the technologies, but I don’t think any of them meant: “these are bad technologies.” In fact, I remember some praise of bindings, and rightfully so.

@Stephane: The pattern you describe with the anchorman and the news is the Moderator pattern, not the Observer pattern. If that’s your model, then (I think) you would be correct to use NSNotificationCenter. In the Observer pattern, the observer actually cares about one specific subject (the person actually making the news in your example, as opposed to the anchorperson). My point was, in that model, NSNotificationCenter is not appropriate. Also note that the news example is a many-to-many relationship. Many people are making the news, and many people are listening to it.

@Nathan: I will admit I can be a bit dogmatic about design patterns, and anal about coding standards. You are correct that the notifications are their own design pattern. My point is that they are not the Observer pattern, completely, although they get used in that manner. I was trying to point out a better way (a implementation that was only the Observer pattern).

Although I don’t expect classes to police for incorrect use, it would be nice if they didn’t encourage it.

@Anonymous: I never said anyone was incompetent, nor was that my intent. My argument was simply: “there’s a better way to do this.”

I’m sorry that you dislike my writing style. I fully confess that I am an engineer and not a professional writer. I’m sorry that the fact that I identified things as “good” or “bad” annoyed you, but that is the way of the world. Some things really are “good” while others are “bad.”

As you might have noted, this is my personal blog, and the implicit implication is that everything here is my personal opinion. You are free to accept or reject my opinions at your whim, and it will not offend me in the least.

@igerard: Sorry to chase a rabbit here, but I’d like to have a minute with your initial comment: “Programming is not religious.”

People say this, and mean it, but can never do it. Programming is religious, and each person has their own little cult. Whether it is over whether programming is an art or science, or if inlining is really worth it, or if source control should be used, or the indention style that should be used. Each programmer has their own idiosyncrasies that they cling to, despite the lack of evidence, or even evidence to the contrary, that they are true.

Alright, rabbit chased.

Although NSNotificationCenter can be used to implement a one-to-many relationship, it is often not used that way (at least in the code I’ve seen), and it does not enforce this. Also, the syntax of its use (like I mentioned in the post) does not lend itself to the relationship of the objects.

@Brent: Thanks for pointing to the docs, but I already knew that (and mentioned it briefly in my post), and I believe you missed my point. As I stated in the post, although NSNotificationCenter will allow you to establish a one-to-many relationship, it allows many-to-many, and the common use appears to be many-to-many, even when the real relationship is one-to-many.

I will fully admit that I don’t know what the original designers intended. However, I would like to point out that sword cuts both ways: unless you have information that you didn’t mention, neither do you.

I also don’t think the original designers intended a pure Observer pattern. My point was that although it is not an Observer pattern, it is used in that function, and Apple has not provided an appropriate one-to-many Observer pattern in Cocoa (unless KVO is it).

As far as globals goes, you took my one comment and blew it _way_ out of proportion. I admit that was probably at least partially my fault because of my attempt at humor (note the “trademark” sign in my statement). I never said that all globals were bad, and should never be used. I, occasionally, will use singletons and local static variables. I even clarified this in one of my earlier comments. However, my point was, in a one-to-many Observer relationship, there is no need to have a global.

To your comment that singletons aren’t globals, I will have to disagree. You are correct that they will often encapsulate their member data, which makes them better that a global C struct. However, singletons share the same global access from any part of the code that proper globals do. This means they are open for being used from anywhere, which can produce much tighter coupling than necessary.

Globally available symbols are essential for software to work properly; the alternative to global visibility would be long chains of references, which would lead to the same thing. Every object graph has a root; relative to every other object in the graph, that object is “global”. And sometimes, you have to talk to the root object.

Open up XCode’s debugger and click on the globals disclosure triangle and check out the tremendously large number of global variables, without which, a lot of code would be much more obfuscated and difficult to use.

The problem with global variables goes back to C structures being shared around by everybody. Code all over an application could alter their contents, creating unmanageable complexity. Encapsulation solved that problem; globally available objects are not the same thing as global variables.

Sorry to be blatantly contradictory, but you are free to use NSNotificationCenter (either the default, or one of your own creation) in a one-to-many manner if you desire. you simply provide the object which you are observing. Optionally, you can omit the notification name and receive all notifications regarding the observed object. From the docs:

notificationName
The name of the notification for which to register the observer; that is, only notifications with this name are delivered to the observer. When nil, the notification center doesn’t use a notification’s name to decide whether to deliver it to the observer.

notificationSender
The object whose notifications the observer wants to receive; that is, only notifications sent by this sender are delivered to the observer. When nil, the notification center doesn’t use a notification’s sender to decide whether to deliver it to the observer.

–

In any case, regardless of the actual facts, but based on the ones you present, your argument in and of itself is, as pointed out by others, fundamentally flawed. You are trying to say that the designers of Foundation (and it wasn’t Apple, but NeXT) intended to implement a pattern and failed, whereas you have no way of knowing what they intended. You are merely assuming.

NSNotificationCenter allow to implement observable/observer relationship/behavior in a very easy way.

If you want to implement this pattern in a one to many relationship way it is easy with NSArray, selector, target, and category on NSObject to get code usable from everywhere in your class tree, not as clean as protocol but it does work.

You can even use NSInvocation which is an interesting object allowing more complexe signature for message targeted to the observer.

To make short, NSNotificationCenter is a compromise to get something very usable, genereic… I suspect that NSNotificationCenter use heavily Hash table, hence in some circumstance you can get poor performance, and then it is a good idea to make specialized instance of NSNotificationCenter.

I find it curious that you’re argument now involves the supposed incompetence of some nameless people. (Who are they ?) Would it not have been more honest if you had written:

“I read the Design Patterns book and thought NSNotificationCenter is exactly the observer pattern, but then I noticed…”

My response would be nicer, if you hadn’t written in this annoying preaching style. This is “good” this is “bad”. Apple’s work is “shoddy”. You’re doing a lot of posturing and preaching, but you have very little to back it up.

For me, NS[Distributed]NotificationCenter just works.

The thing that surprised me in this week’s ‘large projects’ discussion was how a number of high profile (== blogging) developers criticized some great Cocoa features. Notifications suddenly confuse the flow of control, KVO is ‘only for preferences’, bindings are ‘hidden in the nib’ and are to be avoided. Oh my… Let’s all agree that these are wonderful technologies that make our lives so much easier. And let’s remind ourselves that the _only_ effective way to remember how a program works is to read the _documentation you wrote when you created the code_… If you were lazy, don’t take it out on the framework, it can’t help it.

Which brings us to the sorry state of HeaderDoc ;-\

I thought I outlined a nice way to implement it at the end of the post. You simply aggregate the Observer or Subject object, which contains a pointer back to the real observer or subject. In Objective-C the Observer (or Subject) can simply forward the message invocations to the real object. There is a level indirection there, but its still quite usable. In fact I’ve seen this design used in C++ where there is multiple inheritance.

@Diederik: Unfortunately, I haven’t really used KVO, so I can’t really comment on them. I know some others have expressed displeasure with how they’re implemented.

@Patrick: Agreed, NSNotificationCenter doesn’t implement the observer pattern, that was my point. However, people (including from Apple) are using it in that manner. I agree, the way it is architected is useful, just not as an observer pattern.

Also, I’m not against singletons. I like them, and use them. As you say, there are times to use them, and times when they’re not appropriate. I’m saying when you want an observer pattern, they’re not appropriate.

@Anonymous: My point was people were using the NSNotificationCenter as if it were the observer pattern, and my point was it isn’t.

@Shawn: Yes, that is true. But I still think NSNotificationCenter shouldn’t be used in place of the observer pattern, when that’s appropriate. NSNotificationCenter still represents a many-to-many relationship, even when you use multiple of them.