Definition of observer pattern
Definition: Defines a one-to-many dependency between objects so that whenever an object changes state, all dependent objects are notified and automatically updated
In layman’s terms, when a class meets a condition, it calls a set of defined methods
Its class diagram is as follows:
Four of the characters:
- Subject observed: Defines the responsibilities that the observed must fulfill. It must be able to dynamically add or remove the observed. It is generally an abstract class or an implementation class that does only what it must do as an observed: manage and inform the observer
- Observer: After receiving the message, the Observer performs the Update operation and processes the received message
- ConcreteSubject Concreteobserved: Defines the observed’s own business logic and defines which events are notified
- ConcreteObserver: Each observer reacts differently when receiving a message, and each observer has its own business logic
Observed abstract class code:
Specific observed code:
Observer interface code:
Specific observer code:
The scenarios are as follows:
Application of the observer pattern
Advantages of observer mode:
- There is abstract coupling between observer and other observer. Designed this way, it is easy to expand both by adding observers and being observed
- Establish a trigger mechanism.
Disadvantages of the observer model:
The observer mode needs to consider concurrency efficiency and operation efficiency, one observed, multiple observers, development and debugging will be more complex, and in Java, message notification is executed sequentially, one observer is jammed, which will affect the overall execution efficiency. In this case, an asynchronous approach is generally considered
Usage scenarios of observer mode:
- Associative behavior scenarios. Associative behavior is separable rather than “composed” relationships
- Time multi-level triggering scenario
- Message exchange scenarios across systems
Considerations for observer mode
1. The problem of broadcast chain
An observer can have dual identities, both observer and observed. Once the chain is established, this logic is complicated and very difficult to maintain. According to the rule of thumb, in an observer mode, at most one object can be both the observer and the observed, that is, the message can be forwarded at most once, which is relatively easy to control.
The biggest difference between the observer mode and the responsibility chain mode is that the message of the observer broadcast chain changes at any time in the process of transmission. It is a message structure negotiated by two adjacent nodes. However, the responsibility chain mode basically keeps the message immutable in the process of message transmission, and only modifies the original message if it needs to be changed
2. Handle the problem asynchronously
What if there are a lot of observers, and it takes a long time to process something? What if it’s asynchronous, because it’s about thread safety and queues
Extensions to the observer mode
1. Observer mode in the Java world
In Java, java.util.Observable implements the Observable function and inherits it directly from the Observer. Java.util.Observer is a written Observer interface
2. Real observer mode in the project
- Message communication between observer and observed. The change of the observed state will trigger an action of the observer and send a message to the observer. In practice, the general practice is as follows: The update method in the observer takes two parameters, one is the observed and the other is a Data Transfer Object (DTO). DTO is usually a pure JavaBean generated by the observed. Of course, if remote transmission is considered, Generally, messages are delivered in XML format
- Observer response mode. If the observer is too late to respond, the observed time is lengthened. How do observers respond quickly? There are two ways: one is to use multithreading technology, which is commonly known as asynchronous architecture; The second is caching technology.
- The observed tries to be the boss. Consider flexibility in the design, otherwise it will increase the observer’s business logic, generally do this, implement an overload of the observed business logic doSomething method, for example, add a doSomething(Boolean isNotifyObs) method, Decide whether to notify the observer, rather than decide whether to consume the message when it reaches the observer
Examples of the Observer model in real projects and life:
- For example, to create a new file in a directory, this action tells the directory manager to add the directory and the disk manager to reduce the space by 1Kb, where “file” is the observed and “directory manager” and “disk Manager” are the observers
- Cat and mouse games. When the cat mews in the night, the mice run away and wake up their sleeping owners. In this case, the “cat” is the observed, while the mouse and man are the observers
- Withdraw money from ATM. What events will be triggered when you withdraw money from ATM machine and enter wrong password for many times, and the card will be swallowed by ATM? First, the camera takes continuous quick shots; second, it informs the monitoring system that card swallowing occurs; third, it initializes the ATM screen and returns to the original state. Normally the first two actions are done in observer mode, and the last action is done as an exception
- Radio radio. When a radio is broadcasting, one radio can be turned on to listen, or two radios can be turned on to listen. The radio is the observed, and the radio is the observer