觀察者模式

所謂觀察者模式，主要目的是為了松耦合，舉一個(gè)例子說(shuō)明，當(dāng)玩家擊殺怪物后可以獲得對(duì)應(yīng)的獎(jiǎng)勵(lì)，那么玩家需要關(guān)注怪物死亡這一事件，每當(dāng)怪物死亡的時(shí)候，玩家獲得獎(jiǎng)勵(lì)的方法就會(huì)被調(diào)用，玩家需要時(shí)刻關(guān)注所有的潛在的可能被擊殺的怪物，非常的不方便，同時(shí)如果怪物的腳本出現(xiàn)了問(wèn)題也可能影響到玩家的正常操控。我們希望的是，當(dāng)怪物死亡的時(shí)候才讓玩家知道“怪物已經(jīng)死亡了”這個(gè)消息，就好比我網(wǎng)購(gòu)了某樣?xùn)|西，我并不關(guān)心貨物是怎么送過(guò)來(lái)，只需要送到之后告訴我“快遞到了”這個(gè)消息，然后我就會(huì)執(zhí)行取快遞這個(gè)行為。這樣就把我和送快遞的流程隔開(kāi)了。

在上述的例子中，我就是觀察者，快遞員就是被觀察者，快遞員送到快遞之后就會(huì)通知我，然后我執(zhí)行我的取快遞方法。

發(fā)布訂閱模式

大多數(shù)情況下可以將發(fā)布訂閱模式里的Publisher，理解為觀察者模式里的Subject，而Subscriber，就是Observer。區(qū)別在于Publisher變化時(shí)，并不會(huì)主動(dòng)去通知Subscriber。還是用送快遞方式來(lái)舉例，當(dāng)快遞業(yè)務(wù)達(dá)到一定量的時(shí)候，快遞員數(shù)量不夠，送貨上門(mén)效率就會(huì)變低，這個(gè)時(shí)候就引入了菜鳥(niǎo)驛站的概念，快遞員把貨物送到菜鳥(niǎo)驛站，顧客去菜鳥(niǎo)驛站取貨，兩者并不直接接觸，而是通過(guò)中轉(zhuǎn)站也就是Broker。

快遞員告訴菜鳥(niǎo)驛站XXX的快遞到了，菜鳥(niǎo)驛站轉(zhuǎn)述給XXX：你的貨物到了自取，XXX來(lái)到菜鳥(niǎo)驛站：我要取XXX的快遞。發(fā)布訂閱模式里，發(fā)布者和訂閱者，不是松耦合，而是完全解耦的。從本質(zhì)上來(lái)說(shuō)發(fā)布者和訂閱者分別和Broker也是松耦的，但是解耦出來(lái)的broker里可以做得更多. 比如:在里面分別對(duì)發(fā)布者和訂閱這使用職責(zé)鏈模式進(jìn)行執(zhí)行順序調(diào)整和過(guò)濾,以及設(shè)置整個(gè)鏈條的終止條件等很多邏輯.

當(dāng)然采用哪種方式其實(shí)和快遞的多少并沒(méi)有直接的聯(lián)系，需要從發(fā)送消息的對(duì)象和接受消息的對(duì)象做判斷，例如 端午節(jié)公司發(fā)粽子，這件事是由行政部門(mén)決定的，公司員工和行政部門(mén)同處于公司一個(gè)主體下面，這件事不方便交給第三方做，需要親手交到員工手上，也就是觀察者模式。對(duì)于送快遞來(lái)說(shuō)，顧客與快遞員并沒(méi)有直接聯(lián)系，也不希望產(chǎn)生過(guò)多的糾紛，那么中轉(zhuǎn)站的存在就是合理的。

用C#寫(xiě)一個(gè)簡(jiǎn)單的事件處理中心，代碼如下

根據(jù)事件的需求，重載不同數(shù)量的參數(shù)嗎(action最多四個(gè)參數(shù))，這是一個(gè)簡(jiǎn)單地事件中心的實(shí)現(xiàn)。