Lambda时代的Observer Pattern：现代实现与相关疑问

传统的观察者模式要求观察者实现update()方法，不过借助C++的Lambda表达式，我们可以采用另一种实现方式：

#include <functional>
#include <vector>
#include <iostream>

class Subject
{
public:
   using CallbackClosure = std::function<void()>;
   void RegisterCallback(CallbackClosure&& cb) {
      closures_.push_back(std::move(cb));
   }

   void test() {
       for (auto const& cb : closures_) {
           cb();
       }
   }

private:
   std::vector<CallbackClosure> closures_;
};

// 使用示例
int main()
{
   Subject s;
   // 这里用Lambda注册回调，而非观察者对象指针
   s.RegisterCallback([]{ std::cout << "Hey from main\n"; });
   s.test();

   return 0;
}

当然，我们可以将RegisterCallback设为纯虚函数，让不同的主题类实现该接口，但上述代码已足以说明核心思路。

技术问题解答 #

1. 这种实现是否是观察者模式的现代做法？

是的，这属于观察者模式的现代轻量化实现。传统实现依赖类继承与接口约束，而基于Lambda/函数对象的方式利用C11及以后的函数式特性，更灵活简洁，避免了为简单场景定义大量冗余观察者类的问题，也契合现代C"组合优于继承"的设计原则。

2. 为观察者定义update接口是否仍有优势？

依然有不可替代的价值：

• 规范性与可维护性：统一的update接口能明确观察者职责，团队协作时更易理解代码结构，避免回调逻辑的随意性。
• 状态封装：传统观察者类可封装自身状态，处理主题通知时能安全复用内部状态；而Lambda捕获外部状态时，容易引发生命周期管理问题（比如悬空引用）。
• 扩展性：当需要给观察者添加attach/detach自定义逻辑、状态查询等额外方法时，类接口的方式比零散Lambda更易扩展。
• 类型安全：基于接口的实现能在编译期确保观察者符合约定，Lambda回调的类型检查相对松散，易出现签名不匹配问题。

3. Lambda能否被视为匿名观察者？

可以。从观察者模式的核心逻辑来看，观察者的本质是能响应主题通知的行为载体：

• Lambda本身是可调用对象，封装了响应主题通知的逻辑，和传统观察者类的update方法承担的角色完全一致。
• 它没有显式类名与实例名称，因此可看作匿名的观察者实例，只是省略了传统模式中观察者类的定义与实例化步骤，直接将响应逻辑作为参数传递给主题。

内容的提问来源于stack exchange，提问作者SupAl