小猪学设计模式之—观察者模式

2016-09-28

观察者模式

观察者模式在所有设计模式中应该属于比较好理解的也是能让大家立即先想到的设计模式了。
观察者模式是行为型模式的一种。

定义对象间的一种一对多的依赖关系，当一个对象状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

一个简单的例子是用观察者模式和轮询做对比，麦兜在吃煮粉时不停的问：老板有煮粉吗？这叫轮询；而老板说：你先等着，等有了之后我通知你！这就叫订阅，也就是观察者了。

涉及到的角色

抽象被观察者
抽象观察者
具体被观察者
具体观察者

抽象被观察者角色：把所有对观察者对象的引用保存在一个集合中，每个被观察者角色都可以有任意数量的观察者。被观察者提供一个接口，可以增加和删除观察者角色。一般用一个抽象类和接口来实现。

/// <summary>
/// 抽象主题类，也叫被观察者
/// </summary>
public abstract class Subject
{
    private IList<Observer> observers = new List<Observer>();

    /// <summary>
    /// 增加观察者
    /// </summary>
    /// <param name="observer"></param>
    public void Attach(Observer observer)
    {
        observers.Add(observer);
    }

    /// <summary>
    /// 移除观察者
    /// </summary>
    /// <param name="observer"></param>
    public void Detach(Observer observer)
    {
        observers.Remove(observer);
    }

    /// <summary>
    /// 向观察者（们）发出通知
    /// </summary>
    public void Notify()
    {
        foreach (Observer o in observers)
        {
            o.Update();
        }
    }
}

具体被观察者角色：在被观察者内部状态改变时，给所有登记过的观察者发出通知。具体被观察者角色通常用一个子类实现。

/// <summary>
/// 具体观察者或具体通知者，将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色通常用一个具体子类实现。
/// </summary>
public class ConcreteSubject extends Subject
{
    private String subjectState;

    /// <summary>
    /// 具体观察者的状态
    /// </summary>
    public String SubjectState
    {
        get { return subjectState; }
        set { subjectState = value; }
    }
}

抽象观察者角色：为所有具体的观察者定义一个接口，在得到主题的通知时更新自己。

/// <summary>
/// 抽象观察者类，为所有具体观察者定义一个接口，在得到通知时更新自己
/// </summary>
public abstract class Observer
{
    public abstract void Update();
}

具体观察者角色：该角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。通常用一个子类实现。如果需要，具体观察者角色可以保存一个指向具体主题角色的引用。

/// <summary>
/// 具体观察者，实现抽象观察者角色所要求的更新接口，已是本身状态与主题状态相协调
/// </summary>
public class ConcreteObserver extends Observer
{
    private String observerState;
    private String name;
    private ConcreteSubject subject;

    /// <summary>
    /// 具体观察者用一个具体主题来实现
    /// </summary>
    public ConcreteSubject Subject
    {
        get { return subject; }
        set { subject = value; }
    }

    public ConcreteObserver(ConcreteSubject subject, String name)
    {
        this.subject = subject;
        this.name = name;
    }

    /// <summary>
    /// 实现抽象观察者中的更新操作
    /// </summary>
    public override void Update()
    {
        observerState = subject.SubjectState;
        Console.WriteLine("The observer's state of {0} is {1}", name, observerState);
    }
}

上述的示例代码中我们使用了抽象类作为抽象被观察者和抽象观察者，当然我们也可以使用接口来代替抽象类实现同样的功能。

另外，上述代码中的被观察者向外提供的通知方法是Notify()，在实际的代码中我们需要对这部分进行抽象，例如在麦兜的例子中，老板应该提供给所有客户（当然包括麦兜）提供一个通知接口，这个接口告诉所有想吃煮粉的客户，你们想要吃的东西来了，现在可以下单了。在这里，老板就是具体的被观察者了，而客户就是具体的观察者，麦兜是观察者中的一员。

推模式与拉模式

目标角色在发生变化后，仅仅告诉观察者角色“我变化了”，观察者角色如果想要知道具体的变化细节，则就要自己从目标角色的接口中得到。这种模式被很形象的称为：拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出来的。
在麦兜的例子中，当顾客们知道有了煮粉之后，如果想要继续了解煮粉还有多少份，卖多少钱这些信息的时候，他们就得再次的去找老板问了。

还有一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同时，通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要，先给你啦。
如果我们在观察者的抽象接口中添加被观察者的参数，例如下列的抽象观察者的代码：

/// <summary>
/// 抽象观察者类，为所有具体观察者定义一个接口，在得到通知时更新自己
/// </summary>
public abstract class Observer
{
    public abstract void Update(final Subject subject,final Object parms);
}

这样在被观察者进行通知时就需要将本身的一些信息推给观察者，观察者可根据被观察者的信息做一些逻辑判断然后选择自身做的事。
当老板通知在等煮粉的客户：现在可以订煮粉啦，限量20份，每份200块时，聪明的麦兜果断选择了放弃煮粉，点了份鸭血粉丝汤开心的吃了起来。

不过这两种模式的使用，取决于系统设计时的需要。如果目标角色比较复杂，并且观察者角色进行更新时必须得到一些具体变化的信息，则“推模式”比较合适。如果目标角色比较简单，则“拉模式”就很合适啦