Observer Design Pattern

An observer design pattern is a behavioral design pattern where objects are represented as observers that wait for an event to trigger. When the new event is triggered, the multiple observers catch these events.

The event source (or object) attaches to the subject. Whenever the change is performed in the subject, it is notified by the observer. It follows the one to many approaches between the objects so that one change in the subject will reflect in all of its dependents and be updated automatically.

Let's understand the above concept using the real-world example.

If we are newspaper or magazine subscriber, we don't need to go the store to get the news. We get the newspaper at home. If there is a new update available, the publisher sends it directly to our mailbox right after publication.

The publisher has the complete information regarding the subscriber. The subscriber can stop the publisher's service if it doesn't match with their interest.

Problem without using Observer Design Pattern

Imagine a customer is interested in a particular product (suppose a new mobile) that is not launched yet. But, it will be available in the store very soon so that customers could visit the store regularly and check the availability. But these visits would pointless because the product is still on the way.

Instead of doing this, the store could send several emails, but it will bother those who are not interested in the new product.

Here, the two problems arise: Either the customer wastes their time checking product availability, or the emails could bother by notifying the wrong customer.

Solution Using Observe Method

The objects that contain some interesting information are represented as the subject. It notifies the other objects to change to its state is known as the publisher. All the other objects that want to track changes to the publisher's state are called subscribers.

In the observer method, the publisher class consists of the subscription method so that each object can subscribe and unsubscribe to the event that is occurring by that publisher. This mechanism may seem slightly hard, but it is not as complicated as it sounds. The publisher-subscriber mechanism consists of the following methods.

• A list of references to the subscriber objects.
• Various public methods provide the facility to add and remove a subscriber from the list.

With the observer method's help, whenever any event takes place to the publisher, it directly transfers to the subscriber and calls the exact notification methods on their objects.

An application might have several subscriber classes willing to track the events from the same publisher class. But publishers cannot attach to all of these subscriber classes.

A common interface is implemented by all subscribers and publishers to use that interface to communicate with subscribers. The interface should declare the notification method, and this method contains the set of the parameter that the publisher can use to pass some data along with the notification.

We can modify the interface to make compatible for the all subscriber to work with the different types of publishers. We only need to specify a few subscribe methods.

Implementation of Observer Design Pattern

Let's understand the following code of snippet.

Example -

Output:

Current Task Downloading
Working_Class running: 1 (1)
Working_Class running: 1 (1)
Working_Class running: 1 (1)
Task CompletedTask CompletedTask Completed
Working_Class running: 2 (5)
Working_Class running: 2 (5)
Working_Class running: 2 (5)
Task Completed
Task Completed
Working_Class running: 3 (5)
Task Completed
Working_Class running: 3 (5)
Working_Class running: 3 (5)
Task CompletedTask Completed

Working_Class running: 4 (5)Working_Class running: 4 (5)Task Completed

Working_Class running: 4 (5)
Task CompletedTask Completed
Working_Class running: 5 (5)

Working_Class running: 5 (5)
Task Completed
Working_Class running: 5 (5)
Task Completed
Task Completed
Task Completed

Explanation -

In the above code, we explained the way of downloading a result where each object is treated as the observer.

Advantages of Observer Design Pattern

Following are some advantages of the observer design pattern.

• It is quite flexible to set up the relationship at runtime between the objects.
• With the Open/Closed Principle's help, we can introduce the new subscriber class without making a change in the publisher's code.
• This method carefully describes the coupling existing between the objects and the observer.

Disadvantages of Observer Design Pattern

Following are some disadvantages of the observer design pattern.

• The observer method has a risk to implement. If it is not implemented carefully, it will be the cause of large complexity code.
• The main disadvantage of the observer design pattern that subscribers are notified in random order.
• There is also a memory leakage problem in the observer design pattern because of the observer's explicit register and unregistering.

Applicability

• The observer method should be used if there are multiple dependencies on the state of one object. It follows the one to many dependencies, which means any change in the object state will reflect the attached object (in case of loose coupling).
• This method is used to send notifications, emails, messages etc. When we subscribe to any particular website, we notify you of any new events on that website.
• The object should be coupled tightly. If there is loose coupling in objects, the change in one state will reflect in another object.
• The subscriber list is dynamic, which means subscribers can join and drop the subscription when they want.