Observer Design Pattern With Real World Example

Purpose

Observer design pattern in Java is very important pattern and as name suggest it’s used to observe things. Suppose you want to notify for change in a particular object than you observer that object and changes are notified to you. Object which is being observed is refereed as Subject and classes which observe subject are called Observer.

Play with an Example

I'm planning to buy an MI note 4 smartphone from flipkart. Unfortunately it seems the product was out of stock. But we can see a NOTIFY ME button over there instead of Buy Now

once the user enters his email address and click on the NOTIFY ME button, then the user will get a notification email from flipkart once the product is available on the cart. We can say this scenario is an example of Observer Design Pattern.

1. the end user register his email address for notification
2. Products are adding to the inventory, So changing the product status from 'Out of Stock' to 'Available'
3. Once the product status changed, Flipkart send the notification mail to the registered email Ids.

Here in the Observer Design Pattern point of view flipkart called subject and notification registered users called subscribers.

Lets Implement the same example in java.

Here we have two customers which registered for the notification are Anish (AnishCustomer.java) and Akhil (AkhilCustomer.java). Those peoples are registered for buying MI Note 6 mobile phone hence the selector is called FlipkartMINote6.java

Points to Remember

• Differentiate between the core (or independent) functionality and the optional (or dependent) functionality.
• Model the independent functionality with a "subject" abstraction.
• Model the dependent functionality with an "observer" hierarchy.
• The Subject is coupled only to the Observer base class.
• The client configures the number and type of Observers.
• Observers register themselves with the Subject.
• The Subject broadcasts events to all registered Observers.
• The Subject may "push" information at the Observers, or, the Observers may "pull" the information they need from the Subject.

Advanced Points

• Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers. Command normally specifies a sender-receiver connection with a subclass. Mediator has senders and receivers reference each other indirectly. Observer defines a very decoupled interface that allows for multiple receivers to be configured at run-time.
• Mediator and Observer are competing patterns. The difference between them is that Observer distributes communication by introducing "observer" and "subject" objects, whereas a Mediator object encapsulates the communication between other objects. We've found it easier to make reusable Observers and Subjects than to make reusable Mediators.
• On the other hand, Mediator can leverage Observer for dynamically registering colleagues and communicating with them.