Design Mode learning notes-Observer mode, design mode learning notes

Design Mode learning notes-Observer mode (transfer), design mode learning notes

Http://www.cnblogs.com/wangjq/archive/2012/07/12/2587966.html

1. Overview

It is sometimes called the publish/subscribe mode. The observer mode 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.

2. Solved problems

Splitting a system into a class that cooperates with each other has a bad side effect, that is, maintaining 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 observer solves such Coupling Relationships.

3. Role in the Mode

3.1 abstract topic: It stores reference of all observer objects in one aggregation. Each topic can have any number of observers. Abstract topic provides an interface to add and delete observer objects.

3.2 ConcreteSubject: stores the relevant status into a specific observer object, and sends a notification to all registered observers when the status of the subject changes.

3.3 abstract Observer: defines an interface for all specific observers and updates themselves when receiving topic notifications.

3.4 ConcreteObserver: implements the update interface required by the abstract observer role to coordinate its status with the topic status.

4. Mode Interpretation

4.1 observer pattern class diagram

　　

4.2 code of observer Mode

/// <Summary> /// abstract topic class /// </summary> public abstract class Subject {private IList <Observer> observers = new List <Observer> (); /// <summary> /// add an observer /// </summary> /// <param name = "Observer"> </param> public void Attach (observer) {observers. add (observer );} /// <summary> /// remove the observer /// </summary> /// <param name = "Observer"> </param> public void Detach (observer) {observers. remov E (observer) ;}/// <summary> /// send a notification to the observer /// </summary> public void Policy () {foreach (Observer o in observers) {o. update () ;}}/// <summary> // abstract observer class, which defines an interface for all specific observers, update yourself when notified. // </summary> public abstract class Observer {public abstract void Update ();} /// <summary> /// a specific observer or a specific notification, stores the relevant status into a specific observer object. When the internal status of a specific subject changes, send a notification to all registered observers. A topic role is usually implemented by a specific subclass. /// </Summary> public class ConcreteSubject: Subject {private string subjectState; /// <summary> /// the status of the specified observer /// </summary> public string SubjectState {get {return subjectState;} set {subjectState = value ;}}} /// <summary> /// specifies the observer to implement the update interface required by the abstract observer role, the status of the topic already exists. // </summary> public class ConcreteObserver: Observer {private string observerState; private string name; private ConcreteSubject subject; /// <summary> /// a specific observer uses a specific topic to implement /// </summary> public ConcreteSubject Subject {get {return subject ;} set {subject = value ;}} public ConcreteObserver (ConcreteSubject subject, string name) {this. subject = subject; this. name = name ;}/// <summary> /// implement the Update operation in the abstract observer /// </summary> public override void Update () {observerState = subject. subjectState; Console. writeLine ("The observer's state of {0} is {1}", name, observerState );}}

4.3 client code

Class Program {static void Main (string [] args) {// a specific topic role generally uses a specific self to implement ConcreteSubject subject = new ConcreteSubject (); subject. attach (new ConcreteObserver (subject, "Observer A"); subject. attach (new ConcreteObserver (subject, "Observer B"); subject. attach (new ConcreteObserver (subject, "Observer C"); subject. subjectState = "Ready"; subject. Y (); Console. read ();}}

Running result

　　

5. Summary

5.1 advantages

5.1.1 The Observer mode removes the coupling between the subject and the specific observer, so that both sides of the coupling depend on abstraction rather than on specifics. So that changes on the other side will not be affected.

5.2 disadvantages

5.2.1 The dependency is not completely removed, and the abstract notification still depends on the abstract observer.

5.3 applicable scenarios

5.3.1 when an object needs to be changed to another object, and it does not know how many objects need to be changed.

5.3.2 an abstract type has two aspects. When one of them depends on the other, the observer mode can encapsulate the two in an independent object so that they can change and reuse independently.