java設計模式中觀察者模式怎么實現

這篇文章將為大家詳細講解有關java設計模式中觀察者模式怎么實現，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

具體的代碼如下。

我們看輸出實現了我們想要的結果，也就是當訂單發生更新時，其他3個系統都會收到信息。但我們在之前的文章中提到過，我們在設計系統時，不要針對實現編程，要針對接口編程，這樣程序比較方便擴展。按照我們上述的代碼，如果我們要添加新的系統，例如卡卷系統 ，那么這時我們就要修改曾經已經編寫好的代碼，也就是OrderSuccess接口，那這就違背了設計模式的基本原則了。顯然上述的代碼，雖然可以實現需求，但是卻不是最好的，因為不方便擴展。那么怎么辦？我們分析需求知道這顯然是一個一對多的關系，當訂單更新時，其他和它相關的系統都需要接到通知然后更新，類似報紙訂閱是一樣的，只要報紙發生變化，那么訂閱該報紙的人都能知道。其實，這就是典型的觀察者模式。下面我們先看一下觀察者模式的定義。

觀察者模式：定義了對象之間的一對多依賴，這樣一來，當一個對象改變狀態時，它的所有依賴者都會收到通知并自動更新。

我們在說的簡單點比如對一個有狀態的對象，我們稱之為主題對象，然后我們有一堆和主題對象依賴的對象，我們叫它觀察者對象。這樣當主題對象更新時，觀察者對象會自動收到通知并更新。

按照我們上面的代碼怎么把他們修改為觀察者模式呢？我們按之前學到的知識應該對接口編程，而不是對實現編程。所以我們應該抽取出兩個接口一個是主題接口，一個是觀察者接口。這樣主題只知道了觀察者都實現了觀察者接口，而主題不需要知道觀察者具體的類是誰，這樣在任何時候我們都可以隨時增加新的觀察者，只要實現觀察者接口就可以了。而主題并不做任何的修改，因為主題對象唯一依賴的東西是一個實現了觀察者接口的對象列表，所以我們可以隨時添加任意的觀察者，而主題對象并不需要做任何的更新，這就遵循了設置模式的原則，將對象中可能變化的部分提取出來，這樣當其他對象變化時，該對象不需要做任何的更改。這里我們還有一個重要的設置模式原則，也就是為交互對象之間的松耦合設計而努力。在說的直白點就是我們在設計系統時應該將對象與對象之間的耦合度設計的盡量低，耦合度越低，對象與對象的依賴關系也就越低，這樣也就方便我們更好的擴展。

那我們應該怎么將上述的代碼修改為觀察者模式呢？通過以前的知識我們知道應該對接口編程，而不是對實現編程，因為這樣我們比較方便擴展。所以我們應該將上述代碼中涉及到的物流系統、商品系統、積分系統抽象出一個公共的接口，同理我們也將訂單抽象出一個接口，這樣的好處是，當創建新的子類時，對接口的編程代碼是不需要變化的，這就遵循了我們上述提到過的松耦合了。下面我們將上述代碼修改為真正的觀察者模式，具體代碼如下：

這樣我們就將上述的代碼修改為真正的觀察者模式的代碼，這樣的好處就是非常方便我們的擴展，我們在新添加新的系統時，而并不需要修改曾經已經開發好的代碼，也就是訂單中的已有的代碼，這樣就真正做到了可擴展了。下面我們將新增一個卡卷系統，來證明我們上述所說的可擴展性。

快看，我們成功的將新的卡卷系統添加到了這個觀察者了，并且它成功收到了訂單變更的通知，并且我們并沒有修改任何有關訂單的代碼，這就是我們上面所說的低耦合，這也就是觀察者模式的好處。

到這里，我們已經將觀察者模式都介紹完了，本應該到這里就結束了，但這個觀察者模式有點特別，Java為了我們更方便的使用觀察者模式，所以在Java中直接內置的支持觀察者模式，也就是我們自己并不需要創建主題和觀察者了，因為Java中直接就提供了這兩個接口（確切的說是一個接口和一個類）。下面我們將上述的代碼，用Java中內置的觀察者模式來實現。

下面為具體的代碼：

我們看使用Java內置的觀察者和我們自定義的觀察者模式的效果是一樣的，但代碼卻大大的減少了，因為大部分的代碼都已經被內置的實現了。雖然這樣有很大的好處，但有一點不太方便，可能你們也發現了，也就是Observable是一個類，而不是一個接口，如果我們要想使用Java內置的觀察者模式，如果主題已經繼承了其他的父類，那我們就不能使用Java內置的觀察者模式了，因為在Java中并不支持多重繼承，這也就是Java內置的觀察者模式的弊端。

關于“java設計模式中觀察者模式怎么實現”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。