Observer mode (Observer)

Observer mode (Observer): defines a one-to-many dependency, allowing multiple Observer objects to listen to a topic object at the same time. When the status of this topic object changes, it notifies all observer objects so that they can automatically update themselves. UML class diagram: analysis: The Observer class, abstract Observer, defines an interface for all the specific observers. When a notification is received, the updated interface is called an update interface. Abstract observers are generally implemented using an abstract class or an interface. The Update interface usually contains an Update method, which is called an Update method. Subject Class, which can be translated into a topic or abstract notification. It is generally implemented using an abstract class or an interface. It stores all references to the observer object in a aggregation, and each topic can have any number of observers. Abstract topic provides an interface to add and delete observer objects. The ConcreteSubject class is called a specific topic or a specific notification, and stores the relevant status into a specific observer object: when the internal status of a specific topic is changed, a notification is sent to all registered observers. A specific topic is usually implemented by a specific subclass. ConcreteObserver class, which implements the update interface required by the abstract observer role. So that the status of the topic can be consistent with that of the topic. A specific observer role can save a reference pointing to a specific topic object. A specific observer role is usually implemented by a specific subclass. Observer mode (Observer) Implementation: [csharp] using System; using System. collections. generic; using System. linq; using System. text; namespace Observer {/** Observer class, abstract Observer, define an interface for all specific observers. Update yourself when receiving notification of a topic * this interface is called the update interface. Abstract observers are generally implemented using an abstract class or an interface. The Update interface usually contains an * Update method, which is called the Update method. */Abstract class Observer {public abstract void Update () ;}/ ** Subject class, which can be translated as a topic or abstract notifier. It is generally implemented using an abstract class or an interface. * It stores all references to the observer object in one aggregation, and each topic can have any number of observers. * An abstract topic provides an interface for adding and deleting observer objects. */Abstract class Subject {private List <Observer> observers = new List <Observer> (); // Add the public void Attach (Observer observer) {observers. add (observer);} // remove the Observer public void Detach (observer) {observers. remove (observer);} // Notify public void Policy () {foreach (Observer o in observers) {o. update (); // notify each observer so that each observer modifies its own status.}/** the ConcreteSubject class is called a specific subject or a specific notification, save the relevant status to a specific observer object: * When the internal status of a subject changes, a notification is sent to all registered observers. A specific topic is usually implemented using a specific subclass. */Class ConcreteSubject: Subject {private string subjectState; public string getSubjectState () {return this. subjectState;} public void setSubjectState (string state) {this. subjectState = state ;}}/** ConcreteObserver class, which implements the update interface required by the abstract observer role. In this way, the status of * is in harmony with the status of the topic. A specific observer role can save a reference pointing to a specific topic object. A specific * observer role is usually implemented by a specific subclass. */Class ConcreteObserver: Observer {private string name; private string observerState; private ConcreteSubject cSubject; public ConcreteObserver (ConcreteSubject cSubject, string name) {this. cSubject = cSubject; this. name = name;} public ConcreteSubject getCSubject () {return this. cSubject;} public void setCSubject (ConcreteSubject cSubject) {this. cSubject = cSubject;} public override void Up Date () {this. observerState = this. cSubject. getSubjectState (); Console. writeLine ("The Observer {0} status is {1}", this. name, this. observerState); // throw new NotImplementedException () ;}} client: [csharp] using System; using System. collections. generic; using System. linq; using System. text; namespace Observer {// client code class Program {static void Main (string [] args) {ConcreteSubject cSubject = new ConcreteSubject (); CSubject. attach (new ConcreteObserver (cSubject, "X"); cSubject. attach (new ConcreteObserver (cSubject, "Y"); cSubject. attach (new ConcreteObserver (cSubject, "Z"); cSubject. setSubjectState ("ABC"); cSubject. Y (); Console. read () ;}} observer mode Summary: we know that it is a bad side to split a system into a series of collaborative classes, that is, to maintain consistency between related objects. We do not want to make all kinds of Close coupling to maintain consistency, which will cause inconvenience to maintenance, expansion and reuse. The key objects in the Observer mode are the topic Subject and the Observer. A Subject can have any number of observers dependent on it. Once the status of the Subject changes, all observers can be notified. When a Subject sends a notification, it does not need to know who is its observer. That is to say, it does not need to know who is the observer. However, no specific observer knows or needs to know the existence of other observers. When an object needs to change other objects at the same time, and it does not know how many objects are to be changed, the observer mode should be considered. In general, the work done by the observer mode is actually decoupling. Let both sides of coupling depend on abstraction rather than on specifics. So that changes on the other side will not be affected.