What is Observer Pattern? It’s a way of notifying a group of objects about state changes in another object. The observers subscribe to receive notifications and the subject updates them when its state changes. The observer pattern achieves this while keeping the subscribers independent from the subject’s implementation. All of these objects remain loosely coupled.
- There is an object referred to as the subject. This subject sends notifications.
- The subject maintains a list of subscribed objects otherwise know as observers and notifies them of changes in its state.
- The observers need to subscribe to receive notifications from the subject.
- There is no tight coupling between the subject and the observers.
The observer allows subscribers to get notified about changes in another object without being tightly coupled to the sender.
Example:
Let's take the Auctioning system as an example. Here the subject is represented by the auctioneer. The bidders are the observers. The auctioneer updates the bidders when the new bid is accepted or when the reserve price has been met. The auctioneer is independent of the bidder.
Another example is the Notification system in software. There are apps which subscribe or observe certain events in the operating system. These events can be user-generated events or OS generated events. OS is the subject which on event generation notifies all the observers about the event.
The observer design pattern allows objects to subscribe to receive notifications about changes in another object. The Notification Center, also known as the subject, updates the observers when its state changes. The subject only knows that the receivers adopt the observer protocol. No further implementation details are needed. This loosely coupled design lets us easily add or remove observers. There is no need to modify the subject when creating new observer types. The only requirement is to make the new type conform to the Observer protocol.
Disadvantages: One of the potential issues is related to observers being kept alive by the subject. When an observer is about to be released, we should detach it from the subject. Otherwise, the subject will keep the observer alive and it’s going to update it long after it should have been released. This may cause undesired side effects and all kinds of weird bugs. Another pitfall with this pattern is allowing the observers and the subject to become tightly coupled. The observer pattern is implemented correctly if the subject only caused the observer’s update method.
Top comments (2)
"The observer achieves this while keeping the subscribers independent from the subject’s implementation."
That paragraph is not so clear. Did you mean subject rather then the observer? Because the observer is the subscriber toward the subject.
It must have been: "The observer pattern achieves this while keeping the subscribers independent from the subject’s implementation." would make more sense.
Thanks for pointing out the ambiguity!!