Observer model
The Observer pattern (also known as Publish/Subscribe) is one of the behavioral patterns that defines a one-to-many dependency that allows multiple observer objects to listen on a subject object at the same time. The topic object notifies all observer objects of state changes so that they can update themselves automatically
Take a chestnut
We’ve all followed a certain celebrity on Sina Weibo, and every time the celebrity posts an update, his fans will know. Let’s use a graph to show their relationship.
The star posted a post on Sina Weibo saying he can sing, rap and more. And then his fans will know. From this example, we can see that there are two kinds of people, the first is the star, the second is the fan. Language translated into design patterns is subject and observer.
Our star’s micro-blog is equivalent to a theme, and fans are observers, observing the stars’ dynamics at any time. But stars have the right to let you pay attention to, also have the right to screen you. Now let’s look at it from a class diagram perspective
(1) Abstract topic: It stores all observer objects in a collection, which can have any number of observers. Abstract topic provides an interface for adding and deleting observer objects. It means that stars save all their fans in one account, and there is no limit to the number of fans. They can add fans or block fans. (2) ConcreteSubject: Concrete topic. This role stores the state in the concrete observer object and notifies all registered observers when the internal state of the concrete topic changes. It means that as soon as our stars get updates, they send them to their fans. (3) Observer: Abstract Observer, is an abstract class of Observer, which defines an update interface to update itself when notified of changes to the topic. This is the abstraction of all our fans. (4) ConcrereObserver: A concrete observer, which implements an update interface defined by an abstract observer to update its status when notified of subject changes. Be specific to each fan. The observer model is relatively simple, which is an example of fans following stars.
The code implements the observer pattern
Let’s go back to the example above to explain this example.
Step 1: Define an abstract Observer: a fan of the abstract
Step 2: concreteObserver: Concrete fans
Step 3: Define abstract Subject: Abstract star
Step 4: ConcreteSubject: Concrete stars
Analysis observer model
The main advantage of observer mode is that it can realize the separation of presentation layer and data logic layer, and establish an abstract coupling between observation object and observer, supporting broadcast communication. Its main drawback is that if an observable object, there are a lot of direct and indirect observer will all observers notice to spend a lot of time, and if you have any circular dependencies between the observer and the observed target, observe the target cycle will trigger their calls, could lead to a system crash. In fact, there is another thing we need to know. In the above example, we will find that the fans’ news is actually pushed by the stars. There is also an observer mode, that is, our fans take the initiative to get the news. (1) Push model: The topic object pushes the details of the topic to the observer, whether it is needed or not. (2) Pull model: The topic object transmits only a small amount of information when notifying the observer. If the observer needs more specific information, it is up to the observer to go to the subject object and get it