Observer Design Pattern explained in 2 minutes

Practical guide to explain Observer Design Pattern

Photo by Sergey Semin on Unsplash

Problem Statement

Imagine, you have a pool of workers and a set of jobs that need execution. How are you going to model it?

class Job {
    List<Worker> workers = new ArrayList<>();
    
    public void executeJob() {
        workers.forEach(worker -> worker.execute(this))
    }
}

The simplest strategy is to pass a list of workers to the Job and then invoke them one by one during execution.

The downside of this approach is that it tightly couples two different concepts — job and its execution together in the same class. It’s assigning multiple responsibilities to the same class which violates SRP (Single Responsibility Principle).

Observer Design Pattern can simplify this solution!

public record Job(String jobId) {
}

public interface Observer<T> {
    void update(T data);
}

public interface Subject<T> {
    boolean addObserver(Observer<T> observer);

    boolean removeObserver(Observer<T> observer);

    void notifyObservers(T data);
}

public class JobDispatcher implements Subject<Job> {
    Set<Observer<Job>> observers = new HashSet<>();

    @Override
    public boolean addObserver(Observer<Job> observer) {
        return observers.add(observer);
    }

    @Override
    public boolean removeObserver(Observer<Job> observer) {
        return observers.remove(observer);
    }

    @Override
    public void notifyObservers(Job job) {
        observers.forEach(observer -> observer.update(job));
    }
}

public class JobExecutor implements Observer<Job> {
    UUID uuid;

    public JobExecutor() {
        uuid = UUID.randomUUID();
    }

    @Override
    public void update(Job data) {
        System.out.println(uuid + " is executing jobId " + data.jobId());
    }
}

public class Main {
    public static void main(String[] args) {
        testObserver();
    }

    public static void testObserver() {
        JobExecutor executor1 = new JobExecutor();
        JobExecutor executor2 = new JobExecutor();
        JobDispatcher jobDispatcher = new JobDispatcher();
        jobDispatcher.addObserver(executor1);
        jobDispatcher.addObserver(executor2);
        jobDispatcher.notifyObservers(new Job("job1"));

        jobDispatcher.removeObserver(executor1);
        jobDispatcher.notifyObservers(new Job("job2"));
    }
}

// Output
3139088c-07eb-4f92-92da-0fb3af53b6be is executing jobId job1
fea0bf8a-6b2e-413f-9ae9-4a286b142798 is executing jobId job1
fea0bf8a-6b2e-413f-9ae9-4a286b142798 is executing jobId job2

We have created two new interfaces, Observer and the Subject. The sole responsibility of the Observer is to act when a subject is modified. The subject keeps track of the list of observers and decides how/when to invoke them when it changes.

What’s the benefit?

• Adheres to SRP — Each class has one responsibility and is decoupled from another. The logic of execution can change without impacting the subject.

What’s the drawback?

• This design pattern is very similar to the Publisher/Consumer problem and hence it suffers from all its issues as well. In a production ready code, we would have to be agnostic of various conditions like how to deal with slow observers, backpressure propagation and task backlog management.

To learn more about me and discover additional insights on design patterns, system design and distributed databases, visit https://snehasishroy.com. You can also explore my Medium articles by visiting https://snehasishroy.medium.com