Java設計模式遵循的七大原則

  近年來，人們踴躍的提倡和使用設計模式，根本原因就是為了實現程式碼的複用性，增加程式碼的可維護性。設計模式的實現遵循了一些原則，從而達到程式碼的複用性和增加可維護性的目的，設計模式對理解物件導向的三大特徵有很好的啟發，不看設計模式，很難深層地體會到物件導向開發帶來的好處 。在剛開始學習中，很難做到將這些模式融匯貫通，所以這個需要我們在編碼前多思考，等想充分了，在開始實踐編碼。以下是設計模式應遵循的七大原則

1.開閉原則（Open Close Principle）

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

    開放-封閉原則的意思是說，你設計的時候，時刻要考慮，盡量讓這個類是足夠好，寫好了就不要去修改了，如果新需求來，我們增加一些類就完事了，原來的程式碼能不動則不動。這個原則有兩個特性，一個是說“對於擴展是開放的”，另一個是說“對於更改是封閉的”。面對需求，程式的改變是透過增加新程式碼進行的，而不是更改現有的程式碼。這就是「開放-封閉原則」的精神所在

    例如，剛開始需求只是寫加法程序，很快在client類中完成後，此時變化沒有發生，需求讓再添加一個減法功能，此時會發現增加功能需要修改原來這個類，這就違背了開放-封閉原則，於是你就應該考慮重構程序，增加一個抽象的運算類，透過一些面向對象的手段，如繼承、動態等來隔離具體加法、減法與client耦合，需求仍可滿足，還能應付變化。此時需求要加入乘除法功能，就不需要再去更改client及加減法類，而是增加乘法和除法子類即可。
絕對的修改關閉是不可能的，無論模組是多麼的'封閉'，都會存在一些無法對之封閉的變化，既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測最有可能發生的變化種類，然後再建構抽象來隔離那些變化。在我們最初編寫程式碼時，假設變化不會發生，當變化發生時，我們會創建抽象來隔離以後發生同類的變化。

     我們希望的是在開發工作展開不久就知道可能發生的變化，查明可能發生的變化所等待的時候越長，要創建正確的抽象就越困難。開放-封閉原則是物件導向設計的核心所在，遵循這個原則可以帶來物件導向技術所宣稱的巨大好處，也就是可維護、可擴展、可重複使用、彈性好。開發人員應該只對程式中呈現出現頻繁變化的那些部分做出抽象，然而對於應用程式中的每個部分都刻意地進行抽象同樣不是一個好主意，拒絕不成熟的抽象和抽象本身一樣重要。開放-封閉原則，可以保證先前程式碼的正確性，因為沒有修改先前程式碼，所以可以保證開發人員專注於將設計放在新擴充的程式碼上。

簡單的用一句經典的話來說：過去的事已成歷史，是不可修改的，因為時光不可倒流，但現在或明天計劃做什麼，是可以自己決定(即擴展)的。

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

定義1：如果每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序為所有的所有程序在  物件 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. 提高內聚，減少對外互動。使介面用最少的方法去完成最多的事情。

   運用介面隔離原則，一定要適度，介面設計的過大或過小都不好。設計介面的時候，只有多花點時間去思考、規劃，才能準確地實踐這項原則。

4.組合/聚合復用原則

就是說要盡量的使用合成和聚合，而不是繼承關係達到復用的目的
該原則就是在一個新的對象裡面使用一些已有的對象，使之成為新物件的一部分：新的物件透過向這些物件的委派達到重複使用已有功能的目的。
      其實這裡最終要的地方就是區分「has-a」和「is-a」的差別。相對於合成和聚合，
繼承的缺點在於：父類別的方法全部暴露給子類別。父類別如果發生變化，子類別也得發生變化。聚合的複用的時候就對另外的類別依賴的比較的少。 。
合成/聚合復用
① 優點：
新物件存取成分物件的唯一方法是透過成分物件的介面；
 這種重複使用是黑箱重複使用，因為成分物件的內部細節是新物件所看不見的；

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

繼承復用
① 優點：
  新的實作較為容易，因為基底類別的功能大多可以透過繼承關係自動進入衍生類別；
  修改或擴充繼承而來的實作較為容易。
② 缺點：
  繼承復用破壞包裝，因為繼承將基類的實現細節暴露給派生類，這種復用也稱為白箱復用；
  如果基類的實現改變，那麼派生類的實現也不得不改變；
  從基底類別繼承而來的實作是靜態的，不可能在運作時改變，不夠彈性。
6.迪米特法則（Law Of Demeter）

    迪米特法則其根本思想，是強調了類之間的松耦合，類之間的耦合越弱,越有利於復用，一個處在弱耦合的類別被修改，不會對有關係的類別造成影響，也就是說，資訊的隱藏促進了軟體的重複使用。

    自從我們接觸程式設計開始，就知道了軟體程式設計的總的原則：低耦合，高內聚。無論是面向過程編程還是物件導向編程，只有使各個模組之間的耦合盡量的低，才能提高程式碼的複用率。低耦合的優點不言而喻，但是怎麼樣程式設計才能做到低耦合呢？那正是迪米特法則要去完成的。

    迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類別來說，無論邏輯多麼複雜，都盡量地的將邏輯封裝在類別的內部，對外除了提供的public方法，不對外洩漏任何資訊。迪米特法則還有一個更簡單的定義：只與直接的朋友溝通。首先來解釋什麼是直接的朋友：每個物件都會與其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變數、方法參數、方法回傳值中的類別為直接的朋友，而出現在局部變數中的類別則不是直接的朋友。也就是說，陌生的類別最好不要作為局部變數的形式出現在類別的內部。

一句話總結就是：一個物件應該對其他物件保持最少的了解。

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

定義：不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責，應該只有一個引起它變化的原因

    說到單一職責原則，很多人都會不屑一顧。因為它太簡單了。稍有經驗的程式設計師即使從來沒有讀過設計模式、從來沒有聽說過單一職責原則，在設計軟體時也會自覺的遵守這一重要原則，因為這是常識。在軟體編程中，誰也不希望因為修改了一個功能而導致其他的功能發生故障。而避免出現這一問題的方法便是遵循單一職責原則。雖然單一職責原則如此簡單，並且被認為是常識，但是即便是經驗豐富的程式設計師寫出的程序，也會有違背這項原則的程式碼存在。為什麼會出現這種現象呢？因為有職責擴散。所謂職責擴散，就是因為某種原因，職責P被分化為粒度更細的職責P1和P2。

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

1.可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；

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

3.變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。

需要說明的一點是單一職責原則不只是物件導向程式設計思想所特有的，只要是模組化的程式設計，都需要遵循這項重要原則。