在观察者模式中，主体直接通知其观察者。

本文将通过两道手撕面试题代码，深入剖析这两种模式的核心原理、实现方式，以及它们之间的本质区别。

EventObserver
│
├── subscribe: adds new observable events
│
├── unsubscribe: removes observable events
|
└── broadcast: executes all events with bound data

咱就是说观察者模式和发布订阅模式，这两个玩意儿，其实hen多人搞混了但它们真的不是一回事儿。害，今天咱就来好好掰扯掰扯。

你懂的，设计模式这玩意儿，听起来高大上，其实说白了就是代码里的“人际关系”处理方式。你想想，一个对象状态变了其他一堆对象要跟着动，这不就是咱们生活里的“一荣俱荣，一损俱损”嘛。

先说说观察者模式，它就像一个“小喇叭”，被观察者一有动静，就直接喊话给所有观察者：“我变了！你们快点geng新！”

而发布订阅模式呢，它geng像一个“中介”，发布者把消息发给中介，中介再去找对应的订阅者。这样发布者和订阅者之间就完全解耦了谁也不认识谁，全靠中介传话。

你懂的，这俩模式虽然kan起来差不多，但实现方式和使用场景可差远了。咱一个一个来别急，慢慢来。

观察者模式

咱先从观察者模式说起。这玩意儿，简单粗暴，就是“一对多”。

你想想，一个对象维护一个观察者列表，一旦自己状态变了就遍历这个列表，挨个通知。是不是有点像老师点名，点到谁，谁就geng新一下自己。

来咱kan个例子：

class Observable {
  constructor {
    this.observers = ;
  }
  subscribe {
    this.observers.push;
  }
  unsubscribe {
    this.observers = this.observers.filter;
  }
  notify {
    this.observers.forEach);
  }
}

这个是基础的观察者模式实现，是不是hen清晰？

你懂的，这个模式Zui大的好处就是简单直接，适合对象之间耦合度不高的场景。比如你写个博客系统，字数统计、标题geng新、内容保存这些模块，douKe以通过观察者模式来实现同步geng新。

比如你写个字数统计功Neng，用户每输入一个字，就通知所有观察者geng新字数。这个场景下观察者模式就特别合适。

class Observerd {
    constructor {
        this.name = name;
        this.state = "走路";
        this.observers = ;
    }
    setObserver {
        this.observers.push;
    }
    setState {
        this.state = state;
        this.notifyAllObservers;
    }
    notifyAllObservers {
        this.observers.forEach(observer => {
            observer.update;
        });
    }
}
class Observer {
    update {
        console.log;
    }
}

你kan，这个例子中，被观察者一调用setState，观察者就收到通知，然后打印出“小明正在走路”或者“小明正在跑步”。

这不就实现了观察者模式的核心思想嘛：一个对象状态变了其他对象自动geng新。

你懂的，这种模式Zui大的问题就是耦合度高，Ru果观察者太多，通知起来就慢了。所以它适合小范围、对象不多的场景。

发布订阅模式

发布订阅模式就不一样了它有个“中间商”，专门负责消息的中转。发布者只管发消息，订阅者只管收消息，谁也不认识谁。

比如window上的事件，就是发布订阅模式的典型实现。你想想，你给window加个事件监听，比如addEventListener，然后在某个地方触发dispatchEvent，事件就传过去了。这不就是“发布-订阅”嘛。

// ========== window 作为事件调度中心 ==========
// . 订阅 ：监听一个自定义事件
window.addEventListener => {
    console.log;
});
// . 发布 ：在任意地方触发事件
function login {
    // ... 登录逻辑 ...
    const customEvent = new CustomEvent('user-logged-in', {
        detail: { id: , name: '张三' }
    });
    window.dispatchEvent;
}
// . 取消订阅 
const handler =  => { console.log; };
window.addEventListener;
// 不再需要时移除
window.removeEventListener;

你kan，这种模式的好处就是解耦，发布者和订阅者之间没有直接联系，全靠事件系统来协调。这样系统就灵活多了。

再比如你写个EventEmitter类，也是发布订阅模式的体现：

class EventEmitter {
    constructor {
        this.events = {};
    }
    on {
        if  {
            this.events = ;
        }
        this.events.push;
    }
    emit {
        const callbacks = this.events;
        if  {
            callbacks.forEach(callback => {
                callback;
            });
        }
    }
}

这个模式下你Ke以在任意地方订阅事件，然后在任意地方发布事件，系统会自动帮你传话。是不是hen爽？

你懂的，这种模式特别适合大型系统，模块之间解耦，互不影响。比如你写个博客系统，用户登录、文章geng新、评论通知这些模块，douKe以通过事件系统来通信，谁也不用管谁。

优点

关注点分离

符合单一职责原则

观察者和被观察者低耦合

缺点

观察者过多时通知所有观察者可Neng带来性Neng问题

说实话，这两种模式各有千秋。观察者模式适合小范围、强耦合的场景，比如组件内部通信；而发布订阅模式适合大范围、松耦合的场景，比如模块间通信。

咱就是说理解了这两个模式，你就Neng在写代码的时候游刃有余了。想一想，你是不是也遇到过类似的需求？比如一个输入框，用户每次输入dou要geng新字数，或者一个按钮点击后要通知多个模块geng新状态，这些douKe以用这两种模式来解决。

害，信息量有点大，我也是初次深入学习一下这些概念，感觉脑子dou快不够用了。不过理解了这些，你就Neng写出geng优雅的代码了。

Zui后咱再啰嗦一句，这两种模式虽然kan起来简单，但实际应用中可不简单。你得根据具体场景来选择合适的模式。别kan我这说得头头是道，其实我也是边学边有不足的地方还请不吝赐教哈。

设计模式这玩意儿，就是让你的代码geng优雅、geng易维护。你懂的，代码写得好不好，就kan设计模式用得溜不溜。

好了今天就到这里下回咱再聊聊别的。

---