Brent Simmons makes some excellent points in his latest post - and he got me thinking. I like his recommendations about Notifications and KVO, and when to use them. What he says about Notifications is right on:

It’s difficult, when doing research, to know what’s going to happen when I encounter a notification-send… Another thing I do - which may sound like heresy - is just to admit that class x and y know about each other.

That is definitely NOT heresy! Using Notifications just to prevent two objects from talking directly to each other is a bad idea if those two objects should know about each other. Notifications work well when the sender doesn’t care about most aspects of the receiver. In fact, the only thing a Notification sender cares about is sending the message - it doesn’t want to know anything else about the receiver, the number of receivers, the types of the receivers, the interface(s) or methods on the receiver, and it especially doesn’t want to do any receiver management. That’s a VERY loose relationship - barely a first date! Are there many objects in your code that talk to each other, but meet the above criteria? There shouldn’t be many. In relationship terms, Notifications are like a good crush.

On the other hand, Brent follows that above quote with a small code example:

[[SomeClass sharedController] updateStuff]

That code scares me almost as much as notifications, but for the opposite reason. Using singleton classes basically makes a global variable, and overuse of shared singletones creates connections between lots of objects without describing an actual relationship between two objects. Does object X need to call methods on Y? Why? When? In MVC terms, most of the projects that I’ve seen that overuse the singleton pattern are abusing the C - instead of specific relationships, they create the singletons that float around, dating any old object, but never having a relationship. Unless you truly have objects that are utilities, free agents, no relationships, then you should see as few singletones as you do Notifications. In relationshiop terms, a singleton is a bachelor, a cheater… fun, and sometimes useful, but often dangerous.

Besides Notifications and singletons, KVO implies yet another kind of relationship - one that’s more intimate than a Notification and more specific than a singleton. KVO is all about specific properties of an object, and unlike Notifications, KVO implies knowing more about the type of the object, its ivars, and its method interface. Use KVO when that relationship applies to your objects: anywhere that another object knows specific details about the sender - possibly a similar class in a related area of the application, or a partner in the MVC pattern.

The more I code, the more I realize that the projects and code I’m happiest with are the ones that best describe in code the conceptual relationships between the objects that make up the code. As projects get large and complicated, patterns don’t always fit the small details of a feature or requirement. In those situations, I often end up writing code or using a pattern that also doesn’t exactly fit. But if I focus on explicitly describing the object relationships as I go, I usually have an easier time using that code later on.

Brent mentions many more tips than the Notification, singleton and KVO ones above - so definitely check it out.

Update: Daniel Jalkut weighs in here.

Update: Rentszch weighs in, too.