Week 3 - Observer Design Pattern

The Observer Design Pattern¶

Classification¶

Behavioral Design Pattern

Pattern Definition¶

Define a one-to-many dependency between object so that when one object changes state, all its dependents are notified and updated automatically.
In the observer pattern, the objects that watch on the state of another object are called Observers and the object that is being watched is called the Subject.

Representations¶

Mermaid Graph¶

classDiagram
    Subject <|.. ConcreteSubject: implements
    Observer <|.. ConcreteObserver: implements
    ConcreteSubject "0" --> "*" Observer : Association
    ConcreteObserver "0" --> "*" Subject : Association
    class Observer{
        <<interface>>
        +update(): void
        +setSubject(Subject): void
    }
    class ConcreteObserver{
        +update(): void
        +setSubject(Subject): void
    }
    class Subject{
        <<interface>>
        +registerObserver(Observer):void
        +unregisterObserver(Observer):void
        +notifyObservers():void
        +getState():Object
        +setState(Object):void
    }
    class ConcreteSubject{
        +registerObserver(Observer):void
        +unregisterObserver(Observer):void
        +notifyObservers():void
        +getState():Object
        +setState(Object):void
    }

UML¶

Usage¶

Useful when you are interested in the state of an object and want to get notified whenever there is any change.

Real World Usages¶

Model-View-Controller (MVC) frameworks use Observer: Model is the Subject and Views are Observers that can register to get notified of any change to the model.
Java Message Service (JMS) uses Observer+Mediator: To allow applications to subscribe and publish data to other applications.
Javascript Events use Observer: inputs as Subjects with functions as Listeners.
Many GUI libraries including Swing and JavaFX use Observer: Components are the Subject allowing add/remove listeners, which are the Observers.

Application to my Real World Application¶

Application: ETL Pipeline
Pattern Application: Observe the progress if the Payload through the Stages of a Pipeline
Breakdown: Subject is the Pipeline that will notify Progress observers at the beginning or ending of each stage. Progress observers will be notified of the input or output at each stage and be able to: Report statistical progress, Trigger other pipelines with observed output at a particular stage, thus allowing for threaded Pipeline runs.

Java Code Example¶

Observer Design Pattern

Main Take-Aways from the textbook¶

The Observer Pattern defines a one-to-many relationship between objects.
Subjects update Observers using a common interface.
Observers of any concrete type can participate in the pattern as long as they implement the Observer interface.
Observers are loosely coupled in that the Subject knows nothing about them, other than that they implement the Observer interface.
You can push or pull data from the Subject when using the pattern (pull is considered more “correct”).
The Observer Pattern is related to the Publish/Subscribe Pattern, which is for more complex situations with multiple Subjects and/or multiple message types.
The Observer Pattern is a commonly used pattern, and we’ll see it again when we learn about Model-View-Controller.

Main OO Principles of Observer Pattern¶

Strive for loosely coupled designs
- Subject knows very little about observers relying on its data.
Encapsulate what Varies
- The state of the Subject and number/type of Observers vary, and both are encapsulated in separate classes.
- We can add Observers dependent on the Subject without having to change the subject.
Program to an Interface not an Implementation
- Both Subject and Observer use interfaces allowing both to keep generic references in our concrete implementations. This lends to loose coupling.
Favor composition over inheritance
- The Subject maintains a List, which is composition, and the Observers maintain a reference to the Subject, which is also composition. No inheritance hierarchy exists.