C 设计模式精讲：观察者模式的原理、实现与应用（一）

s4y3ici0

243人浏览 · 2026-05-04 16:49:15

s4y3ici0 · 2026-05-04 16:49:15 发布

观察者模式是一种常用的行为型设计模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象的状态发生改变时，会通知所有观察者对象，使它们能够自动更新自己。在C 开发中，观察者模式可以用于解耦主题对象和观察者对象，提高系统的灵活性和可维护性。例如，在GUI框架中，按钮点击事件可以作为主题，多个监听器可以作为观察者；在实时数据处理系统中，传感器数据变化可以作为主题，数据分析模块可以作为观察者。

如果没有观察者模式，主题对象需要维护一个观察者列表，并在状态改变时遍历该列表并调用每个观察者的更新方法。这种方式会导致主题对象和观察者对象紧耦合，当需要新增或删除观察者时，需要修改主题对象的代码，违反了开闭原则。同时，如果观察者的更新逻辑比较复杂，会增加主题对象的负担，影响其性能。例如，一个Nginx服务器，如果使用硬编码的方式来处理不同的请求类型（如静态资源、动态页面），则代码会变得非常臃肿，难以维护和扩展。利用观察者模式，我们可以将不同的请求处理逻辑作为观察者，当接收到新的请求时，Nginx服务器（主题）只需要通知所有的观察者，由它们自行决定是否处理该请求，从而实现了解耦。

痛点：代码耦合与维护难题

传统的紧耦合设计，当观察者数量或类型发生变化时，主题代码不得不随之修改。这不仅增加了维护成本，也降低了代码的可复用性。想象一下，如果你的系统需要支持多种不同的日志记录方式（例如，写入文件、发送到远程服务器、展示在GUI界面上），而这些日志记录方式都直接硬编码在主题对象中，那么每增加一种新的日志记录方式，都需要修改主题对象的代码。利用观察者模式，可以将每种日志记录方式作为一个观察者，主题对象只需要维护一个观察者列表，当需要增加新的日志记录方式时，只需要添加一个新的观察者即可，无需修改主题对象的代码。

C 观察者模式的核心原理与实现

观察者模式包含两个核心角色：主题（Subject）和观察者（Observer）。

**主题（Subject）：**维护一个观察者列表，提供添加、删除和通知观察者的方法。
**观察者（Observer）：**定义一个更新接口，当主题状态发生改变时，会被主题调用。

核心组件的 C 实现

下面是一个简单的 C 观察者模式的实现示例：

#include <iostream>#include <vector>// 抽象观察者类class Observer {public:  virtual void update(int state) = 0; // 纯虚函数，子类必须实现  virtual ~Observer() {}};// 抽象主题类class Subject {public:  virtual void attach(Observer* observer) = 0; // 添加观察者  virtual void detach(Observer* observer) = 0; // 移除观察者  virtual void notify() = 0;                // 通知所有观察者  virtual ~Subject() {}protected:  std::vector<Observer*> observers; // 观察者列表};// 具体主题类class ConcreteSubject : public Subject {public:  void attach(Observer* observer) override {    observers.push_back(observer);  }  void detach(Observer* observer) override {    for (auto it = observers.begin(); it != observers.end();   it) {      if (*it == observer) {        observers.erase(it);        break;      }    }  }  void notify() override {    for (Observer* observer : observers) {      observer->update(state_); // 调用观察者的 update 方法    }  }  void setState(int state) {    state_ = state;    notify(); // 状态改变时通知观察者  }private:  int state_; // 主题的状态};// 具体观察者类class ConcreteObserver : public Observer {public:  ConcreteObserver(Subject* subject, std::string name) : subject_(subject), name_(name) {}  void update(int state) override {    observerState_ = state;    std::cout << "Observer " << name_ << " received update. New state: " << observerState_ << std::endl;  }private:  Subject* subject_;   // 指向主题的指针  int observerState_; // 观察者的状态  std::string name_;  // 观察者名字};int main() {  ConcreteSubject* subject = new ConcreteSubject();  ConcreteObserver* observer1 = new ConcreteObserver(subject, "A");  ConcreteObserver* observer2 = new ConcreteObserver(subject, "B");  subject->attach(observer1);  subject->attach(observer2);  subject->setState(10); // 改变主题状态，通知观察者  subject->detach(observer1);  subject->setState(20); // 改变主题状态，通知观察者  delete observer1;  delete observer2;  delete subject;  return 0;}

这个例子中，Subject 类维护了一个 observers 列表，用于存储所有观察者。ConcreteSubject 类继承自 Subject 类，并实现了 attach、detach 和 notify 方法。Observer 类定义了一个 update 接口，ConcreteObserver 类继承自 Observer 类，并实现了 update 方法。当 ConcreteSubject 的状态改变时，会调用 notify 方法，遍历 observers 列表，并调用每个观察者的 update 方法。这种设计实现了主题对象和观察者对象的解耦，使得系统更加灵活和可维护。

观察者模式的实战应用与避坑指南

观察者模式在实际开发中有着广泛的应用，例如：

**GUI 框架：**按钮点击事件、文本框内容改变等事件都可以作为主题，多个监听器可以作为观察者。
**消息队列：**消息队列中的消息可以作为主题，多个消费者可以作为观察者。
**实时数据处理：**传感器数据变化可以作为主题，数据分析模块可以作为观察者。
**配置管理：**配置文件的更新可以作为主题，应用程序可以作为观察者。例如，我们可以使用观察者模式来实现一个动态配置加载的功能，当配置文件发生改变时，自动通知所有相关的模块重新加载配置。

实战避坑：避免循环依赖与内存泄漏

在使用观察者模式时，需要注意以下几点：

**避免循环依赖：**主题和观察者之间不要相互依赖，否则会导致循环依赖，影响系统的可维护性。
**避免内存泄漏：**当观察者不再需要监听主题时，需要及时从主题的观察者列表中移除，否则会导致内存泄漏。
**考虑线程安全：**如果在多线程环境下使用观察者模式，需要考虑线程安全问题，例如使用互斥锁来保护观察者列表。
**优化通知机制：**如果观察者数量很多，频繁的通知可能会影响性能。可以考虑使用异步通知或者批量通知的方式来优化通知机制。例如，可以使用线程池来异步地通知观察者，或者将多个状态改变合并为一个通知。

例如，在使用Redis作为消息队列时，我们可以将Redis的发布/订阅功能作为观察者模式的一种实现。Redis的频道可以作为主题，订阅频道的客户端可以作为观察者。当发布者向频道发送消息时，Redis会自动将消息推送给所有订阅该频道的客户端。但是，在使用Redis的发布/订阅功能时，需要注意消息的可靠性问题，因为Redis不会持久化消息，如果客户端离线，可能会丢失消息。为了解决这个问题，可以使用Redis的持久化机制，例如RDB或AOF，来持久化消息。

此外，在使用宝塔面板部署Nginx服务器时，宝塔面板提供了图形化的界面来管理Nginx的配置文件，例如修改端口号、添加虚拟主机等。但是，如果直接修改Nginx的配置文件，可能会导致Nginx服务器无法启动。为了避免这种情况，可以使用宝塔面板提供的配置检测功能，在修改配置文件后，先进行配置检测，确保配置文件的语法正确，然后再重启Nginx服务器。