概念

觀察者模式，原理很簡(jiǎn)單，把A類的子類分別注入到B類中，通過(guò)用B類調(diào)用方法，循環(huán)調(diào)用A類的方法，就是所謂觀察者模式

偽代碼如下，最快的速度理解觀察者模式：

接口 A{// 觀察者接口notify(); } Class A1 extend A{// 等待被調(diào)的接口notify(){// A1類特有的實(shí)現(xiàn)println(A1被通知);} } Class A2 extend A{notify(){println(A2被通知);} } Class B{List<A> alist;addA(A a){//將觀察者注入到B中alist.add(a);}void notify(){for(A a : alist){// 循環(huán)通知每一個(gè)A的實(shí)現(xiàn)對(duì)象a.notify();}} } Class Test{main方法(){// 定義通知者BB b = new B();// 將兩個(gè)觀察者A1,A2注冊(cè)到B中b.addA(new A1());b.addA(new A2());// 當(dāng)B發(fā)出通知后，就會(huì)循環(huán)調(diào)用那些曾經(jīng)在自己這里注冊(cè)過(guò)的觀察者b.notify();} }

觀察者使用場(chǎng)景

上面的偽代碼，是最簡(jiǎn)單的觀察者模式的原型。
觀察者模式一般用于一個(gè)變化（B的notify方法）要引起多個(gè)變化（A的notify方法）的場(chǎng)景。比如我執(zhí)行完一個(gè)操作后，需要同時(shí)執(zhí)行好幾個(gè)方法。

舉個(gè)例子：消息通知

當(dāng)系統(tǒng)生成一條消息后，需要同時(shí)發(fā)送系統(tǒng)消息，郵件消息，短信消息，甚至以后還會(huì)有其他類型的消息。
那就可以搞個(gè)消息的父類A，定義好發(fā)送接口notify。
后面每種消息都是A的子類，然后有著自己的發(fā)消息的不同實(shí)現(xiàn)。
然后搞個(gè)發(fā)消息的類B，提前將A的這些子類注冊(cè)給B，當(dāng)系統(tǒng)產(chǎn)生消息的時(shí)候，只需要調(diào)用B的發(fā)送，就可以將消息發(fā)給各個(gè)地方了。

再舉個(gè)例子：地主剝削

地主就是那個(gè)通知者
所有長(zhǎng)工都是觀察者
每個(gè)長(zhǎng)工，都要觀察地主的命令。比如地主說(shuō)打掃衛(wèi)生，然后在地主那里注冊(cè)的所有長(zhǎng)工，都開(kāi)始打掃衛(wèi)生。如果新來(lái)了長(zhǎng)工，那就在地主那里注冊(cè)下，下次地主再發(fā)命令，新來(lái)的長(zhǎng)工也就和之前的長(zhǎng)工一樣了。

觀察者的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：解耦了觀察者，可以很容易的新增多個(gè)觀察者。
缺點(diǎn)：觀察者和通知者耦合，就是上面?zhèn)未a中，A和B是耦合的。

為了解決這個(gè)缺點(diǎn)，于是有了觀察者模式的升級(jí)版：發(fā)布訂閱模式

發(fā)布訂閱模式

發(fā)布訂閱模式，一聽(tīng)都比較熟悉，因?yàn)槲覀冇玫膍q就是基于發(fā)布訂閱模式
發(fā)布訂閱模式，就是觀察者模式的增強(qiáng)版。
哪里增強(qiáng)了呢？我們知道觀察者模式中，觀察者和通知者是耦合的，是不能隨意更換的。那發(fā)布訂閱模式就是解了這種耦合。
將以前的通知者，叫發(fā)布者
將以前的觀察者，叫訂閱者
然后發(fā)布者和訂閱者中間有個(gè)第三方，記錄發(fā)布者和訂閱者的關(guān)系，即誰(shuí)訂閱了誰(shuí)
那么從此發(fā)布者和調(diào)用者，就不用互相耦合了。

除了mq，簡(jiǎn)單的還可以研究下google的eventbus，可以參考我之前的一篇文章，有現(xiàn)成的能運(yùn)行的例子，可以去感受一下。
spring boot 整合 谷歌guava的EventBus 實(shí)現(xiàn)單機(jī)版的消息發(fā)布訂閱

總結(jié)

以上是生活随笔為你收集整理的[设计模式] ------ 观察者模式和他的升级版发布订阅模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。