Java中設計模式有哪些原則

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

一.單一職責原則

　　單一職責原則是最簡單的面向對象設計原則，它用于控制類的粒度大小。單一職責原則定義如下：

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

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

      單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責并將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。

      下面通過一個簡單實例來進一步分析單一職責原則：

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

 

圖1  初始設計方案結構圖

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

現使用單一職責原則對其進行重構。

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

      (1) DBUtil：負責連接數據庫，包含數據庫連接方法getConnection()；

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

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

      使用單一職責原則重構后的結構如圖2所示：
 

圖1原始結構圖

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

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

圖2  重構后的結構圖

四、依賴倒置原則

定義：高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。即針對接口編程，不要針對實現編程

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

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

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

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

      通過使用接口隔離原則，本實例重構后的結構如圖2所示：

圖2 重構后的結構圖

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

  迪米特法則其根本思想，是強調了類之間的松耦合，類之間的耦合越弱,越有利于復用，一個處在弱耦合的類被修改，不會對有關系的類造成影響，也就是說，信息的隱藏促進了軟件的復用。

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

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