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

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長期合作伙伴，公司提供的服務(wù)項(xiàng)目有：國際域名空間、網(wǎng)站空間、營銷軟件、網(wǎng)站建設(shè)、肇源網(wǎng)站維護(hù)、網(wǎng)站推廣。

具體的代碼如下。

我們看輸出實(shí)現(xiàn)了我們想要的結(jié)果，也就是當(dāng)訂單發(fā)生更新時(shí)，其他3個(gè)系統(tǒng)都會(huì)收到信息。但我們?cè)谥暗奈恼轮刑岬竭^，我們?cè)谠O(shè)計(jì)系統(tǒng)時(shí)，不要針對(duì)實(shí)現(xiàn)編程，要針對(duì)接口編程，這樣程序比較方便擴(kuò)展。按照我們上述的代碼，如果我們要添加新的系統(tǒng)，例如卡卷系統(tǒng) ，那么這時(shí)我們就要修改曾經(jīng)已經(jīng)編寫好的代碼，也就是OrderSuccess接口，那這就違背了設(shè)計(jì)模式的基本原則了。顯然上述的代碼，雖然可以實(shí)現(xiàn)需求，但是卻不是最好的，因?yàn)椴环奖銛U(kuò)展。那么怎么辦？我們分析需求知道這顯然是一個(gè)一對(duì)多的關(guān)系，當(dāng)訂單更新時(shí)，其他和它相關(guān)的系統(tǒng)都需要接到通知然后更新，類似報(bào)紙訂閱是一樣的，只要報(bào)紙發(fā)生變化，那么訂閱該報(bào)紙的人都能知道。其實(shí)，這就是典型的觀察者模式。下面我們先看一下觀察者模式的定義。

觀察者模式：定義了對(duì)象之間的一對(duì)多依賴，這樣一來，當(dāng)一個(gè)對(duì)象改變狀態(tài)時(shí)，它的所有依賴者都會(huì)收到通知并自動(dòng)更新。

我們?cè)谡f的簡單點(diǎn)比如對(duì)一個(gè)有狀態(tài)的對(duì)象，我們稱之為主題對(duì)象，然后我們有一堆和主題對(duì)象依賴的對(duì)象，我們叫它觀察者對(duì)象。這樣當(dāng)主題對(duì)象更新時(shí)，觀察者對(duì)象會(huì)自動(dòng)收到通知并更新。

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

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

這樣我們就將上述的代碼修改為真正的觀察者模式的代碼，這樣的好處就是非常方便我們的擴(kuò)展，我們?cè)谛绿砑有碌南到y(tǒng)時(shí)，而并不需要修改曾經(jīng)已經(jīng)開發(fā)好的代碼，也就是訂單中的已有的代碼，這樣就真正做到了可擴(kuò)展了。下面我們將新增一個(gè)卡卷系統(tǒng)，來證明我們上述所說的可擴(kuò)展性。

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

到這里，我們已經(jīng)將觀察者模式都介紹完了，本應(yīng)該到這里就結(jié)束了，但這個(gè)觀察者模式有點(diǎn)特別，Java為了我們更方便的使用觀察者模式，所以在Java中直接內(nèi)置的支持觀察者模式，也就是我們自己并不需要?jiǎng)?chuàng)建主題和觀察者了，因?yàn)镴ava中直接就提供了這兩個(gè)接口（確切的說是一個(gè)接口和一個(gè)類）。下面我們將上述的代碼，用Java中內(nèi)置的觀察者模式來實(shí)現(xiàn)。

下面為具體的代碼：

我們看使用Java內(nèi)置的觀察者和我們自定義的觀察者模式的效果是一樣的，但代碼卻大大的減少了，因?yàn)榇蟛糠值拇a都已經(jīng)被內(nèi)置的實(shí)現(xiàn)了。雖然這樣有很大的好處，但有一點(diǎn)不太方便，可能你們也發(fā)現(xiàn)了，也就是Observable是一個(gè)類，而不是一個(gè)接口，如果我們要想使用Java內(nèi)置的觀察者模式，如果主題已經(jīng)繼承了其他的父類，那我們就不能使用Java內(nèi)置的觀察者模式了，因?yàn)樵贘ava中并不支持多重繼承，這也就是Java內(nèi)置的觀察者模式的弊端。

關(guān)于“java設(shè)計(jì)模式中觀察者模式怎么實(shí)現(xiàn)”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。