设计模式-观察者模式（观察者模式的需求衍变过程详解，关于监听的理解）

前言

在软件设计中，对象之间的通信是非常常见的情况。然而，当对象之间的通信过于紧密，可能会导致代码的耦合度增加，使得系统难以维护和扩展。为了解决这个问题，观察者模式应运而生。本文将介绍观察者模式的原理、应用场景以及实现方式，并通过图、代码和例子进行详细说明。

概念

观察者模式通过定义一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，当主题对象发生变化时，会自动通知所有观察者对象进行相应的更新操作。

你有过这样的问题吗？

概念中说“多个观察者对象同时监听某一个主题对象”，什么叫监听，监听是被动的还是主动的？在代码中哪块体现监听了？
观察者模式的需求是如何演变的？
观察者模式属于行为型，为什么呢？行为型有什么特点吗？
观察者模式应用场景有哪些？有什么不足吗？

带着类似的问题，看下面的内容，文章的最后也会对这些问题一一回答

详细介绍

原理：

观察者模式由两个核心角色组成：主题（Subject）和观察者（Observer）。主题对象维护一个观察者列表（有个容器用来放观察者），当主题对象的状态发生变化时，会遍历观察者列表，依次通知每个观察者进行相应的更新操作。观察者对象则通过注册到主题对象上，以接收主题对象的通知。

应用场景：

观察者模式在许多实际应用中都有广泛的应用，例如：

消息订阅和发布系统：主题对象充当消息发布者，观察者对象充当消息订阅者。当发布者发布新消息时，订阅者会收到通知并进行相应的处理。
GUI开发：主题对象可以是用户界面组件，观察者对象可以是与该组件相关的其他组件。当用户界面组件发生变化时，其他组件可以及时更新自身的状态。
股票市场监控系统：主题对象可以是股票市场，观察者对象可以是投资者。当股票市场行情发生变化时，投资者可以及时了解到最新的行情。

实现方式：

类图

在这里插入图片描述

代码

下面通过一个简单的示例来演示观察者模式的实现。

首先，我们定义主题接口（Subject），包含注册观察者、移除观察者和通知观察者的方法。

public interface Subject {
    void registerObserver(Observer observer);
    void removeObserver(Observer observer);
    void notifyObservers();
}

然后，我们定义观察者接口（Observer），包含接收通知并进行更新操作的方法。

public interface Observer {
    void update();
}

接下来，我们实现具体的主题类（ConcreteSubject），并在该类中实现注册观察者、移除观察者和通知观察者的方法。

public class ConcreteSubject implements Subject {
    private List<Observer> observers = new ArrayList<>();
    
    @Override
    public void registerObserver(Observer observer) {
        observers.add(observer);
    }
    
    @Override
    public void removeObserver(Observer observer) {
        observers.remove(observer);
    }
    
    @Override
    public void notifyObservers() {
        for (Observer observer : observers) {
            observer.update();
        }
    }
    
    // 其他业务逻辑...
}

最后，我们实现具体的观察者类（ConcreteObserver），并在该类中实现接收通知并进行更新操作的方法。

public class ConcreteObserver implements Observer {
    @Override
    public void update() {
        // 执行更新操作...
    }
}

通过以上代码，我们可以看到，主题对象和观察者对象之间并没有直接的耦合关系，它们通过接口进行通信，实现了松耦合的对象间通信。

问题回答

监听，为什么叫监听，具体代码是哪

在观察者模式中，观察者对象通过注册（或订阅）的方式来监听某一个主题对象。这个监听的过程在代码中体现在观察者对象注册到主题对象的观察者列表中。

具体地，主题对象通常会提供一些方法，例如attach(observer)和detach(observer)，用于观察者对象的注册和注销。当主题对象的状态发生变化时，它会遍历观察者列表，并调用每个观察者对象的相应方法，通知它们状态的变化。

关于为什么称之为"监听"，这是因为在观察者模式中，观察者对象并不需要主动去轮询或查询主题对象的状态，而是被动地接收主题对象的通知。观察者对象通过注册到主题对象上，就像是在"监听"主题对象的状态变化。

观察者对象并没有主动去听的动作，但它们被动地接收主题对象的通知，从而实现了对主题对象状态变化的监听。这种被动的接收通知的行为，可以理解为观察者对象在"监听"主题对象。

观察者模式的需求衍变过程

故事背景：

老板回来，前台秘书发通知消息给正在玩的同事们（前提是，同事提前在秘书那“注册”过–“老板来了通知我一下”），收到秘书的通知后，同事们各自采取行动

宏观

最初的通知者和观察者是明确知道对方的存在的，但是在经过一次次的优化后观察者和通知者都不知道对方具体存在只知晓一个接口或者抽象类，这里就是在一对多通知的时候使用这种抽象的好处，不需要知道具体的通知者和观察者。

微观：

1.双向耦合：
开始有三个类：前台秘书类，看股票同事类，客户端，此时的前台秘书类与观察者类相互耦合，前台秘书类要增加观察者、观察者需要前台的的状态。
需要解决的问题是：前台秘书类与观察者类相互耦合。

2.解耦
增加抽象的观察者，增加了看NBA的同事，看股票的同事与看NBA 的同事继承抽象观察者。前台秘书类中与具体的观察者耦合的地方都改成了抽象观察者。存在的问题是：具体的观察者不应该依赖具体的主题，而是需要一个抽象的通知者。如果前台有事来不及通知，那么通知谁来做？前台不想通知某位同事，需要有移除方法进行支持。

3.观察者模式
观察者模式的作用是在解耦合，让耦合的双方都依赖抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。
如果观察者是风马牛不相及的类，使用接口更加合适。

观察者模式的不足：
抽象通知者依赖抽象观察者，应该由客户端决定通知谁；并不是每个具体的观察者都是更新方法。

事件与委托的实现
看股票的观察者类、看NBA 观察者类去掉了父类抽象观察者，并将更新方法名改为自己合适的方法名字。抽象观察者不要了，声明EventHandler委托,在具体的统治者类增加委托事件-update。

观察者是为什么是行为型

观察者模式是一种行为型设计模式，因为它关注的是对象之间的行为和交互，通过定义接口和松耦合的方式实现了对象之间的动态关联。

在观察者模式中，被观察者和观察者之间通过定义接口进行通信，这就意味着它们之间可以有不同的行为。被观察者负责维护观察者的列表，并在状态发生改变时通知观察者。观察者则负责定义在接收到通知时要执行的行为。

观察者模式的行为型特点还体现在它的实现方式上。在观察者模式中，被观察者和观察者之间是松耦合的，它们之间的关联是动态的，可以随时添加或移除观察者。这种灵活性使得观察者模式非常适合在复杂的系统中处理对象之间的行为和交互。

简单一句话总结行为型设计模式特点：
行为型模式的核心，都有一个类,把整个模式要做的事封装在这个类的一个方法里执行。
具体在观察者模式中这个类是ConcreteObserver,具体是其中的构造方法。具体观察者，只管要它要订阅哪个主题，（this.subject=subject.）但是它不管订阅的主题具体做什么事，进而实现了整个设计模式要实现的行为。