《Java設計模式》七大原則

    最近幾年來，人們踊躍的提倡和使用設計模式，其根本緣由就是爲了實現代碼的複用性，增長代碼的可維護性。設計模式的實現遵循了一些原則，從而達到代碼的複用性及增長可維護性的目的，設計模式對理解面向對象的三大特徵有很好的啓發，不看設計模式，很難深層地體會到面向對象開發帶來的好處 。在剛開始學習中，很難作到將這些模式融匯貫通，因此這個須要咱們在編碼前多思考，等想充分了，在開始實踐編碼。下面是設計模式應當遵循的七大原則

1.開閉原則（Open Close Principle）

定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。

    開 放-封閉原則的意思就是說，你設計的時候，時刻要考慮，儘可能讓這個類是足夠好，寫好了就不要去修改了，若是新需求來，咱們增長一些類就完事了，原來的代碼 能不動則不動。這個原則有兩個特性，一個是說「對於擴展是開放的」，另外一個是說「對於更改是封閉的」。面對需求，對程序的改動是經過增長新代碼進行的，而 不是更改現有的代碼。這就是「開放-封閉原則」的精神所在

    比 如，剛開始需求只是寫加法程序，很快在client類中完成後，此時變化沒有發生，需求讓再添加一個減法功能，此時會發現增長功能須要修改原來這個類，這 就違背了開放-封閉原則，因而你就應該考慮重構程序，增長一個抽象的運算類，經過一些面向對象的手段，如繼承、動態等來隔離具體加法、減法與client 耦合，需求依然能夠知足，還能應對變化。此時需求要添加乘除法功能，就不須要再去更改client及加減法類，而是增長乘法和除法子類便可。
絕 對的修改關閉是不可能的，不管模塊是多麼的‘封閉‘，都會存在一些沒法對之封閉的變化，既然不可能徹底封閉，設計人員必須對於他設計的模塊應該對哪一種變化 封閉作出選擇。他必須先猜想出最有可能發生的變化種類，而後構造抽象來隔離那些變化。在咱們最初編寫代碼時，假設變化不會發生，當變化發生時，咱們就建立 抽象來隔離之後發生同類的變化。

     我 們但願的是在開發工做展開不久就知道可能發生的變化，查明可能發生的變化所等待的時候越長，要建立正確的抽象就越困難。開放-封閉原則是面向對象設計的核 心所在，遵循這個原則能夠帶來面向對象技術所聲稱的巨大好處，也就是可維護、可擴展、可複用、靈活性好。開發人員應該僅對程序中呈現出現頻繁變化的那些部 分作出抽象，然而對於應用程序中的每一個部分都刻意地進行抽象一樣不是一個好主意，拒毫不成熟的抽象和抽象自己同樣重要。開放-封閉原則，能夠保證之前代碼 的正確性，由於沒有修改之前代碼，因此能夠保證開發人員專一於將設計放在新擴展的代碼上。

簡單的用一句經典的話來講：過去的事已成歷史，是不可修改的，由於時光不可倒流，但如今或明天計劃作什麼，是能夠本身決定(即擴展)的。

2.里氏代換原則（Liskov Substitution Principle）

定義1：若是對每個類型爲 T1的對象 o1，都有類型爲 T2 的對象o2，使得以 T1定義的全部程序 P 在全部的對象 o1 都代換成 o2 時，程序 P 的行爲沒有發生變化，那麼類型 T2 是類型 T1 的子類型。

定義2：子類型必須可以替換掉它們的父類型。
    描述：一個軟件實體若是使用的是一個父類的話，那麼必定適用於其子類，並且它察覺不出父類對象和子類對象的區別，也就是說，在軟件裏面，把父類都替換成它的子類，程序的行爲沒有變化
例子：在生物學分類上，企鵝是一種鳥，但在編程世界裏，企鵝卻不能繼承鳥。在面向對象設計時，子類擁有父類全部非private的行爲和屬性，鳥會飛，但企鵝不會飛，因此企鵝不能繼承鳥類。

    只 有當子類能夠替換掉父類，軟件單位的功能不受影響時，父類才能真正被複用，而子類也可以在父類的基礎上增長新的行爲，正是有里氏代換原則，使得繼承複用成 爲了可能。正是因爲子類型的可替換性才使得使用父類類型的模塊在無需修改的狀況下就能夠擴展，否則還談什麼擴展開放，修改關閉呢

里氏替換原則通俗的來說就是：子類能夠擴展父類的功能，但不能改變父類原有的功能。它包含如下4層含義：

1.子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。

2.子類中能夠增長本身特有的方法。

3.當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。

4.當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

    看上去很難以想象，由於咱們會發如今本身編程中經常會違反里氏替換原則，程序照樣跑的好好的。因此你們都會產生這樣的疑問，假如我非要不遵循里氏替換原則會有什麼後果？

後果就是：你寫的代碼出問題的概率將會大大增長。

3.依賴倒轉原則（Dependence Inversion Principle）

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

    依 賴倒轉其實就是誰也不要依靠誰，除了約定的接口，你們均可以靈活自如。依賴倒轉能夠說是面向對象設計的標誌，用哪一種語言來編寫程序不重要，若是編寫時考慮 的都是如何針對抽象編程而不是針對細節編程，即程序中全部的依賴關係都是終止於抽象類或者接口，那就是面向對象的設計，反之那就是過程化的設計了。若是設 計的各個部件或類相互依賴，這樣就是耦合度高，難以維護和擴展，這也就體現不出面向對象的好處了。

    依 賴倒轉原則，比如一個團隊，有需求組，開發組，測試組，開發組和測試組都是面對一樣的需求後，作本身相應的工做，而不該該是測試組按照開發組理解的需求去 作測試用例，也就是說開發組和測試組都是直接面向需求組工做，你們的目的是同樣的，保證產品按時上線，需求是不依賴於開發和測試的。

    依 賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。在 java中，抽象指的是接口或者抽象類，細節就是具體的實現類，使用接口或者抽象類的目的是制定好規範和契約，而不去涉及任何具體的操做，把展示細節的任 務交給他們的實現類去完成。

    依賴倒置原則的中心思想是面向接口編程，傳遞依賴關係有三種方式，以上的說的是是接口傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞，相信用過Spring框架的，對依賴的傳遞方式必定不會陌生。

在實際編程中，咱們通常須要作到以下3點：

低層模塊儘可能都要有抽象類或接口，或者二者都有。

變量的聲明類型儘可能是抽象類或接口。

使用繼承時遵循里氏替換原則。

    總之，依賴倒置原則就是要咱們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。

4.接口隔離原則（Interface Segregation Principle）

   接 口隔離原則的含義是：創建單一接口，不要創建龐大臃腫的接口，儘可能細化接口，接口中的方法儘可能少。也就是說，咱們要爲各個類創建專用的接口，而不要試圖去 創建一個很龐大的接口供全部依賴它的類去調用。在程序設計中，依賴幾個專用的接口要比依賴一個綜合的接口更靈活。接口是設計時對外部設定的「契約」，經過 分散定義多個接口，能夠預防外來變動的擴散，提升系統的靈活性和可維護性。

   說 到這裏，不少人會覺的接口隔離原則跟單一職責原則很類似，其實否則。其一，單一職責原則原注重的是職責；而接口隔離原則注重對接口依賴的隔離。其二，單一 職責原則主要是約束類，其次纔是接口和方法，它針對的是程序中的實現和細節；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序總體框架的構建。

採用接口隔離原則對接口進行約束時，要注意如下幾點：

1. 接口儘可能小，可是要有限度。對接口進行細化能夠提升程序設計靈活性是不掙的事實，可是若是太小，則會形成接口數量過多，使設計複雜化。因此必定要適度。

2. 爲依賴接口的類定製服務，只暴露給調用的類它須要的方法，它不須要的方法則隱藏起來。只有專一地爲一個模塊提供定製服務，才能創建最小的依賴關係。

3. 提升內聚，減小對外交互。使接口用最少的方法去完成最多的事情。

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

5.組合/聚合複用原則

就是說要儘可能的使用合成和聚合，而不是繼承關係達到複用的目的
該原則就是在一個新的對象裏面使用一些已有的對象，使之成爲新對象的一部分：新的對象經過向這些對象的委派達到複用已有功能的目的。
      其實這裏最終要的地方就是區分「has-a」和「is-a」的區別。相對於合成和聚合，
繼承的缺點在於：父類的方法所有暴露給子類。父類若是發生變化，子類也得發生變化。聚合的複用的時候就對另外的類依賴的比較的少。。
合成/聚合複用
① 優勢：
新對象存取成分對象的惟一方法是經過成分對象的接口；
 這種複用是黑箱複用，由於成分對象的內部細節是新對象所看不見的；

 這種複用支持包裝；
這種複用所需的依賴較少；
每個新的類能夠將焦點集中在一個任務上；
 這種複用能夠在運行時動態進行，新對象可使用合成/聚合關係將新的責任委派到合適的對象。
② 缺點：
經過這種方式複用建造的系統會有較多的對象須要管理。

繼承複用
① 優勢：
  新的實現較爲容易，由於基類的大部分功能能夠經過繼承關係自動進入派生類；
  修改或擴展繼承而來的實現較爲容易。
② 缺點：
  繼承複用破壞包裝，由於繼承將基類的實現細節暴露給派生類，這種複用也稱爲白箱複用；
  若是基類的實現發生改變，那麼派生類的實現也不得不發生改變；
  從基類繼承而來的實現是靜態的，不可能在運行時發生改變，不夠靈活。

6.迪米特法則（Law Of Demeter）

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

    自從咱們接觸編程開始，就知道了軟件編程的總的原則：低耦合，高內聚。不管是面向過程編程仍是面向對象編程，只有使各個模塊之間的耦合儘可能的低，才能提升代碼的複用率。低耦合的優勢不言而喻，可是怎麼樣編程才能作到低耦合呢？那正是迪米特法則要去完成的。

    迪米特法則又叫最少知道原則，最先是在1987年由美國Northeastern University的Ian Holland 提出。通俗的來說，就是一個類對本身依賴的類知道的越少越好。也就是說，對於被依賴的類來講，不管邏輯多麼複雜，都儘可能地的將邏輯封裝在類的內部，對外除 了提供的public方法，不對外泄漏任何信息。迪米特法則還有一個更簡單的定義：只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每一個對象都會與 其餘對象有耦合關係，只要兩個對象之間有耦合關係，咱們就說這兩個對象之間是朋友關係。耦合的方式不少，依賴、關聯、組合、聚合等。其中，咱們稱出現成員 變量、方法參數、方法返回值中的類爲直接的朋友，而出如今局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要做爲局部變量的形式出如今類的內 部。

一句話總結就是：一個對象應該對其餘對象保持最少的瞭解。

7.單一職責原則（Single Responsibility Principle）

定義：不要存在多於一個致使類變動的緣由。通俗的說，即一個類只負責一項職責，應該僅有一個引發它變化的緣由

    說 到單一職責原則，不少人都會不屑一顧。由於它太簡單了。稍有經驗的程序員即便歷來沒有讀過設計模式、歷來沒有據說過單一職責原則，在設計軟件時也會自覺的 遵照這一重要原則，由於這是常識。在軟件編程中，誰也不但願由於修改了一個功能致使其餘的功能發生故障。而避免出現這一問題的方法即是遵循單一職責原則。 雖然單一職責原則如此簡單，而且被認爲是常識，可是即使是經驗豐富的程序員寫出的程序，也會有違背這一原則的代碼存在。爲何會出現這種現象呢？由於有職 責擴散。所謂職責擴散，就是由於某種緣由，職責P被分化爲粒度更細的職責P1和P2。

遵循單一職責原的優勢有：

1.能夠下降類的複雜度，一個類只負責一項職責，其邏輯確定要比負責多項職責簡單的多；

2.提升類的可讀性，提升系統的可維護性；

3.變動引發的風險下降，變動是必然的，若是單一職責原則遵照的好，當修改一個功能時，能夠顯著下降對其餘功能的影響。

須要說明的一點是單一職責原則不僅是面向對象編程思想所特有的，只要是模塊化的程序設計，都須要遵循這一重要原則。