Observer Design Pattern

Observer design pattern is a behavioral pattern. It is applicable when one-to-many relationship is demanded. One-to-many relationship means many objects are dependent on a single object. Dependency clause can be understood as when object changes its state, changes are notified to dependents. This approach is called Push Model. Dependents can also observe if target object is changed and therefore they can incorporate changes themselves. This approach is known as Pull Model. 

The question which arises is that when we talk about dependency, as per good design principle, we need to have minimum coupling among classes i.e. decouple as much possible to reduce dependencies.

Let’s see how observer pattern can help us achieve this behavior, but before we delve ourselves in to details, we shall define our terminology.

Subject / Observable: The real world object whose state is observed. A subject may have any number of dependent objects.

Observers: Dependent objects are referred as observers. All observers are notified whenever a change occurs in subject.

Observer pattern is also known as Publish Subscribe; subject being the publisher of the changes in state and observers being subscribers of the changes in publisher’s state.


There are plenty of example describing observer pattern. I will list a few of them.

  • Feeds: One can subscribe to feeds and get notified whenever there is new news. Facebook also works on publish subscriber principle. You subscribe to celebrity, product feeds by liking their Facebook page and get notified when they publish anything on their Facebook pages.
  • Stock Exchange: Customers subscribe to stocks of many companies and get notified whenever there is a change in their share price.
  • Excel: charts, worksheet and tables are subscribers of the underline application data entered by user. They change their representation depending on changes in the user data.

In my case, I shall take example of feeds. In a client with several possibilities of configuring feeds from different companies e.g. Yahoo, C-SharpCorner and etc. Yahoo users would subscribe to Yahoo feeds and apple users to Apple news feeds and so on. Nevertheless, Users can unsubscribe whenever they want.


In the UML diagram below, FeedObservable is an interface for attaching and detaching observer objects.

Concrete classes e.g. CsharpBlogFeeds, JavaBlogFeeds, AppleNewsFeed, stores state of interest to ConcreteObservers objects and sends a notification to its observers when its state changes.

IObserver defines an updating interface for objects that should be notified of changes in subject.

YahooUsers, GmailUsers and OtherUsers maintain a reference to a ConcreteSubject object and also store state that should be consistent with the subject.

Figure 1: Yahoo

A point to be noted is that in order to decouple subjects and observers, we need to separate the subject from its observers in such a way that adding new observers will be transparent for the subject. Therefore, we provide Add and remove method in FeedObservable interface. These methods help observers to subscribe and unsubscribe to feeds.

To summarize, subject is only aware about a list of observers conforming to an abstract class. The subject does not have any inkling about concrete observers. Thus both concrete subjects and concrete observers are decoupled.The pattern is useful mostly for dynamic relationships between objects. A new observer can be hooked to an observable during program execution, then unhook it later (e.g. remove the window from the list of observers when the user closes it).