一、前言

知道的越多不知道的就越多

編程開發這條路上的知識是無窮無盡的，就像以前你敢說精通Java，到后來學到越來越多只想寫了解Java，過了幾年現在可能想說懂一點點Java。當視野和格局的擴大，會讓我們越來越發現原來的看法是多么淺顯，這就像站在地球看地球和站在宇宙看地球一樣。但正因為胸懷和眼界的提升讓我們有了更多的認識，也逐漸學會了更多的技能。雖然不知道的越來越多，但也因此給自己填充了更多的技術棧，讓自己越來越強大。

拒絕學習的惰性很可怕

現在與以前不一樣，資料多、途徑廣，在這中間夾雜的廣告也非常多。這就讓很多初學者很難找到自己要的知識，最后看到有人推薦相關學習資料立刻屏蔽、刪除，但同時技術優秀的資料也不能讓需要的人看見了。久而久之把更多的時間精力都放在游戲、娛樂、影音上，適當的放松是可以的，但往往沉迷以后就很難出來，因此需要做好一些可以讓自己成長的計劃，稍有克制。

平衡好軟件設計和實現成本的度°

有時候一個軟件的架構設計需要符合當前條件下的各項因素，往往不能因為心中想當然的有某個藍圖，就去開始執行。也許雖然你的設計是非常優秀的，但是放在當前環境下很難滿足業務的時間要求，當一個業務的基本訴求不能滿足后，就很難拉動市場。沒有產品的DAU支撐，最后整個研發的項目也會因此停滯。但研發又不能一團亂麻的寫代碼，因此需要找好一個適合的度，比如可以搭建良好的地基，實現上可擴展。但在具體的功能上可以先簡化實現，隨著活下來了再繼續完善迭代。

二、開發環境

JDK 1.8

Idea + Maven

三、觀察者模式介紹

簡單來講觀察者 模式，就是當一個行為發生時傳遞信息給另外一個用戶接收做出相應的處理，兩者之間沒有直接的耦合關聯。例如；狙擊手、李云龍。

除了生活中的場景外，在我們編程開發中也會常用到一些觀察者的模式或者組件，例如我們經常使用的MQ服務，雖然MQ服務是有一個通知中心并不是每一個類服務進行通知，但整體上也可以算作是觀察者模式的思路設計。再比如可能有做過的一些類似事件監聽總線，讓主線服務與其他輔線業務服務分離，為了使系統降低耦合和增強擴展性，也會使用觀察者模式進行處理。

四、案例場景模擬

http://weixin.qq.com/r/W0Rqco7EptPZrcoR9xFJ (二維碼自動識別)

在本案例中我們模擬每次小客車指標搖號事件通知場景(真實的不會由官網給你發消息)

可能大部分人看到這個案例一定會想到自己每次搖號都不中的場景，收到一個遺憾的短信通知。當然目前的搖號系統并不會給你發短信，而是由百度或者一些其他插件發的短信。那么假如這個類似的搖號功能如果由你來開發，并且需要對外部的用戶做一些事件通知以及需要在主流程外再添加一些額外的輔助流程時該如何處理呢？

基本很多人對于這樣的通知事件類的實現往往比較粗獷，直接在類里面就添加了。1是考慮 這可能不會怎么擴展，2是壓根就沒考慮 過。但如果你有仔細思考過你的核心類功能會發現，這里面有一些核心主鏈路，還有一部分是輔助功能。比如完成了某個行為后需要觸發MQ給外部，以及做一些消息PUSH給用戶等，這些都不算做是核心流程鏈路，是可以通過事件通知的方式進行處理。

那么接下來我們就使用這樣的設計模式來優化重構此場景下的代碼。

1. 場景模擬工程

itstack

這里提供的是一個模擬小客車搖號的服務接口。

2. 場景簡述

2.1 搖號服務接口

public

非常簡單的一個模擬搖號接口，與真實公平的搖號是有差別的。

五、用一坨坨代碼實現

這里我們先使用最粗暴的方式來實現功能

按照需求需要在原有的搖號接口中添加MQ消息發送以及短消息通知功能，如果是最直接的方式那么可以直接在方法中補充功能即可。

1. 工程結構

itstack

這段代碼接口中包括了三部分內容；返回對象(LotteryResult)、定義接口(LotteryService)、具體實現(LotteryServiceImpl)。

2. 代碼實現

public

從以上的方法實現中可以看到，整體過程包括三部分；搖號、發短信、發MQ消息，而這部分都是順序調用的。

除了搖號接口調用外，后面的兩部分都是非核心主鏈路功能，而且會隨著后續的業務需求發展而不斷的調整和擴充，在這樣的開發方式下就非常不利于維護。

3. 測試驗證

3.1 編寫測試類

@Test

測試過程中提供對搖號服務接口的調用。

3.2 測試結果

22:

從測試結果上是符合預期的，也是平常開發代碼的方式，還是非常簡單的。

六、觀察者模式重構代碼

接下來使用觀察者模式來進行代碼優化，也算是一次很小的重構。

1. 工程結構

itstack

觀察者模式模型結構

從上圖可以分為三大塊看；事件監聽、事件處理、具體的業務流程，另外在業務流程中 LotteryService 定義的是抽象類，因為這樣可以通過抽象類將事件功能屏蔽，外部業務流程開發者不需要知道具體的通知操作。

右下角圓圈圖表示的是核心流程與非核心流程的結構，一般在開發中會把主線流程開發完成后，再使用通知的方式處理輔助流程。他們可以是異步的，在MQ以及定時任務的處理下，保證最終一致性。

2. 代碼實現

2.1 事件監聽接口定義

public

接口中定義了基本的事件類，這里如果方法的入參信息類型是變化的可以使用泛型<T>

2.2 兩個監聽事件的實現

短消息事件

public

MQ發送事件

public

以上是兩個事件的具體實現，相對來說都比較簡單。如果是實際的業務開發那么會需要調用外部接口以及控制異常的處理。

同時我們上面提到事件接口添加泛型，如果有需要那么在事件的實現中就可以按照不同的類型進行包裝事件內容。

2.3 事件處理類

public

整個處理的實現上提供了三個主要方法；訂閱(subscribe)、取消訂閱(unsubscribe)、通知(notify)。這三個方法分別用于對監聽時間的添加和使用。

另外因為事件有不同的類型，這里使用了枚舉的方式進行處理，也方便讓外部在規定下使用事件，而不至于亂傳信息(EventType.MQ、EventType.Message)。

2.4 業務抽象類接口

public

這種使用抽象類的方式定義實現方法，可以在方法中擴展需要的額外調用。并提供抽象類abstract LotteryResult doDraw(String uId)，讓類的繼承者實現。

同時方法的定義使用的是protected，也就是保證將來外部的調用方不會調用到此方法，只有調用到draw(String uId)，才能讓我們完成事件通知。

此種方式的實現就是在抽象類中寫好一個基本的方法，在方法中完成新增邏輯的同時，再增加抽象類的使用。而這個抽象類的定義會有繼承者實現。

另外在構造函數中提供了對事件的定義；eventManager.subscribe(EventManager.EventType.MQ, new MQEventListener())。

在使用的時候也是使用枚舉的方式進行通知使用，傳了什么類型EventManager.EventType.MQ，就會執行什么事件通知，按需添加。

2.5 業務接口實現類

public

現在再看業務流程的實現中可以看到已經非常簡單了，沒有額外的輔助流程，只有核心流程的處理。

3. 測試驗證

3.1 編寫測試類

@Test

從調用上來看幾乎沒有區別，但是這樣的實現方式就可以非常方便的維護代碼以及擴展新的需求。

3.2 測試結果

23:

從測試結果上看滿足 我們的預期，雖然結果是一樣的，但只有我們知道了設計模式的魅力所在。

七、總結

從我們最基本的過程式開發以及后來使用觀察者模式面向對象開發，可以看到設計模式改造后，拆分出了核心流程與輔助流程的代碼。一般代碼中的核心流程不會經常變化。但輔助流程會隨著業務的各種變化而變化，包括；營銷、裂變、促活等等，因此使用設計模式架設代碼就顯得非常有必要。

此種設計模式從結構上是滿足開閉原則的，當你需要新增其他的監聽事件或者修改監聽邏輯，是不需要改動事件處理類的。但是可能你不能控制調用順序以及需要做一些事件結果的返回繼續操作，所以使用的過程時需要考慮場景的合理性。

任何一種設計模式有時候都不是單獨使用的，需要結合其他模式共同建設。另外設計模式的使用是為了讓代碼更加易于擴展和維護，不能因為添加設計模式而把結構處理更加復雜以及難以維護。這樣的合理使用的經驗需要大量的實際操作練習而來。

作者：小傅哥

鏈接：人類身份驗證 - SegmentFault

總結

以上是生活随笔為你收集整理的java 观察者模式_重学 Java 设计模式：实战观察者模式「模拟类似小客车指标摇号过程，监听消息通知用户中签场景」...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。