Observer design pattern of C # design pattern (Observer design pattern)

I. Observer (OBSERVER) model

Observer mode is also called publish-subscribe (publish/subscribe) mode, model-view (model/view) mode, source-listener (Source/listener) mode, or dependent (dependents) mode.

The Observer pattern defines a one-to-many dependency that allows multiple observer objects to listen to one subject object at the same time. When the subject object changes in state, all the observer objects are notified so that they can automatically update themselves.

A software system often requires a change in the state of an object, and some other object changes accordingly. There are many design schemes to do this, but in order to make the system easy to reuse, we should choose the design scheme of low coupling degree. Reducing coupling between objects facilitates the reuse of systems, but at the same time designers need to enable these low coupling objects to maintain consistent action and ensure a high degree of collaboration (collaboration). The Observer model is the most important of the various designs that meet this requirement.

II. structure of the Observer model

The class diagram of the Observer pattern is as follows:

As you can see, there are the following roles in the implementation of this observer pattern:

Abstract theme (Subject) role: Theme roles keep all references to observational objects in one aggregation, and each subject can have any number of observers. Abstract topics provide an interface to add and remove observer objects, which are also called Abstract Observer (observable) roles, typically implemented with an abstract class or an interface.

Abstract observer (OBSERVER) role: Defines an interface for all specific observers, updating themselves when notified of the subject. This interface is called the update interface. Abstract observer roles are typically implemented with an abstract class or an interface. In this schematic implementation, the update interface contains only one method (the update () method), which is called the Update method.

Specific theme (ConcreteSubject) role: The state is deposited in a specific observer object, and all registered observers are notified when the internal state of the specific subject changes. The specific subject role is also called the specific observer role (concrete observable). Specific theme roles are usually implemented with a specific subclass.

The specific observer (CONCRETEOBSERVER) role: The State of the store and the topic itself. The specific reviewer role implements the update interface required by the abstract observer role to reconcile its own state with the state of the subject. If necessary, the specific reviewer role can save a reference to a specific subject object. The specific observer role is usually implemented with a specific subclass.

From the specific theme role to the abstract observer role of the composite relationship, on behalf of the specific Subject object can have any number of abstract observer object references. The use of abstract observers rather than specific observers means that subject objects do not need to know which concreteobserver types are referenced, but only abstract observer types. This makes it possible for a specific subject object to dynamically maintain a series of references to the observer object and to invoke the update () method shared by each observer when needed. This approach is called "for abstract programming".