What is the Observer Design Pattern?

The Observer Design Pattern is a behavioral design pattern that defines a one-to-many dependency between objects. When one object (the subject) changes state, all its dependents (observers) are notified and updated automatically. It primarily deals with the interaction and communication between objects, specifically focusing on how objects behave in response to changes in the state of other objects.

Note: Subjects are the objects that maintain and notify observers about changes in their state, while Observers are the entities that react to those changes.

Real-world analogy of the Observer Design Pattern

Let’s understand the observer design pattern through a real-world example:

magine a scenario where a weather station is observed by various smart devices. The weather station maintains a list of registered devices. Weather Station will update all the devices whenver there is change in the weather.

• Each of the devices are concrete observers and each have their ways to interpret and display the information.
• The Observer Design Pattern provides a flexible and scalable system where adding new devices or weather stations doesn’t disrupt the overall communication, providing real-time and location-specific weather updates to users.

Components of Observer Design Pattern

Below are the main components of Observer Design Pattern:

• Subject:
  • The subject maintains a list of observers (subscribers or listeners).
  • It Provides methods to register and unregister observers dynamically and defines a method to notify observers of changes in its state.
• Observer:
  • Observer defines an interface with an update method that concrete observers must implement and ensures a common or consistent way for concrete observers to receive updates from the subject.
• ConcreteSubject:
  • ConcreteSubjects are specific implementations of the subject. They hold the actual state or data that observers want to track. When this state changes, concrete subjects notify their observers.
  • For instance, if a weather station is the subject, specific weather stations in different locations would be concrete subjects.
• ConcreteObserver:
  • Concrete Observer implements the observer interface. They register with a concrete subject and react when notified of a state change.
  • When the subject’s state changes, the concrete observer’s update() method is invoked, allowing it to take appropriate actions.
  • For example, a weather app on your smartphone is a concrete observer that reacts to changes from a weather station.

Observer Design Pattern Example

To understand observer design pattern, lets take an example:

Consider a scenario where you have a weather monitoring system. Different parts of your application need to be updated when the weather conditions change.

Complete code for the above example

Below is the complete code for the above example:

Java

import java.util.ArrayList;
import java.util.List;

// Observer Interface
interface Observer {
    void update(String weather);
}

// Subject Interface
interface Subject {
    void addObserver(Observer observer);
    void removeObserver(Observer observer);
    void notifyObservers();
}

// ConcreteSubject Class
class WeatherStation implements Subject {
    private List<Observer> observers = new ArrayList<>();
    private String weather;

    @Override
    public void addObserver(Observer observer) {
        observers.add(observer);
    }

    @Override
    public void removeObserver(Observer observer) {
        observers.remove(observer);
    }

    @Override
    public void notifyObservers() {
        for (Observer observer : observers) {
            observer.update(weather);
        }
    }

    public void setWeather(String newWeather) {
        this.weather = newWeather;
        notifyObservers();
    }
}

// ConcreteObserver Class
class PhoneDisplay implements Observer {
    private String weather;

    @Override
    public void update(String weather) {
        this.weather = weather;
        display();
    }

    private void display() {
        System.out.println("Phone Display: Weather updated - " + weather);
    }
}

// ConcreteObserver Class
class TVDisplay implements Observer {
    private String weather;

    @Override
    public void update(String weather) {
        this.weather = weather;
        display();
    }

    private void display() {
        System.out.println("TV Display: Weather updated - " + weather);
    }
}

// Usage Class
public class WeatherApp {
    public static void main(String[] args) {
        WeatherStation weatherStation = new WeatherStation();

        Observer phoneDisplay = new PhoneDisplay();
        Observer tvDisplay = new TVDisplay();

        weatherStation.addObserver(phoneDisplay);
        weatherStation.addObserver(tvDisplay);

        // Simulating weather change
        weatherStation.setWeather("Sunny");

        // Output:
        // Phone Display: Weather updated - Sunny
        // TV Display: Weather updated - Sunny
    }
}

Output

Phone Display: Weather updated - Sunny
TV Display: Weather updated - Sunny

When to use the Observer Design Pattern?

Below is when to use observer design pattern:

• When you need one object to notify multiple others about changes.
• When you want to keep objects loosely connected, so they don’t rely on each other’s details.
• When you want observers to automatically respond to changes in the subject’s state.
• When you want to easily add or remove observers without changing the main subject.
• When you’re dealing with event systems that require various components to react without direct connections.

When not to use the Observer Design Pattern?

Below is when not to use observer design pattern:

• When the relationships between objects are simple and don’t require notifications.
• When performance is a concern, as many observers can lead to overhead during updates.
• When the subject and observers are tightly coupled, as it defeats the purpose of decoupling.
• When number of observers is fixed and won’t change over time.
• When the order of notifications is crucial, as observers may be notified in an unpredictable sequence.