一 觀察者模式
觀察者模式定義了對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都將得到通知，並自動更新。觀察者模式屬於行爲型模式，行爲型模式關注的是對象之間的通訊，觀察者模式就是觀察者和被觀察者之間的通訊。
簡單實現就是被觀察者裏面存儲了觀察者的對象列表，當被觀察者發生某種行爲時，會回調觀察者的方法。抽象代碼如下：
public abstract class Subject {
private List<Observer> observers=new ArrayList<Observer>();//用於保存已訂閱的目標的觀察者
public void attach(Observer observer){//訂閱目標對象
observers.add(observer);
}
public void detach(Observer observer){//解除訂閱關係
observers.remove(observer);
}
protected void notifyObserver(){//通知已訂閱的觀察者
for (Observer observer : observers) {
observer.updata(this);
}
}
}
二 發佈訂閱模式
在軟件架構中，發佈-訂閱是一種消息範式，消息的發送者（稱爲發佈者）不會將消息直接發送給特定的接收者（稱爲訂閱者）。而是將發佈的消息分爲不同的類別，無需瞭解哪些訂閱者（如果有的話）可能存在。同樣的，訂閱者可以表達對一個或多個類別的興趣，只接收感興趣的消息，無需瞭解哪些發佈者（如果有的話）存在。
完成訂閱發佈整個流程需要三個角色：
- 發佈者
- 事件中心
- 訂閱者
三 觀察者模式與發佈訂閱模式區別
先一張圖看看這兩者的區別：
可以看出，發佈訂閱模式相比觀察者模式多了個事件通道，事件通道作爲調度中心，管理事件的訂閱和發佈工作，徹底隔絕了訂閱者和發佈者的依賴關係。即訂閱者在訂閱事件的時候，只關注事件本身，而不關心誰會發布這個事件；發佈者在發佈事件的時候，只關注事件本身，而不關心誰訂閱了這個事件。
觀察者模式有兩個重要的角色，即目標和觀察者。在目標和觀察者之間是沒有事件通道的。一方面，觀察者要想訂閱目標事件，由於沒有事件通道，因此必須將自己添加到目標(Subject)
中進行管理；另一方面，目標在觸發事件的時候，也無法將通知操作(notify) 委託給事件通道，因此只能親自去通知所有的觀察者。
差異總結：
- 角色角度來看，訂閱發佈模式需要三種角色，發佈者、事件中心和訂閱者。二觀察者模式需要兩種角色，目標和觀察者，無事件中心負責通信。
- 從耦合度上來看，訂閱發佈模式是一個事件中心調度模式，訂閱者和發佈者是沒有直接關聯的，通過事件中心進行關聯，兩者是解耦的。而觀察者模式中目標和觀察者是直接關聯的，耦合在一起（有些觀念說觀察者是解耦，解耦的是業務代碼，不是目標和觀察者本身）。
四 觀察者模式與發佈訂閱模式優缺點
訂閱發佈模式優點
靈活
由於訂閱發佈模式的發佈者和訂閱者是解耦的，只要引入訂閱發佈模式的事件中心，無論在何處都可以發佈訂閱。同時訂閱發佈者相互之間不影響。
訂閱發佈模式在使用不當的情況下，容易造成數據流混亂，所以纔有了 React 提出的單項數據流思想，就是爲了解決數據流混亂的問題。
訂閱發佈模式缺點
容易導致代碼不好維護
靈活是有點，同時也是缺點，使用不當就會造成數據流混亂，導致代碼不好維護。
性能消耗更大
訂閱發佈模式需要維護事件列隊，訂閱的事件越多，內存消耗越大。
觀察者模式優點
響應式
目標變化就會通知觀察者，這是觀察者最大的有點，也是因爲這個優點，觀察者模式在前端纔會這麼出名。
觀察者模式缺點
不靈活
相比訂閱發佈模式，由於目標和觀察者是耦合在一起的，所以觀察者模式需要同時引入目標和觀察者才能達到響應式的效果。而訂閱發佈模式只需要引入事件中心，訂閱者和發佈者可以不再一處。
參考：
https://segmentfault.com/a/1190000020169229
https://www.cnblogs.com/onepixel/p/10806891.html