Note: I have transferred this blog from my old blog site: http://dcarapic.blogspot.com/ so I am reposting most of the stuff from there
Wikipedia (at the time of this writing) defines Observer pattern as following:
The Observer pattern (a subset of the asynchronous publish/subscribe pattern) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called Observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
MSDN defines Events (I refer to it later as 'eventing system') as:
Events enable a class or object to notify other classes or objects when something of interest occurs. The class that sends (or raises) the event is called the publisher and the classes that receive (or handle) the event are called subscribers.
.NET eventing system is nothing else then an implementation of an Observer pattern. The subject (type that defines an event) raises the event to notify the Observer (class which adds a handler to the event) that something has occurred.
Having the Observer pattern integrated into the language is a great thing which enables the developer to easily add notifications about object changes. However there are cases where this kind of a system is not sufficient and may lead to poorly designed code if you use it.
The .NET eventing system has the following drawbacks:
- You must define each 'change' as a separate event. Although there are some events which go around this by trying to be 'generic' (such as
INotifyPropertyChanged.PropertyChanged) they are usually not elegant and seem more like a workaround. - You should define each event as
EventHandler(orEventHandler<>). This is not mandatory as CLR allows you to define events of any method signature but if you plan on being CLS compliant and not getting compiler warnings then you usually should follow this convention.
In most cases these drawbacks are not serious and they do not affect your code quality that much. But there are some cases (especially when you have objects where there are lots of changes of various types) where the eventing system is just not good enough. For such cases you should build you own custom Observer pattern.
Building you own Observer pattern is quite simple and can be expressed in these few steps:
- Select the type which will be the subject (lets call it Subject)
- Define the changes that this type will expose
- Create a new interface which will define methods that represent the changes of the Subject (for example
ISubjectObserver) - Create a new interface method for each change (for example
OnSubjectNameChanged,OnSubjectTypeChanged,OnSubjectDetailLineAddedetc.) with parameters which are suitable for each notification (old value, new value, added detail object etc.) - Create a new type which will represent the Observer (lets call it
Observer) - Have it implement the new interface (
public class Observer: ISubjectObserver) - Implement the methods of the interface
- Add two methods to the Subject type which will be used to register/unregister an Observer (
RegisterSubjectObserver(ISubject**Observer**),UnRegisterSubjectObserver(ISubjectObserver*)`
Looks simple, and it is. If you are reading this you are probably thinking "hey, I know how to do all this". Well that might be true but developers sometimes forget to think about alternate ways to do something and this might give you another way of looking at things when designing your applications.