Introduction
This post gives a brief overview about the Observer Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The post aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.
What is the Observer Pattern?
According to Wikipedia, 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. It is mainly used to implement distributed event handling systems, in “event driven” software.
The pattern addresses these problems:
- A one-to-many dependency between objects should be defined without making the objects tightly coupled.
- It should be ensured that when one object changes state an open-ended number of dependent objects are updated automatically.
- It should be possible that one object can notify an open-ended number of other objects.
UML Diagram
The following diagram shows the Observer Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:
You can click on the diagram to open it online in Pladitor.
Diagram Sources
Here are the diagram sources:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
| @startuml
title Observer Pattern
class Subject <<interface>>
class Observer <<interface>>
class ConcreteSubject
class ConcreteObserver
Subject : registerObserver(Observer)
Subject : removeObserver(Observer)
Subject : notifyObservers()
Observer : update()
ConcreteObserver : update()
ConcreteObserver : // otherObserverMethods()
ConcreteSubject : registerObserver(Observer) {…}
ConcreteSubject : removeObserver(Observer) {…}
ConcreteSubject : notifyObservers() {…}
Subject “1” -right-> “*” Observer : “observers”
ConcreteSubject <-left- ConcreteObserver : “subject”
Subject <|– ConcreteSubject
Observer <|— ConcreteObserver
note left of Subject
The Subject Interface
Objects use this interface to register
as observers and also to remove
themselves from being observers.
end note
note left of ConcreteSubject
A concrete subject always
implements the Subject
interface. In addition to
the register and remove
methods, the concrete subject
implements a notifyObservers()
method that is used to update
all the current observers
whenever state changes.
end note
note bottom of ConcreteSubject
The conrete subject
may also have methods for
setting and getting its state.
end note
note bottom of ConcreteObserver
Concrete observers can be
any class that implements the
Observer interface. Each
observer registers with a concrete
subject to receive updates.
end note
note top of Observer
All potential observers need
to implement the Observer
interface. This interface
just has one method, update(),
that gets called when the
Subject’s state changes.
end note
@enduml
|
Open this diagram online with Pladitor.