Observer pattern to ensure consistency between the subject and several observers.
Overview
sometimes called publish-subscribe subscribe> mode, model-view view> mode, source-listener listener> mode, or slave mode
This pattern is often used to implement an event-handling system
Specific environment
- When one object changes and some other objects change
- Relatively independent between actively changing objects and passively changing objects for reuse and maintenance
A class of questions
A system that consists of an object and several collaboration objects, while avoiding the coupling of these objects to each other
Solution Solutions
- Abstract theme Roles
- Specific theme Roles
- Abstract Observer role
- Specific observer roles
Abstract theme Roles
generally implemented by interfaces or abstract classes
Register a set of references that have several abstract observers
At the same time, the ability to delete the abstract observer, and change itself, notify the observer to make corresponding changes
Specific theme Roles
Abstract theme roles are generally implemented by specific subclasses with their own state
Abstract Observer role
generally implemented by interfaces or abstract classes
Define the behavior specification for all specific observers
and define methods, receive notifications and update their status
Specific observer roles
The abstract observer role is generally implemented by a specific subclass, with its own state, which changes with the subject state.
Push models and pull models
In the observer pattern, it is also divided into:
- Push model
The subject object pushes the details of the topic to the observer, and the information that is pushed is usually all or part of the data of the subject object, regardless of whether or not the observer needs them.
- Pull model
Subject object When notifying the observer, only a small amount of information is passed
If the observer needs more specific information, the Observer takes the initiative to get to the subject object, which is equivalent to the observer pulling data from the subject object
In the general implementation of this model, the subject object itself is passed to the observer through the Update method
So that when the observer needs to get the data, it can use this reference to get the
Comparison of two implementation methods
The push model is the assumption that the subject object knows the data that the observer needs;
While the pull model is the subject object does not know what the observer specifically needs data, there is no way, simply pass itself to the observer, let the observer himself to the value of the need
Pushing a model may make it difficult to reuse the observer object because the Observer's Update method is a parameter that is defined as needed, and may not be able to take into account the unused usage. This means that new update methods may be available when new situations arise, or simply re-implement the observer;
The pull model does not cause this situation, because the parameter of the Update method under the pull model is the subject object itself, which is basically the largest collection of data that can be passed by the subject object, and can be adapted to the needs of various situations basically.
Observer interfaces and Observable classes in Java
observer Interface: Viewer
observable class: The subject, that is, the person being observed
by inheriting or implementing them, you can quickly implement the observer pattern, and thread-safe
In addition, these two types use a pull model
Reference
The observer pattern of Java and patterns, Java_my_life
Understanding Design Patterns (Viewer)