观察者模式（Observer Pattern）

观察者模式（Observer Pattern）：定义对象间一种一对多的依赖关系，使得当一个对象（主题 Subject / 被观察者）改变状态时，所有依赖于它的对象（观察者 Observer）都会被自动通知并更新。它属于 GoF 23 种设计模式中的行为型模式，是"发布-订阅"思想在进程内、直接对象引用形态下的经典实现。

一句话记住它："我不主动找你，我变了就喊一嗓子，谁关心谁就来。" 主题只负责广播"我变了"，至于谁在听、听到后干什么，主题一概不关心。

先看一段没有模式的"坏代码"。假设我们要做一个气象站系统：气象站采集到新数据后，需要同步刷新三块展示屏——大屏、手机 App、网页端。

// 坏味道：气象站"认识"每一个具体的展示屏
class WeatherStation {
public:
    void setMeasurements(float t, float h, float p) {
        m_temp = t; m_humidity = h; m_pressure = p;
        // 直接调用每个具体展示屏的方法 —— 高耦合！
        m_bigScreen->update(t, h, p);
        m_phoneApp->refresh(t, h, p);
        m_webPage->render(t, h, p);
    }
private:
    BigScreen*   m_bigScreen;   // 具体类
    PhoneApp*    m_phoneApp;    // 具体类
    WebPage*     m_webPage;     // 具体类
};

这段代码的问题非常典型：

• 违背开闭原则（OCP）：明天要加一块"智能音箱播报屏"，必须修改 WeatherStation 的成员变量和 setMeasurements——每加一个展示端，就要改一次核心业务类，核心类被展示端"绑架"。
• 违背依赖倒置原则（DIP）：高层业务（气象站）直接依赖低层具体实现（各展示屏类），二者之间没有抽象层。
• 违背单一职责（SRP）：气象站既要采集数据，又要管"通知谁、按什么顺序通知"，职责混杂。
• 编译期强耦合：展示屏改了构造函数，气象站要跟着改；展示屏的类头文件一变动，气象站整个模块就要重新编译。
• 无法动态增删：运行中想让某块屏"下线"？除非加一堆 if 标志位，否则做不到。

观察者模式的核心思想可以概括为四个字：订阅-广播。

• 主题（Subject）维护一个观察者列表，提供 attach（订阅）和 detach（退订）两个入口；状态变化时调用 notify，逐个通知观察者。
• 观察者（Observer）提供一个统一的 update 接口。具体观察者实现这个接口，定义"收到通知后干什么"。
• 主题不知道也不关心观察者的具体类型，只通过抽象接口打交道——这就是"解耦"的关键。

生活类比：报刊订阅。出版社（主题）并不知道每个读者的名字和住址，读者只需在邮局登记订阅（attach）。每期报纸印好（状态变化），邮局按订阅名单投递（notify）。读者想停订就退订（detach），出版社完全不需要改动。再比如微信公众号：你关注了某个号（attach），号主一发文（notify），所有粉丝自动收到推送——号主从来不直接调用任何一个粉丝的"阅读"方法。

另一个经典类比是电台广播：电台（主题）对着频率喊话，收音机（观察者）调到该频率就能收到；收音机没开，电台照常广播，互不影响。观察者模式里的"频率"就是那个抽象的观察者接口。

模式还演化出两种通知模型：

• 推模型（Push）：主题把变化的数据打包传给观察者（如把温度湿度气压全传过去）。简单直接，但观察者可能用不到全部数据。
• 拉模型（Pull）：主题只通知"我变了"，观察者自己调用主题的 getter 按需取数据。更灵活，但观察者要知道主题的具体类型，耦合略高。

Qt 的信号槽本质上是一种"推模型"的观察者：信号把参数打包发给槽函数。

观察者模式由四个角色组成：

角色	名称	职责
抽象主题	Subject	维护观察者列表；提供 attach() / detach() / notify()
具体主题	ConcreteSubject	持有真实状态；状态变化时调用 notify()；可提供 getter 供拉模型使用
抽象观察者	Observer	定义统一的更新接口 update()（纯虚函数）
具体观察者	ConcreteObserver	实现 update()，定义收到通知后的具体行为；可持有对具体主题的引用以便拉数据

┌─────────────────┐        ┌──────────────────┐
│    <<interface>>   │        │  <<interface>>    │
│     Subject      │        │     Observer     │
├─────────────────┤        ├──────────────────┤
│ +attach(o)       │        │ +update(data)    │
│ +detach(o)       │        └──────────────────┘
│ +notify()        │                ▲
└───────┬─────────┘                │ 实现
        │ 1 ── * 维护观察者列表     │
        │                          │
┌───────┴─────────┐        ┌───────┴──────────┐
│ ConcreteSubject │        │ ConcreteObserver │
├─────────────────┤        ├──────────────────┤
│ -state           │        │ +update(data)    │
│ +setState(s)     │────────│   { 各自刷新 }   │
└─────────────────┘ 通知    └──────────────────┘

协作流程：具体观察者把自己 attach 到具体主题 → 具体主题状态改变 → 调用 notify() → 遍历观察者列表逐个调用 update() → 各观察者自行刷新。整个过程主题只依赖抽象的 Observer 接口。

用 C++17 实现一个完整可编译的气象站例子。注意规范：观察者列表用 std::shared_ptr 管理所有权，detach 用 erase-remove 惯用法，杜绝悬空指针与内存泄漏。

// observer_demo.cpp —— C++17 观察者模式最小示例
// 编译：g++ -std=c++17 -Wall -Wextra observer_demo.cpp -o observer_demo
#include <iostream>
#include <vector>
#include <memory>
#include <algorithm>
#include <string>

// ── 抽象观察者：所有展示端实现的统一接口 ──
class IObserver {
public:
    virtual ~IObserver() = default;               // 虚析构，保证多态删除安全
    virtual void update(float temp, float humidity, float pressure) = 0;
};

// ── 具体观察者：手机 App 展示端 ──
class PhoneApp : public IObserver {
public:
    explicit PhoneApp(std::string name) : m_name(std::move(name)) {}
    void update(float temp, float humi, float pres) override {
        std::cout << "[" << m_name << "] 温度 " << temp
                  << "°C | 湿度 " << humi
                  << "% | 气压 " << pres << " hPa\n";
    }
private:
    std::string m_name;
};

// ── 主题（被观察者）：气象站 ──
class WeatherStation {
public:
    // 订阅：加入观察者列表
    void attach(std::shared_ptr<IObserver> obs) {
        m_observers.push_back(std::move(obs));
    }
    // 退订：从列表移除（erase-remove 惯用法）
    void detach(const std::shared_ptr<IObserver>& obs) {
        m_observers.erase(
            std::remove(m_observers.begin(), m_observers.end(), obs),
            m_observers.end());
    }
    // 状态变化入口：更新数据并广播
    void setMeasurements(float t, float h, float p) {
        m_temp = t; m_humidity = h; m_pressure = p;
        notify();
    }
private:
    void notify() {
        for (auto& obs : m_observers) {          // 逐个通知，主题不认识具体类型
            obs->update(m_temp, m_humidity, m_pressure);
        }
    }
    std::vector<std::shared_ptr<IObserver>> m_observers;  // 观察者列表
    float m_temp = 0.0f, m_humidity = 0.0f, m_pressure = 0.0f;
};

int main() {
    WeatherStation station;
    auto livingRoom = std::make_shared<PhoneApp>("客厅大屏");
    auto phone      = std::make_shared<PhoneApp>("手机通知");

    station.attach(livingRoom);                    // 两块屏都订阅
    station.attach(phone);

    station.setMeasurements(26.5f, 60.0f, 1013.2f); // 第一次数据更新，双屏都收到

    station.detach(livingRoom);                    // 客厅大屏退订
    station.setMeasurements(27.1f, 58.0f, 1012.8f); // 第二次更新，只剩手机收到

    return 0;
}

程序输出：

[客厅大屏] 温度 26.5°C | 湿度 60% | 气压 1013.2 hPa
[手机通知] 温度 26.5°C | 湿度 60% | 气压 1013.2 hPa
[手机通知] 温度 27.1°C | 湿度 58% | 气压 1012.8 hPa

注意体会：加一块"网页展示屏"只需要新建一个继承 IObserver 的类再 attach 进去，WeatherStation 一行都不用改——这就是 OCP 的胜利。

Qt 本身就是观察者模式的"重度用户"：信号与槽（Signals & Slots）机制就是观察者模式在 C++ 框架层面最成功的工程化实现。信号相当于"主题的通知"，槽相当于"观察者的 update"，connect() 相当于 attach，disconnect() 相当于 detach。相比手写观察者，Qt 的信号槽还额外提供了：

• 类型安全：编译期检查信号与槽的参数签名是否匹配；
• 自动断连：接收者对象销毁时连接自动断开，绝不产生悬空通知（比手写 vector 更安全）；
• 线程安全：跨线程连接自动转为队列投递（QueuedConnection），天然线程安全；
• 一个信号连多个槽、一个槽连多个信号：一对多、多对一都支持。

下面把气象站例子用 Qt6 + C++17 重写。三个文件 + CMake：

weatherstation.h —— 主题：气象站（QObject + 信号）

#ifndef WEATHERSTATION_H
#define WEATHERSTATION_H

#include <QObject>

// 主题：气象站。状态变化时通过信号广播给所有连接的观察者
class WeatherStation : public QObject {
    Q_OBJECT
public:
    explicit WeatherStation(QObject* parent = nullptr) : QObject(parent) {}

    // 状态变化入口：更新数据并发射信号（等价于 notify()）
    void setMeasurements(double temp, double humidity, double pressure) {
        m_temp = temp; m_humidity = humidity; m_pressure = pressure;
        emit measurementsChanged(m_temp, m_humidity, m_pressure);
    }

signals:
    // 通知信号：参数就是推送给观察者的数据（推模型）
    void measurementsChanged(double temp, double humidity, double pressure);

private:
    double m_temp = 0.0, m_humidity = 0.0, m_pressure = 0.0;
};

#endif // WEATHERSTATION_H

display.h —— 观察者：展示端（QObject + 槽）

#ifndef DISPLAY_H
#define DISPLAY_H

#include <QObject>
#include <QDebug>
#include <QString>

// 观察者：展示端。槽函数等价于 update()，收到通知后自行刷新
class PhoneDisplay : public QObject {
    Q_OBJECT
public:
    explicit PhoneDisplay(const QString& name, QObject* parent = nullptr)
        : QObject(parent), m_name(name) {}

public slots:
    // 观察者的更新逻辑：打印一条日志模拟刷新 UI
    void onMeasurementsChanged(double temp, double humidity, double pressure) {
        qInfo() << "[" << m_name << "] 温度:" << temp
                << "°C 湿度:" << humidity << "% 气压:" << pressure << "hPa";
    }

private:
    QString m_name;
};

#endif // DISPLAY_H

main.cpp —— 组装：订阅与退订

#include <QCoreApplication>
#include "weatherstation.h"
#include "display.h"

int main(int argc, char* argv[]) {
    QCoreApplication app(argc, argv);

    WeatherStation station;                    // 主题
    PhoneDisplay livingRoom("客厅大屏");        // 观察者 1
    PhoneDisplay phone("手机通知");             // 观察者 2

    // attach：把观察者的槽连接到主题的信号
    QObject::connect(&station, &WeatherStation::measurementsChanged,
                     &livingRoom, &PhoneDisplay::onMeasurementsChanged);
    QObject::connect(&station, &WeatherStation::measurementsChanged,
                     &phone, &PhoneDisplay::onMeasurementsChanged);

    station.setMeasurements(26.5, 60.0, 1013.2); // 广播 1：两块屏都刷新

    // detach：断开客厅大屏
    QObject::disconnect(&station, &WeatherStation::measurementsChanged,
                        &livingRoom, &PhoneDisplay::onMeasurementsChanged);

    station.setMeasurements(27.1, 58.0, 1012.8); // 广播 2：只剩手机收到
    return 0;
}

CMakeLists.txt

cmake_minimum_required(VERSION 3.16)
project(observer_demo LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_AUTOMOC ON)   # 自动处理 Q_OBJECT 的 moc

find_package(Qt6 REQUIRED COMPONENTS Core)

add_executable(observer_demo
    main.cpp
    weatherstation.h
    display.h
)
target_link_libraries(observer_demo PRIVATE Qt6::Core)

构建与运行：

mkdir build && cd build
cmake .. -DCMAKE_PREFIX_PATH=/path/to/qt6
cmake --build .
./observer_demo

运行输出（qInfo 格式）：

[ "客厅大屏" ] 温度: 26.5 °C 湿度: 60 % 气压: 1013.2 hPa
[ "手机通知" ] 温度: 26.5 °C 湿度: 60 % 气压: 1013.2 hPa
[ "手机通知" ] 温度: 27.1 °C 湿度: 58 % 气压: 1012.8 hPa

在真正的 Qt 项目里，上面的 PhoneDisplay 通常是一个 QWidget/QLabel：把 onMeasurementsChanged 里换成 ui->tempLabel->setText(...) 就是标准的"数据变化驱动界面刷新"，这也是 MVC 中 View 监听 Model 变化的基础。

以最小 C++ 示例为主线，梳理完整执行流程：

1. 创建并订阅：main 中构造 WeatherStation 和两个 PhoneApp，分别调用 station.attach(...) 把两个观察者加入 m_observers 列表。此时列表长度为 2，主题与观察者之间只有抽象接口的依赖。
2. 状态更新：调用 station.setMeasurements(26.5, 60.0, 1013.2)，函数内部先更新三个成员变量（m_temp/m_humidity/m_pressure），再调用私有方法 notify()。
3. 广播通知：notify() 用范围 for 遍历 m_observers，对每个元素调用 obs->update(m_temp, m_humidity, m_pressure)——这是多态调用，实际执行的是 PhoneApp::update，打印一行数据。两个观察者依次收到通知，输出两行日志。
4. 动态退订：station.detach(livingRoom) 用 erase-remove 把客厅大屏从列表中移除，列表长度变 1。再次 setMeasurements(27.1, ...) 时，只有手机收到通知。
5. 收尾：main 返回，WeatherStation 析构时其 std::shared_ptr<IObserver> 列表自动释放引用；PhoneApp 对象在 main 栈上自动析构。全程无手动 delete，无悬空指针。

Qt 版本的流程本质相同，只是把"调用 update()"换成了"emit 信号 → 由元对象系统查找并调用所有已连接的槽"；唯一差异是 disconnect 之后，如果接收者对象被销毁，连接会自动清理，无需手动维护列表。

观察者模式的每一个设计决策都指向同一个目标：让"通知的发出方"与"通知的接收方"彻底解耦。拆开来看：

• 解耦点：主题只依赖抽象的 Observer 接口，不依赖任何具体观察者。观察者可以独立变化、独立测试、独立部署，"多一个观察者"和"少一个观察者"对主题完全透明。
• 开闭原则（OCP）：新增一种观察者（网页端、音箱、短信）只需新增一个实现 IObserver 的类并 attach，主题类零修改——对扩展开放，对修改关闭。
• 依赖倒置原则（DIP）：主题和观察者都依赖于抽象接口（IObserver），而不是相互依赖具体类。高层模块（业务核心）不再依赖低层模块（展示细节）。
• 单一职责（SRP）：主题只管"状态 + 广播"，观察者只管"收到通知后干什么"。各自的变化原因互不相干。
• 组合优于继承：观察者通过"注册"组合进主题，而不是通过继承获得通知能力；运行期可动态增删，比继承灵活得多。
• 可测试性：测试主题时挂一个"记录型"假观察者（Mock），断言它收到的数据序列即可；测试观察者时直接手动调用 update()，无需真实主题。两边都能独立单测。
• 触发时机集中：状态变化后"通知"这个动作被收敛到 setMeasurements 一处，避免"忘通知"或"重复通知"这类低级 bug。

回到第二节的坏代码，想象系统继续演化的下场：

• if-else 膨胀：当"某些展示端只在特定条件下刷新"（比如只在温度突变时提醒手机），你会在 setMeasurements 里堆出一串 if (needPhone) ...; if (needWeb) ...，业务逻辑和展示逻辑纠缠成意大利面条。
• 类爆炸 + 修改连锁：每加一个展示端，主题类就要加一个成员指针、改一次通知函数。展示端从 3 个涨到 10 个时，主题类成了"什么都知道"的上帝类，任何展示端的改动都可能波及核心逻辑。
• 编译耦合：主题的 .h 被迫 include 所有展示端的头文件；任何一个展示端头文件变化，主题及其所有依赖者都要重新编译，构建时间随模块膨胀。
• 无法动态增删：运行时想临时挂一个"调试日志观察者"？硬编码结构下不可能，只能改代码重编译。
• 测试地狱：主题依赖具体展示端，测主题必须构造真实展示端（可能还要连数据库、弹窗口），无法用轻量假对象替换。

一句话总结反例的代价：稳定的通知机制被易变的接收方绑架，每一次"新增接收方"都变成对核心代码的一次外科手术。

适合使用的场景（3-5 个）：

• 一个对象状态变化需要驱动多个对象更新，且接收方的数量、类型会变化。典型：数据模型变化刷新多个视图（MVC 的 View 监听 Model）。
• 事件驱动的 UI 编程：按钮点击、定时器超时、网络数据到达——Qt 里几乎一切交互都是信号槽（观察者）在驱动。
• 跨模块解耦的通知：业务模块 A 完成某个动作后，要让日志模块、统计模块、消息推送模块各自响应，但 A 不想认识它们。
• 订阅式业务：行情推送、消息队列消费者、传感器数据分发等"多路分发"场景。
• 触发器/联动规则：一个属性变化引发一系列级联动作（如 UI 控件联动、状态机外部响应）。

不适合的场景（2-4 个）：

• 只有唯一接收方且永远不变：直接函数调用或回调即可，引入观察者纯属浪费。
• 对通知顺序有强依赖、且接收方相互影响：观察者模式的通知顺序依赖注册顺序，语义脆弱，容易埋雷。
• 高频状态变化 + 大量观察者：每次变化都全量广播，同步调用会拖慢主题；需要节流、批量合并或异步队列，模式本身不提供。
• 观察者生命周期难以管理：如果观察者随时可能销毁而又没有自动断连机制（如 Qt 信号槽），手写观察者列表很容易悬空指针崩溃。

过度设计提醒：一对一的"A 变了 B 要更新"，用普通调用即可，别为了"以后可能加观察者"提前套模式（YAGNI）。另外注意通知风暴：A 通知 B，B 又通知 A，可能形成环状级联；性能：广播是同步的，观察者里别做重活，否则拖慢主题。

对比模式	相似点	关键区别
中介者模式（Mediator）	都是"多对象协作"，都降低对象间耦合	观察者是一对多广播：主题→观察者单向流动，观察者之间互不认识；中介者是多对多中枢：所有对象（同事）只和中介者通信，由中介者协调转发，形成星型结构。Qt 的 QAbstractItemModel 之于多个 View 是观察者；而对话框里多个控件通过 QDialog 协调联动则更接近中介者。
发布-订阅（Pub/Sub）	思想同源：发布者不直接调用订阅者	观察者模式里主题直接持有观察者引用，是进程内同步的；Pub/Sub 通常通过消息代理/主题通道中转，发布者和订阅者彼此完全无引用，可跨进程、跨机器、异步。观察者是 Pub/Sub 的"进程内简化版"。
命令模式（Command）	都把"行为"封装成对象/接口	命令模式封装的是"一个待执行的动作"（可撤销、可排队），由调用者显式触发；观察者封装的是"对变化的响应"，由主题状态变化隐式触发。命令是"主动的执行"，观察者是"被动的响应"。

另外常被混淆的是信号槽与回调（Callback）：回调是单接收者的函数指针，信号槽是多接收者、类型安全、可自动断连的观察者实现——可以认为 Qt 信号槽是回调的"观察者化升级版"。

观察者模式在 Qt 里不是"某个类用到了"，而是整个框架的地基。最直接的体现：

• QObject 信号槽机制：QMetaObject::activate() 就是主题的 notify()——遍历连接列表，逐个调用槽函数（观察者的 update）。connect()=attach，disconnect()=detach，且接收者析构时自动断连（QObject 析构里调用 disconnect(this)），从机制上杜绝悬空指针。
• QAbstractItemModel：Model 发射 dataChanged() / rowsInserted() 等信号，所有 View（QListView/QTableView/QTreeView）作为观察者自动刷新。这正是 MVC 里"View 监听 Model"的标准观察者实现，也是 QAbstractItemView 的 setModel 内部 connect 的由来。
• QTimer::timeout：定时器是主题，连接它的槽是观察者；QNetworkAccessManager 的 finished()、QProcess 的 readyRead() 同理。
• QEvent 系统：QCoreApplication::sendEvent/postEvent + 各对象的 event()/eventFilter() 是观察者思想的另一变体——事件是"通知"，事件过滤器是"可插拔的观察者"。
• 测试设施 QSignalSpy：专门"监听"信号并记录发射参数，本质就是一个测试用观察者，印证了观察者模式带来的可测试性红利。

可以说：理解观察者模式，就理解了 Qt 事件驱动架构的一半。