Let us first consider the following scenario to understand observer pattern.
Suppose we are building a cricket app that notifies viewers about the information such as current score, run rate etc. Suppose we have made two display elements CurrentScoreDisplay and AverageScoreDisplay. CricketData has all the data (runs, bowls etc.) and whenever data changes the display elements are notified with new data and they display the latest data accordingly.
Below is the java implementation of this design.
Current Score Display: Runs: 90 Wickets:2 Overs: 10.2 Average Score Display: Run Rate: 8.823529 PredictedScore: 441
Problems with above design:
- CricketData holds references to concrete display element objects even though it needs to call only the update method of these objects. It has access to too much additional information than it requires.
- This statement “currentScoreDisplay.update(runs,wickets,overs);” violates one of the most important design principle “Program to interfaces, not implementations.” as we are using concrete objects to share data rather than abstract interfaces.
- CricketData and display elements are tightly coupled.
- If in future another requirement comes in and we need another display element to be added we need to make changes to the non-varying part of our code(CricketData). This is definitely not a good design practice and application might not be able to handle changes and not easy to maintain.
How to avoid these problems?
Use Observer Pattern
To understand observer pattern, first you need to understand the subject and observer objects.
The relation between subject and observer can easily be understood as an analogy to magazine subscription.
- A magazine publisher(subject) is in the business and publishes magazines (data).
- If you(user of data/observer) are interested in the magazine you subscribe(register), and if a new edition is published it gets delivered to you.
- If you unsubscribe(unregister) you stop getting new editions.
- Publisher doesn’t know who you are and how you use the magazine, it just delivers it to you because you are a subscriber(loose coupling).
The Observer Pattern defines a one to many dependency between objects so that one object changes state, all of its dependents are notified and updated automatically.
- One to many dependency is between Subject(One) and Observer(Many).
- There is dependency as Observers themselves don’t have access to data. They are dependent on Subject to provide them data.
Image Source : Wikipedia
- Here Observer and Subject are interfaces(can be any abstract super type not necessarily java interface).
- All observers who need the data need to implement observer interface.
- notify() method in observer interface defines the action to be taken when the subject provides it data.
- The subject maintains an observerCollection which is simply the list of currently registered(subscribed) observers.
- registerObserver(observer) and unregisterObserver(observer) are methods to add and remove observers respectively.
- notifyObservers() is called when the data is changed and the observers need to be supplied with new data.
Provides a loosely coupled design between objects that interact. Loosely coupled objects are flexible with changing requirements. Here loose coupling means that the interacting objects should have less information about each other.
Observer pattern provides this loose coupling as:
- Subject only knows that observer implement Observer interface.Nothing more.
- There is no need to modify Subject to add or remove observers.
- We can reuse subject and observer classes independently of each other.
- Memory leaks caused by Lapsed listener problem because of explicit register and unregistering of observers.
When to use this pattern?
You should consider using this pattern in your application when multiple objects are dependent on the state of one object as it provides a neat and well tested design for the same.
Real Life Uses:
- It is heavily used in GUI toolkits and event listener. In java the button(subject) and onClickListener(observer) are modelled with observer pattern.
- Social media, RSS feeds, email subscription in which you have the option to follow or subscribe and you receive latest notification.
- All users of an app on play store gets notified if there is an update.
This article is contributed by Sulabh Kumar. If you like GeeksforGeeks and would like to contribute, you can also write an article and mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above
- Observer Pattern | Set 2 (Implementation)
- The Decorator Pattern | Set 2 (Introduction and Design)
- Strategy Pattern | Set 1 (Introduction)
- Singleton Design Pattern | Introduction
- Facade Design Pattern | Introduction
- Decorator Pattern | Set 1 (Background)
- Decorator Pattern | Set 3 (Coding the Design)
- Strategy Pattern | Set 2 (Implementation)
- Design Patterns | Set 1 (Introduction)
- Command Pattern
- Singleton Design Pattern | Implementation
- Adapter Pattern
- Iterator Pattern
- Curiously recurring template pattern (CRTP)
- Flyweight Design Pattern
- Implementing Iterator pattern of a single Linked List
- Java Singleton Design Pattern Practices with Examples
- How to prevent Singleton Pattern from Reflection, Serialization and Cloning?
- Proxy Design Pattern
- Composite Design Pattern
Improved By : RahulSindhav