Java中設(shè)計模式有哪些原則

這篇文章給大家介紹Java中設(shè)計模式有哪些原則，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

一.單一職責(zé)原則

　　單一職責(zé)原則是最簡單的面向?qū)ο笤O(shè)計原則，它用于控制類的粒度大小。單一職責(zé)原則定義如下：

單一職責(zé)原則(Single Responsibility Principle, SRP)：一個類只負(fù)責(zé)一個功能領(lǐng)域中的相應(yīng)職責(zé)，或者可以定義為：就一個類而言，應(yīng)該只有一個引起它變化的原因。

      單一職責(zé)原則告訴我們：一個類不能太“累”！在軟件系統(tǒng)中，一個類（大到模塊，小到方法）承擔(dān)的職責(zé)越多，它被復(fù)用的可能性就越小，而且一個類承擔(dān)的職責(zé)過多，就相當(dāng)于將這些職責(zé)耦合在一起，當(dāng)其中一個職責(zé)變化時，可能會影響其他職責(zé)的運作，因此要將這些職責(zé)進(jìn)行分離，將不同的職責(zé)封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責(zé)總是同時發(fā)生改變則可將它們封裝在同一類中。

      單一職責(zé)原則是實現(xiàn)高內(nèi)聚、低耦合的指導(dǎo)方針，它是最簡單但又最難運用的原則，需要設(shè)計人員發(fā)現(xiàn)類的不同職責(zé)并將其分離，而發(fā)現(xiàn)類的多重職責(zé)需要設(shè)計人員具有較強(qiáng)的分析設(shè)計能力和相關(guān)實踐經(jīng)驗。

      下面通過一個簡單實例來進(jìn)一步分析單一職責(zé)原則：

Sunny軟件公司開發(fā)人員針對某CRM（Customer Relationship  Management，客戶關(guān)系管理）系統(tǒng)中客戶信息圖形統(tǒng)計模塊提出了如圖1所示初始設(shè)計方案：

 

圖1  初始設(shè)計方案結(jié)構(gòu)圖

在圖1中，CustomerDataChart類中的方法說明如下：getConnection()方法用于連接數(shù)據(jù)庫，findCustomers()用于查詢所有的客戶信息，createChart()用于創(chuàng)建圖表，displayChart()用于顯示圖表。

現(xiàn)使用單一職責(zé)原則對其進(jìn)行重構(gòu)。

      在圖1中，CustomerDataChart類承擔(dān)了太多的職責(zé)，既包含與數(shù)據(jù)庫相關(guān)的方法，又包含與圖表生成和顯示相關(guān)的方法。如果在其他類中也需要連接數(shù)據(jù)庫或者使用findCustomers()方法查詢客戶信息，則難以實現(xiàn)代碼的重用。無論是修改數(shù)據(jù)庫連接方式還是修改圖表顯示方式都需要修改該類，它不止一個引起它變化的原因，違背了單一職責(zé)原則。因此需要對該類進(jìn)行拆分，使其滿足單一職責(zé)原則，類CustomerDataChart可拆分為如下三個類：

      (1) DBUtil：負(fù)責(zé)連接數(shù)據(jù)庫，包含數(shù)據(jù)庫連接方法getConnection()；

      (2) CustomerDAO：負(fù)責(zé)操作數(shù)據(jù)庫中的Customer表，包含對Customer表的增刪改查等方法，如findCustomers()；

      (3) CustomerDataChart：負(fù)責(zé)圖表的生成和顯示，包含方法createChart()和displayChart()。

      使用單一職責(zé)原則重構(gòu)后的結(jié)構(gòu)如圖2所示：
 

圖1原始結(jié)構(gòu)圖

      在對系統(tǒng)進(jìn)行進(jìn)一步分析后發(fā)現(xiàn)，無論是普通客戶還是VIP客戶，發(fā)送郵件的過程都是相同的，也就是說兩個send()方法中的代碼重復(fù)，而且在本系統(tǒng)中還將增加新類型的客戶。為了讓系統(tǒng)具有更好的擴(kuò)展性，同時減少代碼重復(fù)，使用里氏代換原則對其進(jìn)行重構(gòu)。

      在本實例中，可以考慮增加一個新的抽象客戶類Customer，而將CommonCustomer和VIPCustomer類作為其子類，郵件發(fā)送類EmailSender類針對抽象客戶類Customer編程，根據(jù)里氏代換原則，能夠接受基類對象的地方必然能夠接受子類對象，因此將EmailSender中的send()方法的參數(shù)類型改為Customer，如果需要增加新類型的客戶，只需將其作為Customer類的子類即可。重構(gòu)后的結(jié)構(gòu)如圖2所示：

圖2  重構(gòu)后的結(jié)構(gòu)圖

四、依賴倒置原則

定義：高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴抽象。即針對接口編程，不要針對實現(xiàn)編程

    依賴倒轉(zhuǎn)其實就是誰也不要依靠誰，除了約定的接口，大家都可以靈活自如。依賴倒轉(zhuǎn)可以說是面向?qū)ο笤O(shè)計的標(biāo)志，用哪種語言來編寫程序不重要，如果編寫時考慮的都是如何針對抽象編程而不是針對細(xì)節(jié)編程，即程序中所有的依賴關(guān)系都是終止于抽象類或者接口，那就是面向?qū)ο蟮脑O(shè)計，反之那就是過程化的設(shè)計了。如果設(shè)計的各個部件或類相互依賴，這樣就是耦合度高，難以維護(hù)和擴(kuò)展，這也就體現(xiàn)不出面向?qū)ο蟮暮锰幜恕?br/>     依賴倒轉(zhuǎn)原則，好比一個團(tuán)隊，有需求組，開發(fā)組，測試組，開發(fā)組和測試組都是面對同樣的需求后，做自己相應(yīng)的工作，而不應(yīng)該是測試組按照開發(fā)組理解的需求去做測試用例，也就是說開發(fā)組和測試組都是直接面向需求組工作，大家的目的是一樣的，保證產(chǎn)品按時上線，需求是不依賴于開發(fā)和測試的。
    依賴倒置原則基于這樣一個事實：相對于細(xì)節(jié)的多變性，抽象的東西要穩(wěn)定的多。以抽象為基礎(chǔ)搭建起來的架構(gòu)比以細(xì)節(jié)為基礎(chǔ)搭建起來的架構(gòu)要穩(wěn)定的多。在java中，抽象指的是接口或者抽象類，細(xì)節(jié)就是具體的實現(xiàn)類，使用接口或者抽象類的目的是制定好規(guī)范和契約，而不去涉及任何具體的操作，把展現(xiàn)細(xì)節(jié)的任務(wù)交給他們的實現(xiàn)類去完成。
    依賴倒置原則的中心思想是面向接口編程，傳遞依賴關(guān)系有三種方式，以上的說的是是接口傳遞，另外還有兩種傳遞方式：構(gòu)造方法傳遞和setter方法傳遞，相信用過Spring框架的，對依賴的傳遞方式一定不會陌生。
在實際編程中，我們一般需要做到如下3點：
低層模塊盡量都要有抽象類或接口，或者兩者都有。
變量的聲明類型盡量是抽象類或接口。
使用繼承時遵循里氏替換原則。
    總之，依賴倒置原則就是要我們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。

五、接口隔離原則（Interface Segregation Principle）
   接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口，盡量細(xì)化接口，接口中的方法盡量少。也就是說，我們要為各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調(diào)用。在程序設(shè)計中，依賴幾個專用的接口要比依賴一個綜合的接口更靈活。接口是設(shè)計時對外部設(shè)定的“契約”，通過分散定義多個接口，可以預(yù)防外來變更的擴(kuò)散，提高系統(tǒng)的靈活性和可維護(hù)性。
   說到這里，很多人會覺的接口隔離原則跟單一職責(zé)原則很相似，其實不然。其一，單一職責(zé)原則原注重的是職責(zé)；而接口隔離原則注重對接口依賴的隔離。其二，單一職責(zé)原則主要是約束類，其次才是接口和方法，它針對的是程序中的實現(xiàn)和細(xì)節(jié)；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序整體框架的構(gòu)建。
采用接口隔離原則對接口進(jìn)行約束時，要注意以下幾點：
1. 接口盡量小，但是要有限度。對接口進(jìn)行細(xì)化可以提高程序設(shè)計靈活性是不掙的事實，但是如果過小，則會造成接口數(shù)量過多，使設(shè)計復(fù)雜化。所以一定要適度。
2. 為依賴接口的類定制服務(wù)，只暴露給調(diào)用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定制服務(wù)，才能建立最小的依賴關(guān)系。
3. 提高內(nèi)聚，減少對外交互。使接口用最少的方法去完成最多的事情。

   運用接口隔離原則，一定要適度，接口設(shè)計的過大或過小都不好。設(shè)計接口的時候，只有多花些時間去思考和籌劃，才能準(zhǔn)確地實踐這一原則。

      在圖1中，由于在接口CustomerDataDisplay中定義了太多方法，即該接口承擔(dān)了太多職責(zé)，一方面導(dǎo)致該接口的實現(xiàn)類很龐大，在不同的實現(xiàn)類中都不得不實現(xiàn)接口中定義的所有方法，靈活性較差，如果出現(xiàn)大量的空方法，將導(dǎo)致系統(tǒng)中產(chǎn)生大量的無用代碼，影響代碼質(zhì)量；另一方面由于客戶端針對大接口編程，將在一定程序上破壞程序的封裝性，客戶端看到了不應(yīng)該看到的方法，沒有為客戶端定制接口。因此需要將該接口按照接口隔離原則和單一職責(zé)原則進(jìn)行重構(gòu)，將其中的一些方法封裝在不同的小接口中，確保每一個接口使用起來都較為方便，并都承擔(dān)某一單一角色，每個接口中只包含一個客戶端（如模塊或類）所需的方法即可。

      通過使用接口隔離原則，本實例重構(gòu)后的結(jié)構(gòu)如圖2所示：

圖2 重構(gòu)后的結(jié)構(gòu)圖

六、迪米特法則（Law Of Demeter）

  迪米特法則其根本思想，是強(qiáng)調(diào)了類之間的松耦合，類之間的耦合越弱,越有利于復(fù)用，一個處在弱耦合的類被修改，不會對有關(guān)系的類造成影響，也就是說，信息的隱藏促進(jìn)了軟件的復(fù)用。

  迪米特法則要求我們在設(shè)計系統(tǒng)時，應(yīng)該盡量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那么這兩個對象就不應(yīng)當(dāng)發(fā)生任何直接的相互作用，如果其中的一個對象需要調(diào)用另一個對象的某一個方法的話，可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用。簡言之，就是通過引入一個合理的第三者來降低現(xiàn)有對象之間的耦合度。
   在將迪米特法則運用到系統(tǒng)設(shè)計中時，要注意下面的幾點：在類的劃分上，應(yīng)當(dāng)盡量創(chuàng)建松耦合的類，類之間的耦合度越低，就越有利于復(fù)用，一個處在松耦合中的類一旦被修改，不會對關(guān)聯(lián)的類造成太大波及；在類的結(jié)構(gòu)設(shè)計上，每一個類都應(yīng)當(dāng)盡量降低其成員變量和成員函數(shù)的訪問權(quán)限；在類的設(shè)計上，只要有可能，一個類型應(yīng)當(dāng)設(shè)計成不變類；在對其他類的引用上，一個對象對其他對象的引用應(yīng)當(dāng)降到最低。
   下面通過一個簡單實例來加深對迪米特法則的理解：

關(guān)于Java中設(shè)計模式有哪些原則就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。