This is the ninth article on design patterns, in which all the design patterns I will encounter are summarized one by one. I will write down my thoughts on each design pattern and how we can flexibly apply these design patterns in practical work. Welcome your attention. In this article we will talk about the event-driven observer pattern that can help us implement it.
A brief introduction to the observer pattern
The observer pattern simply means that when one object changes, another object changes. It is a typical behavior pattern.
In previous articles, we introduced event-driven programming, and the Observer pattern is a typical event-driven programming model.
Class diagram of observer mode:
An introduction to the various characters in Observer mode:
- Abstract Topic roles: Abstract topics can be used to maintain individual registered observers, as well as the state of the topic
- Concrete topic roles: Used to implement notification methods in abstract topics that notify all registered subjects when state changes in a concrete topic
- Abstract observer: The abstraction of a class of observers
- Concrete observer: Implements the methods defined in the abstract observer to act upon notification of the topic
The concrete realization idea of observer mode
- Creation of an abstract theme
- Specific topic creation, the realization of notification
- Abstract observer creation, notice that the notification method needs to be triggered when changes occur within the object
- The specific observer was notified and did different things
The concrete implementation scheme of observer mode
Public abstract class Subject {// Observers registered to this Subject private List<Observer> observers = new ArrayList<Observer>(); // state private int state; Public void add(Observer Observer) {observers.add(Observer); Public void remove(Observer Observer) {observers.remove(Observer); } public int getState() { return state; } public void setState(int state) {this.state = state; notifyAllObservers(); } public void notifyAllObservers(); } public class ConcreteSubject extends Subject {public void notifyAllObservers() {for (Observer Observer: observers) { observer.response(); } // Public interface Observer {// Public interface Observer void response(); } public class ConcreteObserver1 implements Observer {public void Response () { System.out.println(" Concrete observer 1 reacts!" ); Public class ConcreteObserver2 implements Observer {public void Response () { System.out.println(" Concrete observer 2 reacts! ") ); }}Copy the code
Advantages and disadvantages of the observer model
advantages
- The subject and the observer are loosely coupled
- Can flexibly trigger each observer through the theme, do the corresponding operation
- Support one-to-many
disadvantages
- It takes a long time for the observation object (subject) to inform the observer (a large number of observers, or a complex observer operation)
- Cyclic dependencies between the observer and the object (subject) can cause the system to crash
- The observer can only know that the object of observation has changed, but not how.
The applicable scenarios of the observer pattern
- Objects have a one-to-many relationship. Changes in the state of one object affect other objects.
- You don’t need to know who the specific observer is, you just distribute the notification, and interested objects in the system automatically register to receive the notification.
- Trigger chains need to be established in the system to form a chain trigger mechanism that allows events to be notified across domains (across both observer types).
Summary of observer model
The observer mode is also a topic subscription mode. Interested observers subscribe to the topic, and the changes of the topic will be automatically notified to each observer. In this way, we can give some business logic touch to some events to trigger, which is called event-driven. Those interested in event-driven can read my article at juejin.cn/post/703006… Event-driven program design for us has a great guiding role, the application is also very wide.