* Use lombok, reformat, and optimize the code * Fix merge conflicts and some sonar issues Co-authored-by: va1m <va1m@email.com>
171 lines
5.1 KiB
Markdown
171 lines
5.1 KiB
Markdown
---
|
|
layout: pattern
|
|
title: Observer
|
|
folder: observer
|
|
permalink: /patterns/observer/
|
|
categories: Behavioral
|
|
tags:
|
|
- Gang Of Four
|
|
- Reactive
|
|
---
|
|
|
|
## Also known as
|
|
|
|
Dependents, Publish-Subscribe
|
|
|
|
## Intent
|
|
|
|
Define a one-to-many dependency between objects so that when one object changes state, all its
|
|
dependents are notified and updated automatically.
|
|
|
|
## Explanation
|
|
|
|
Real world example
|
|
|
|
> In a land far away lives the races of hobbits and orcs. Both of them are mostly outdoors so they
|
|
> closely follow the changes in weather. One could say that they are constantly observing the
|
|
> weather.
|
|
|
|
In plain words
|
|
|
|
> Register as an observer to receive state changes in the object.
|
|
|
|
Wikipedia says
|
|
|
|
> The observer pattern is a software design pattern in which an object, called the subject,
|
|
> maintains a list of its dependents, called observers, and notifies them automatically of any state
|
|
> changes, usually by calling one of their methods.
|
|
|
|
**Programmatic Example**
|
|
|
|
Let's first introduce the `WeatherObserver` interface and our races, `Orcs` and `Hobbits`.
|
|
|
|
```java
|
|
public interface WeatherObserver {
|
|
|
|
void update(WeatherType currentWeather);
|
|
}
|
|
|
|
@Slf4j
|
|
public class Orcs implements WeatherObserver {
|
|
|
|
@Override
|
|
public void update(WeatherType currentWeather) {
|
|
LOGGER.info("The orcs are facing " + currentWeather.getDescription() + " weather now");
|
|
}
|
|
}
|
|
|
|
@Slf4j
|
|
public class Hobbits implements WeatherObserver {
|
|
|
|
@Override
|
|
public void update(WeatherType currentWeather) {
|
|
switch (currentWeather) {
|
|
LOGGER.info("The hobbits are facing " + currentWeather.getDescription() + " weather now");
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
Then here's the `Weather` that is constantly changing.
|
|
|
|
```java
|
|
@Slf4j
|
|
public class Weather {
|
|
|
|
private WeatherType currentWeather;
|
|
private final List<WeatherObserver> observers;
|
|
|
|
public Weather() {
|
|
observers = new ArrayList<>();
|
|
currentWeather = WeatherType.SUNNY;
|
|
}
|
|
|
|
public void addObserver(WeatherObserver obs) {
|
|
observers.add(obs);
|
|
}
|
|
|
|
public void removeObserver(WeatherObserver obs) {
|
|
observers.remove(obs);
|
|
}
|
|
|
|
/**
|
|
* Makes time pass for weather.
|
|
*/
|
|
public void timePasses() {
|
|
var enumValues = WeatherType.values();
|
|
currentWeather = enumValues[(currentWeather.ordinal() + 1) % enumValues.length];
|
|
LOGGER.info("The weather changed to {}.", currentWeather);
|
|
notifyObservers();
|
|
}
|
|
|
|
private void notifyObservers() {
|
|
for (var obs : observers) {
|
|
obs.update(currentWeather);
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
Here's the full example in action.
|
|
|
|
```java
|
|
var weather = new Weather();
|
|
weather.addObserver(new Orcs());
|
|
weather.addObserver(new Hobbits());
|
|
weather.timePasses();
|
|
weather.timePasses();
|
|
weather.timePasses();
|
|
weather.timePasses();
|
|
```
|
|
|
|
Program output:
|
|
|
|
```
|
|
The weather changed to rainy.
|
|
The orcs are facing rainy weather now
|
|
The hobbits are facing rainy weather now
|
|
The weather changed to windy.
|
|
The orcs are facing windy weather now
|
|
The hobbits are facing windy weather now
|
|
The weather changed to cold.
|
|
The orcs are facing cold weather now
|
|
The hobbits are facing cold weather now
|
|
The weather changed to sunny.
|
|
The orcs are facing sunny weather now
|
|
The hobbits are facing sunny weather now
|
|
```
|
|
|
|
## Class diagram
|
|
|
|

|
|
|
|
## Applicability
|
|
|
|
Use the Observer pattern in any of the following situations:
|
|
|
|
* When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in
|
|
separate objects lets you vary and reuse them independently.
|
|
* When a change to one object requires changing others, and you don't know how many objects need to
|
|
be changed.
|
|
* When an object should be able to notify other objects without making assumptions about who these
|
|
objects are. In other words, you don't want these objects tightly coupled.
|
|
|
|
## Typical Use Case
|
|
|
|
* Changing in one object leads to a change in other objects.
|
|
|
|
## Real world examples
|
|
|
|
* [java.util.Observer](http://docs.oracle.com/javase/8/docs/api/java/util/Observer.html)
|
|
* [java.util.EventListener](http://docs.oracle.com/javase/8/docs/api/java/util/EventListener.html)
|
|
* [javax.servlet.http.HttpSessionBindingListener](http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSessionBindingListener.html)
|
|
* [RxJava](https://github.com/ReactiveX/RxJava)
|
|
|
|
## Credits
|
|
|
|
* [Design Patterns: Elements of Reusable Object-Oriented Software](https://www.amazon.com/gp/product/0201633612/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0201633612&linkCode=as2&tag=javadesignpat-20&linkId=675d49790ce11db99d90bde47f1aeb59)
|
|
* [Java Generics and Collections](https://www.amazon.com/gp/product/0596527756/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0596527756&linkCode=as2&tag=javadesignpat-20&linkId=246e5e2c26fe1c3ada6a70b15afcb195)
|
|
* [Head First Design Patterns: A Brain-Friendly Guide](https://www.amazon.com/gp/product/0596007124/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0596007124&linkCode=as2&tag=javadesignpat-20&linkId=6b8b6eea86021af6c8e3cd3fc382cb5b)
|
|
* [Refactoring to Patterns](https://www.amazon.com/gp/product/0321213351/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0321213351&linkCode=as2&tag=javadesignpat-20&linkId=2a76fcb387234bc71b1c61150b3cc3a7)
|