观察者模式(Observer)
意图
观察者模式是一种行为型模式，允许你定义一种订阅机制，可在对象事件发生时通知多个 “观察” 该对象的其他对象。 它定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
问题
假如你有两种类型的对象：顾客和商店。顾客对某个特定品牌的产品非常感兴趣（例如最新型号的iPhone手机），而该产品很快将会在商店里出售。
顾客可以每天来商店看看产品是否到货。但如果商品尚未到货时，绝大多数来到商店的顾客都会空手而归。
另一方面，每次新产品到货时，商店可以向所有顾客发送邮件（可能会被视为垃圾邮件）。这样，部分顾客就无需反复前往商店了，但也可能会惹恼对新产品没有兴趣的其他顾客。
我们似乎遇到了一个矛盾：要么让顾客浪费时间检查产品是否到货，要么让商店浪费资源去通知没有需求的顾客。
解决方案
由主题订阅并维护多个观察者，当主题发生变更，则所有观察者收到通知，并各自维持自己的状态。
拥有一些值得关注的状态的对象通常被称为目标，由于它要将自身的状态改变通知给其他对象，我们也将其称为发布者（publisher）。所有希望关注发布者状态变化的其他对象被称为订阅者（subscribers）。
观察者模式建议你为发布者类添加订阅机制，让每个对象都能订阅或取消订阅发布者事件流。不要害怕！ 这并不像听上去那么复杂。实际上，该机制包括：
- 一个用于存储订阅者对象引用的列表成员变量；
- 几个用于添加或删除该列表中订阅者的公有方法。
现在，无论何时发生了重要的发布者事件，它都要遍历订阅者并调用其对象的特定通知方法。
实际应用中可能会有十几个不同的订阅者类跟踪着同一个发布者类的事件，你不会希望发布者与所有这些类相耦合的。此外如果他人会使用发布者类，那么你甚至可能会对其中的一些类一无所知。
因此，所有订阅者都必须实现同样的接口，发布者仅通过该接口与订阅者交互。接口中必须声明通知方法及其参数，这样发布者在发出通知时还能传递一些上下文数据。
如果你的应用中有多个不同类型的发布者，且希望订阅者可兼容所有发布者，那么你甚至可以进一步让所有订阅者遵循同样的接口。该接口仅需描述几个订阅方法即可。这样订阅者就能在不与具体发布者类耦合的情况下通过接口观察发布者的状态。
结构
- 发布者（Publisher）会向其他对象发送值得关注的事件。事件会在发布者自身状态改变或执行特定行为后发生。发布者中包含一个允许新订阅者加入和当前订阅者离开列表的订阅构架。
- 当新事件发生时，发送者会遍历订阅列表并调用每个订阅者对象的通知方法。该方法是在订阅者接口中声明的。
- 订阅者（Subscriber）接口声明了通知接口。在绝大多数情况下，该接口仅包含一个 update更新方法。该方法可以拥有多个参数，使发布者能在更新时传递事件的详细信息。
- 具体订阅者（Concrete Subscribers）可以执行一些操作来回应发布者的通知。所有具体订阅者类都实现了同样的接口，因此发布者不需要与具体类相耦合。
- 订阅者通常需要一些上下文信息来正确地处理更新。因此，发布者通常会将一些上下文数据作为通知方法的参数进行传递。发布者也可将自身作为参数进行传递，使订阅者直接获取所需的数据。
- 客户端（Client）会分别创建发布者和订阅者对象，然后为订阅者注册发布者更新。
实现方式
- 仔细检查你的业务逻辑， 试着将其拆分为两个部分： 独立于其他代码的核心功能将作为发布者； 其他代码则将转化为一组订阅类。
- 声明订阅者接口。 该接口至少应声明一个
update方法。 - 声明发布者接口并定义一些接口来在列表中添加和删除订阅对象。 记住发布者必须仅通过订阅者接口与它们进行交互。
- 确定存放实际订阅列表的位置并实现订阅方法。 通常所有类型的发布者代码看上去都一样， 因此将列表放置在直接扩展自发布者接口的抽象类中是显而易见的。 具体发布者会扩展该类从而继承所有的订阅行为。 但是， 如果你需要在现有的类层次结构中应用该模式， 则可以考虑使用组合的方式： 将订阅逻辑放入一个独立的对象， 然后让所有实际订阅者使用该对象。
- 创建具体发布者类。 每次发布者发生了重要事件时都必须通知所有的订阅者。
- 在具体订阅者类中实现通知更新的方法。 绝大部分订阅者需要一些与事件相关的上下文数据。 这些数据可作为通知方法的参数来传递。 但还有另一种选择。 订阅者接收到通知后直接从通知中获取所有数据。 在这种情况下， 发布者必须通过更新方法将自身传递出去。 另一种不太灵活的方式是通过构造函数将发布者与订阅者永久性地连接起来。
- 客户端必须生成所需的全部订阅者， 并在相应的发布者处完成注册工作。
代码演示
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121 | using System;using System.Collections.Generic;using System.Threading;namespace RefactoringGuru.DesignPatterns.Observer.Conceptual{ public interface IObserver { // Receive update from subject void Update(ISubject subject); } public interface ISubject { // Attach an observer to the subject. void Attach(IObserver observer); // Detach an observer from the subject. void Detach(IObserver observer); // Notify all observers about an event. void Notify(); } // The Subject owns some important state and notifies observers when the // state changes. public class Subject : ISubject { // For the sake of simplicity, the Subject's state, essential to all // subscribers, is stored in this variable. public int State { get; set; } = -0; // List of subscribers. In real life, the list of subscribers can be // stored more comprehensively (categorized by event type, etc.). private List<IObserver> _observers = new List<IObserver>(); // The subscription management methods. public void Attach(IObserver observer) { Console.WriteLine("Subject: Attached an observer."); this._observers.Add(observer); } public void Detach(IObserver observer) { this._observers.Remove(observer); Console.WriteLine("Subject: Detached an observer."); } // Trigger an update in each subscriber. public void Notify() { Console.WriteLine("Subject: Notifying observers..."); foreach (var observer in _observers) { observer.Update(this); } } // Usually, the subscription logic is only a fraction of what a Subject // can really do. Subjects commonly hold some important business logic, // that triggers a notification method whenever something important is // about to happen (or after it). public void SomeBusinessLogic() { Console.WriteLine("\nSubject: I'm doing something important."); this.State = new Random().Next(0, 10); Thread.Sleep(15); Console.WriteLine("Subject: My state has just changed to: " + this.State); this.Notify(); } } // Concrete Observers react to the updates issued by the Subject they had // been attached to. class ConcreteObserverA : IObserver { public void Update(ISubject subject) { if ((subject as Subject).State < 3) { Console.WriteLine("ConcreteObserverA: Reacted to the event."); } } } class ConcreteObserverB : IObserver { public void Update(ISubject subject) { if ((subject as Subject).State == 0 || (subject as Subject).State >= 2) { Console.WriteLine("ConcreteObserverB: Reacted to the event."); } } } class Program { static void Main(string[] args) { // The client code. var subject = new Subject(); var observerA = new ConcreteObserverA(); subject.Attach(observerA); var observerB = new ConcreteObserverB(); subject.Attach(observerB); subject.SomeBusinessLogic(); subject.SomeBusinessLogic(); subject.Detach(observerB); subject.SomeBusinessLogic(); } }} |
|---|
执行结果：
123456789101112131415161718 | Subject: Attached an observer.Subject: Attached an observer.Subject: I'm doing something important.Subject: My state has just changed to: 2Subject: Notifying observers...ConcreteObserverA: Reacted to the event.ConcreteObserverB: Reacted to the event.Subject: I'm doing something important.Subject: My state has just changed to: 1Subject: Notifying observers...ConcreteObserverA: Reacted to the event.Subject: Detached an observer.Subject: I'm doing something important.Subject: My state has just changed to: 5Subject: Notifying observers... |
|---|
参考原文：观察者设计模式
腾讯云开发者
