Notifications or Observer pattern

pp159

The Notification pattern enables communication between objects without tight coupling. An object is able to broadcast information to any number of other objects without any specific information about the other objects. An instance of Cocoa's NSNotification class encapsulates the information to be broadcast. Objects that are interested in receiving the information register themselves with an instance of Cocoa's NSNotificationCenter class. Registered objects are called observers, and the Notification pattern is sometimes called the "Observer" pattern in other frameworks. Registered observer specify the types of communication desired.

The object that sends a message to a notification center doesn't need to know that observers exist or how many observers ultimately receive the notification. Similarly, the observers don't necessarily need to know where notifications originate.

 

Motivation

Use the Notification pattern to establish anonymous communication between objects at runtime. Within the Model View Controller design pattern, notification safely cross subsystem boundaries without tying the subsystems together.

Use the Notification pattern to broadcat messages. Notifications may be posted by any number of objects and received by any number of objects.  The Notification pattern enables one-to-many and many-to-many relationships between objects.

Use the Notification pattern with Cocoa's NSDistributedNotificationCenter calls to achieve simple asynchronous interprocess communication.

Use the Notification pattern when anonymous objects need to passively observe and react to important events. In contrast, use the Delegates pattern when anonymous objects need to actively influence events as they happen.

 

Solution

The Notification pattern is not unique to Cocoa, and a simple version can be readily implemented using Foundation classes along with the Anonymous Object, Heterogenous Containers, and Perform Selector patterns. 

MyNotification

Frist, create a MyNotification class that will fill a role similar to Cocoa's NSNotification class. Instances of the MyNotification class encapsulate information about notifications, as shown in the following code:

@class MyNotification : NSObject

{

　　NSString　　*name;　　//identifies the notification
　　id　　　　　　object;　　//an anonymous object
　　NSDictionary　　*infoDictionary;　　//arbitrary associated info
}

- (id)initWithName:(NSString *)aName object:(id)anObject

　　userInfo:(NSDictionary *)someUserInfo;



@property (readonly, copy) NSString *name;

@property (readonly, assign) id object;

@property (readobly, copy) NSDictionary *infoDictionary;



@end



@interface MyNotification ()

//Re-declare the properties so that their values can be set by methods

//wirhin the implementation of this class.

@property (readwrite, copy) NSString *name;

@property (readwrite, assign) id object;

@property (readwrite, copy) NSDictionary *infoDictionary;



@end



@implementation MyNotification

@synthesize name;

@synthesize object;

@synthesize infoDictionary



- (id)initWithName:(NSString *)aName object:(id)anObject

　　userInfo:(NSDictionary *)aomeUserInfo

{

　　[self setName:aName];

　　[self setObject:anObject];

　　[self setInfoDictionary:someUserInfo];



　　return self;

}



- (void)dealloc

{

　　[self setName:nil];

　　[self setObject:nil];

　　[self setInfoDictionary:nil];

　　[super dealloc];

}



@end

 

 

MyNotificationCenter

Instances of the MyNotificationCenter class store information about observers in a Heterogeneous Container called oberversDictionary. MyNotificationCenter is similar to Cocoa's NSNotificationCenter class.

@class MyNotificationCenter : NSObject

{

　　NSMutableDictionary　　*observersDictionary;

}

+ (id)defaultCenter;

-(void)addObserver: (id)notificationObserver
　　　　　　selector: (SEL)notificationSelector
　　　　　　    name: (NSString *)notificationName
　　　　　　  object: (id)objectOfInterest; 


- (void)removeObserver: (id)notificationObserver;

- (void)postNotification: (MyNotification *)aNotification;

- (void)postNotificaitonName: (NSString *)aName

　　　　　　　　　　　  object: (id)objectOfInterest
　　　　　　　　　　  userInfo: (NSDictionary *)someUserInfo;
@end

 

 

 

 

Examples in Cocoa

Will and Did

Will are used for notification that tell observers about something that is aboutto happen. Did are for notifications that tell observers about something that already happened.

 

Synchronous Versus Asynchronous

Synchronous means that when you post a notification with -postNotification: or any of the related NSNotificationCenter methods, the notification is delivered to all appropriate registered observers before -postNotification: returns control to your code.

When you need more coplex asynchronous behavior than just delaying a message, use Cocoa's NSNotificationQueue class. NSNotificationQueue instances implement an asynchronous First In First Out (FIFO) queue.

 

Consequences

The biggest weakness of the Notification pattern is that class designers must anticipate the need for notifications. There is a trade-off. Posting a notification takes some processor time even when there are no registered observers for the notification. It's not practical to post a notification for every single application state change. Therefore, designers must find a balance between too many and too few notifications.

The Delegates pattern is closely related to the Notification pattern. In fact, Cocoa classes use the Delegate pattern in many of the same cases that notifications are used.  As a general rule, use Notifications when there are potentially many objects that may observe the notification. Use Delegates pattern when exactly one object is given an opportunity to influence or react to change as they are happening.