Observer | Cheat Sheet
Behavioral Pattern — Design Patterns Series
The Observer pattern is a very often and diversely used pattern — in software development as well as in real life. You keep an eye on things and automatically get all the changes without having to send a request all the time.
In real life, the pattern is comparable to notifications of a change or a new publication/release. If you are waiting for a discount on a certain appliance in a certain supermarket, you can be informed about it via newsletter without having to periodically check the state of the product. Another example would be when family members or friends have interesting news, they automatically contact you via phone or messenger to tell you about it.
The same applies to all social media channels — as soon as interesting messages appear, you are automatically informed via push notifications.
Real-life examples
- Social media notifications about updates
- Message orientated applications: HornetQ
- Keyboard and mouse events
- Newsletter and subscription principles
- Mapper in Enterprise Applications (Connects 2 subsystems that want to communicate with each other)
- Observables and Subjects with RxJS in Angular
Meaning
- Definition of a 1:n dependency between objects so that, after state changes of an object, all objects which dependent on it are notified and automatically updated
Applicability (suitable if …)
- An abstraction has two aspects and one depends on the other one (encapsulation of observers in different objects allows independent modification and reuse)
- The modification of one object requires the modification of other objects- it is not known how many
- An object needs to notify other objects (without knowing which objects are involved)
Assets and Drawbacks
- Independent modification, addition, or removal of subjects and observers
- Abstract coupling of subject and observer
- Support of broadcast communication (no specification of a recipient by the subject — automatic forwarding to all interested parties)
- Unexpected or incorrect updates (observers do not know other observers — modules that are not well-defined or orderly can lead to doubtful updates)
Example
The Observer pattern has two basic participants: the Subject and the Observer.
Different Observers can be registered to a Subject, which should be aware of changes in state (provision of an interface for connecting and disconnecting objects). The Subject itself knows all of its Observers and can be observed by any number of them.
The Observer defines an update interface for objects that need to be notified of changes in the state of a Subject.
In this example, we will simulate a server-client communication using the Observer pattern. A random number is passed to the Observer objects.
The Subject provides the possibility for different Observers to connect and receive updates on the randomly generated number. This simulates the server.
In addition to the ChannelServer, two clients are created that register with the Subject and receive updates regarding the random number. These are our two Observers:
Each time a new random number is generated, all Observers registered with the Subject are informed of the change of state:
Conclusion
Design Patterns are an important resource and base knowledge for every developer — they are very helpful for solving programmatic problems, help with consistent communication with other developers about system design, and serve as a significant introduction into object composition (besides inheritance) and dependency inversion.
Behavioral Patterns deal with algorithms and assignment of responsibilities to objects. Furthermore, they describe mutual communication patterns and grasp complex program sequences. They are therefore very well suited for use in areas where complicated code needs to be made readable and maintainable. Extensions are, in consequence, very good and quickly implementable.
