php常用设计模式之观察者模式在日常业务开发中，我们经常遇到类似这样的场景：例如，当用户购买会员成功后，系统需要执行一系

引言

在日常业务开发中，我们经常遇到类似这样的场景：例如，当用户购买会员成功后，系统需要执行一系列后续操作。在用户支付成功后，系统不仅要更新订单状态，还需要为用户添加会员标识、发送通知提醒、记录操作日志等。

通常情况下，我们会将这些逻辑直接写在支付回调方法中，集中处理所有相关操作。比如这样设计：

class OrderService {
    public function onPaymentSuccess($order) {
        // 更新订单状态
        $this->updateOrderStatus($order);

        // 给用户添加会员标识
        $this->addMembership($order);

        // 通知用户
        $this->notifyUser($order);

        // 记录日志
        $this->logPaymentSuccess($order);

        // 其他操作...
    }

    private function updateOrderStatus($order) {
        // 更新订单状态逻辑
        echo "订单状态已更新\n";
    }

    private function addMembership($order) {
        // 添加会员标识逻辑
        echo "用户已添加会员标识\n";
    }

    private function notifyUser($order) {
        // 通知用户逻辑
        echo "已通知用户支付成功\n";
    }

    private function logPaymentSuccess($order) {
        // 记录日志逻辑
        echo "支付成功日志已记录\n";
    }
}

问题分析

在上面的代码中，onPaymentSuccess方法内包含了所有后续操作的逻辑。这样设计有几个缺点：

代码耦合度高：onPaymentSuccess方法需要管理多个操作，逻辑交织在一起，一旦某个操作需要调整或新增其他功能（比如发放优惠券或增加积分），就必须直接修改这个方法。
难以扩展和复用：每次增加新的后续操作时都需要修改onPaymentSuccess方法的代码，导致代码难以扩展和复用。这不符合“开闭原则”（对扩展开放、对修改关闭），不利于后期维护。
不便于测试：所有逻辑都集中在一起，导致在单元测试中难以单独测试每个操作模块，并且如果其中一个操作失败，可能会影响其他操作的正常执行。
违反单一职责原则：onPaymentSuccess不仅仅是一个支付成功的回调方法，还负责管理通知、日志记录等多种不同功能，职责太多，使代码难以维护。

针对这种逻辑设计，我们可以进行优化。通过使用设计模式中的观察者模式，我们可以将这些操作分离为独立的观察者，使得主逻辑更加清晰，也便于扩展和测试。这样，每当支付成功后，系统会自动触发相应的观察者去执行各自的处理逻辑，避免了在主流程中堆叠所有操作，从而提升代码的灵活性和可维护性。

什么是观察者模式

观察者模式是一种行为型设计模式，允许我们定义一个事件触发机制，在事件源和响应操作之间建立解耦的通知关系。当某个事件发生时（例如支付成功），事件源会通知所有订阅的观察者，触发相应的处理逻辑。通过观察者模式，可以在运行时动态添加或移除观察者，使得系统具备高度的可扩展性和灵活性。

观察者模式的原理

观察者模式的核心原理是将事件源和响应操作分离，使得事件发生后，所有订阅的观察者都能接收到通知并执行各自的处理逻辑。通过定义一个观察者接口，事件源可以在触发事件时通知所有观察者，从而实现响应操作的解耦和灵活配置。

示例：

// 观察者接口
interface Observer {
    public function update($order);
}

// 具体观察者：更新订单状态
class UpdateOrderStatus implements Observer {
    public function update($order) {
        echo "订单状态已更新\n";
    }
}

// 具体观察者：添加会员标识
class AddMembership implements Observer {
    public function update($order) {
        echo "用户已添加会员标识\n";
    }
}

// 具体观察者：通知用户
class NotifyUser implements Observer {
    public function update($order) {
        echo "已通知用户支付成功\n";
    }
}

// 具体观察者：记录日志
class LogPaymentSuccess implements Observer {
    public function update($order) {
        echo "支付成功日志已记录\n";
    }
}

// 事件源：支付服务
class PaymentService {
    private $observers = [];

    // 添加观察者
    public function addObserver(Observer $observer) {
        $this->observers[] = $observer;
    }

    // 支付成功时通知所有观察者
    public function onPaymentSuccess($order) {
        foreach ($this->observers as $observer) {
            $observer->update($order);
        }
    }
}

// 客户端代码
$paymentService = new PaymentService();

// 添加各种支付成功后的操作观察者
$paymentService->addObserver(new UpdateOrderStatus());
$paymentService->addObserver(new AddMembership());
$paymentService->addObserver(new NotifyUser());
$paymentService->addObserver(new LogPaymentSuccess());

// 模拟支付成功
$order = "订单信息"; // 示例订单
$paymentService->onPaymentSuccess($order);

在这个示例中，PaymentService类作为事件源，当支付成功时会通知所有已添加的观察者。每个观察者类都独立处理自己的逻辑，便于扩展和测试，实现了低耦合的结构。通过观察者模式，新的观察者可以轻松添加，无需修改事件源的代码

观察者模式的适用场景

需要在事件发生时通知多个模块：例如支付成功、订单更新等事件发生时，系统需要通知多个模块执行不同的操作（如更新订单状态、记录日志、发送通知等）。
动态添加或移除响应操作：在某些场景下，系统可能需要根据具体情况动态增加或移除对某个事件的响应操作。观察者模式允许我们在不修改核心代码的情况下实现这种灵活性。
减少模块之间的耦合：当一个模块发生变化时，不需要知道具体哪些模块会受到影响，观察者模式可以让被观察的事件源与观察者模块解耦，确保变化只影响自身。

通过观察者模式，系统可以灵活地管理事件和响应，增加扩展性和维护性，非常适合需要触发多个独立操作的业务场景。

观察者模式在实际业务中的应用场景

订单支付成功后的多步骤操作：在支付成功后，系统可能需要更新订单状态、通知用户、记录日志等。观察者模式可以让每个操作作为独立的观察者订阅支付事件，确保在事件触发时所有订阅的操作都能自动执行。
电商促销活动的更新通知：当促销活动信息变更时，系统需要更新相关的商品页面、推送消息给用户、发送库存提醒等。观察者模式可以将这些操作解耦，每个模块独立处理自己的响应逻辑。
库存变化通知：在仓储或库存管理系统中，当库存变化时可以触发不同的模块响应，如提醒销售端、更新库存报表、通知供应链等。通过观察者模式，每个模块都可以独立订阅库存变化事件并做出反应。
日志监控和报警：在监控系统中，多个模块可能对同一日志事件产生响应，例如发送邮件报警、短信通知、记录错误等。通过观察者模式，每种报警方式可以独立实现并根据需求灵活添加或移除。
消息通知系统：在社交应用中，当用户发布动态时，可以通知好友或相关的推荐模块。观察者模式允许好友和推荐模块独立订阅动态发布事件，在事件发生时获取更新。
系统配置或环境变更：在大型系统中，当系统配置变更时，可以通过观察者模式触发多个模块响应，如更新缓存、重新加载配置等，确保配置变更影响到各个相关模块。
用户操作后的事件触发：在用户注册、登录、或操作行为后，可以触发不同的观察者操作，如记录用户行为日志、分析用户活跃度、发送欢迎通知等。观察者模式可以确保这些操作独立执行，方便后期扩展和维护。

通过观察者模式，系统可以在事件触发后自动通知所有相关模块，减少模块间的耦合关系，并提升系统的扩展性和灵活性，非常适合需要触发多种响应操作的业务场景。

在业务中使用观察者模式的好处

降低代码耦合：观察者模式将事件源与响应操作解耦，使得事件触发方和响应方不必直接依赖。每个观察者可以独立开发、测试和维护，避免了模块间的强耦合。
提高扩展性：通过将每个响应操作独立为观察者，观察者模式使得系统可以轻松添加或移除观察者，无需修改事件源代码，符合“开闭原则”（对扩展开放，对修改封闭）。
消除复杂的条件判断：观察者模式避免了在事件触发代码中堆积多个if-else或switch语句，通过观察者自动响应事件，保持代码清晰和简洁。
提高代码复用性：每个观察者类都可以在不同的事件源中复用。例如，通知用户的观察者既可以应用于支付成功事件，也可以应用于订单发货等其他场景。
便于单元测试：每个观察者可以单独进行单元测试，不必测试整个事件流程。这样便于确保每个响应操作的逻辑正确性，同时提高了测试覆盖率。
动态添加和移除观察者：在运行时可以灵活地添加或移除观察者，适应不同的业务需求。例如，根据用户的角色或状态选择不同的通知方式，满足个性化需求。

通过观察者模式，系统可以轻松管理事件与响应的关系，使代码更加灵活和易于维护，特别适合在事件驱动和多操作场景中实现低耦合和高扩展性。

开头业务场景的优化方案

如果在上述业务场景中使用观察者模式进行优化重构，我们可以将每一个后续操作（如更新订单状态、通知用户、记录日志等）设计为独立的观察者，使得事件源（支付成功）只需负责通知所有观察者，而不需要直接依赖于具体操作。这样可以灵活地添加或移除新的观察者，而不必修改核心支付流程的代码。

代码示例

首先，我们定义一个观察者接口，表示所有支付成功后的操作：

interface Observer {
    public function update($order);
}

然后，为每个具体操作实现相应的观察者类：

class UpdateOrderStatus implements Observer {
    public function update($order) {
        // 更新订单状态的逻辑
        echo "订单状态已更新\n";
    }
}

class AddMembership implements Observer {
    public function update($order) {
        // 添加会员标识的逻辑
        echo "用户已添加会员标识\n";
    }
}

class NotifyUser implements Observer {
    public function update($order) {
        // 通知用户的逻辑
        echo "已通知用户支付成功\n";
    }
}

class LogPaymentSuccess implements Observer {
    public function update($order) {
        // 记录日志的逻辑
        echo "支付成功日志已记录\n";
    }
}

接着，我们设计一个事件源类（如PaymentService），用于管理和通知所有观察者：

class PaymentService {
    private $observers = [];

    // 添加观察者
    public function addObserver(Observer $observer) {
        $this->observers[] = $observer;
    }

    // 支付成功时通知所有观察者
    public function onPaymentSuccess($order) {
        foreach ($this->observers as $observer) {
            $observer->update($order);
        }
    }
}

最后，客户端代码可以根据需求动态添加观察者，实现支付成功后的所有操作：

// 创建支付服务实例
$paymentService = new PaymentService();

// 添加支付成功后的各个操作观察者
$paymentService->addObserver(new UpdateOrderStatus());
$paymentService->addObserver(new AddMembership());
$paymentService->addObserver(new NotifyUser());
$paymentService->addObserver(new LogPaymentSuccess());

// 模拟支付成功后的操作
$order = "订单信息"; // 示例订单
$paymentService->onPaymentSuccess($order);

优化后的好处

通过这种重构设计：

灵活性：可以轻松添加或移除新的支付成功后操作，而不必修改主流程代码。
低耦合：每个观察者都是独立的类，专注于单一职责，遵循“单一职责原则”，便于维护和复用。
清晰的逻辑：事件源（支付服务）代码只需负责通知观察者，具体操作的实现完全解耦。

这种设计方式使得代码更具扩展性和灵活性，符合观察者模式的核心思想。

最后

通过观察者模式的优化设计，我们成功将支付成功后的多种操作分离为独立的观察者类，使得业务逻辑更加清晰、灵活。这样不仅降低了代码的耦合度，还实现了支付流程的扩展性，使得后续新增需求时无需修改主流程代码。此外，每个观察者类具有单一职责，便于独立测试和复用，符合面向对象设计中的开闭原则和单一职责原则。

观察者模式帮助我们在复杂业务逻辑中实现了高内聚、低耦合，极大地提升了系统的可维护性和扩展性，是处理多种事件响应场景的理想选择。