摘要：與類型庫相比，設計模式是一個更為普遍的概念。是在年，由建筑設計大師亞力山大建筑的永恒之道描述模式是一條由三部分組成的通過規則它表示了一個特定環境一類問題和一個解決方案之間的關系。設計模式是在這方面開始探索的一塊里程碑。

    為了方便地編寫java程序，我們會使用類庫，但設計模式不是類庫。

    與類型庫相比，設計模式是一個更為普遍的概念。類庫是由程序組合而成的組件，而設計模式則是來表現內

部組件是如何被組裝的，以及每一個組件是如何通過相互關聯構成一個龐大的系統。

                                                 -- 引用自《圖解設計模式》 結城浩 著

     最早提出"設計模式"概念。是在1970年，由建筑設計大師亞力山大Alexander<<建筑的永恒之道>>描述：
     
模式是一條由三部分組成的通過規則：它表示了一個特定環境、一類問題和一個解決方案之間的關系。每一個 模

式描述了一個不斷重復發生的問題，以及該問題解決方案的核心設計。在他的另一本書<<建筑者模式語言>>中提

到了現在已經定義的253種模式。

     盡管Alexander的著作是針對建筑領域的，但他的觀點適用于所以的工程設計領域，其中也包含軟件設 計

領域。"軟件設計模式"，這個術語是由1990年代由Erich Gamma等2 從建筑設計領域引入到計算機科學中來的。

目前主要有23種。當然，設計模式不僅僅中有23種。

     這里引用費馬理論：光線傳播的路徑是需時最少的路徑。而設計模式，在軟件開發中，可以讓我們少走很多

彎路，他是一套被反復使用的、多數人知曉的、經過分類編目的、代碼設計經驗的總結。

     軟件需求變幻無窮，計劃沒有變化快，但是我們還是要尋找出不變的東西，并將它和變化的東西分離開來，

這需要非常的智慧和經驗。設計模式是在這方面開始探索的一塊里程碑。    

     為了代碼可重用性、讓代碼更容易被他人理解、保證代碼可靠性。 設計模式使代碼編寫真正工程化；設計模

式是軟件工程的基石脈絡，如同大廈的結構一樣

     "一個類僅有一個職責"或者"引起類變化的只有一個原因",這就是單一職責原理

     就一個類而言，應該僅有僅有一個引起它變化的原因。簡單來說，這個類應該是一組相關性很高的函數，數
     
據的封裝。單一職責的劃分界限并不是總那么清晰，很多的時候都是需要靠個人經驗去界定。

     類只因一個類的原因去變化，面對對象編程時，試圖把一個事物對象成一個類，事務這個類具備的功能都是

這個類的操作。比如。1塊錢，它既可以買辣條，它也可以去買小浣熊便利面等。而在單一職責原理下，錢的功能就

是引起這個類變化的兩個原因，就應該寫成兩個類。

     如果混在一起寫，在修改的一個職責的時候，就會影響到另一個職責。當另一個類只使用其中一個職責的時
     
候，另一不會用到的職責會消耗更多的資源。

     "對于擴展是開放的，對于修改是關閉的",這就是開閉原則原理

     開閉原則明確的告訴我們：軟件實現應該對擴展開放，對修改關閉，其含義就是說：一個軟件應該通過

擴展來實現變化，而不是修改已有的代碼來實現變化的。
     
     打個比方：1塊錢，它既可以買2包辣條。但是由于物價上漲，現在只能買一塊。那么根據開閉原則，你

并不能在原來的代碼中去修改已有的代碼。換句話說，現在是對已有代碼的一種修改，但是，如果他現在還能

界定他還能買一根香腸。那么現在是對已經代碼的一種擴展。

     如果直接修改代碼，那么如果他要換回去怎么辦，又去改回來？所以，開閉原則可以提高程序的復用性、

維護性。

    "任何基類可以出現的地方，子類一定可以出現。 里氏代換原則是繼承復用的基石，只有當衍生類可以

替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新

的行為"。

     所有引用基類的地方必須透明的使用其子類的對象。

 上兩點就是里氏代換原則。  

打個比方：如果對每一個類型為"駝鳥"的對象a,都有類型為"鳥"的對象b,使得以"鳥"定義的所有程序C在
    
所有的對象a都代換為b,程序行為沒有發生變化，那么類型"駝鳥"是"鳥"的子類型。只要有"鳥"能出現的地方

"駝鳥"也可以出現，而且替換為子類不會產生任何的Error或Exception，但是，"駝鳥"出現的地 方，"鳥"未

必就能適應。

高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象

抽象不依賴實現

實現依賴抽象

   以上三點就是依賴倒轉的原則，什么意思呢？指的是模塊與模塊之間的信賴是通過抽象發生的，實現類之間
   
相互獨立，之間不發生直接的信賴關系，其依賴關系是通過接口或者抽象類產生的，接口或者抽象類不依賴實現，

實現依賴接口或者抽象類。更加精簡的意思叫做“面向接口編程” 。

   采用依賴倒置原則可以減少類間的耦合性，提高系統的穩定性，減少并行開發引起的風險，提高代碼的可讀性

和可維護性。

   這里打個比方：人，和一包笑笑牌辣條。創建一個人類A，里面有一個吃辣條的動作a1方法，再來一個笑笑

牌辣條類B，里面有一個打印辣條自己被吃的方法b1方法，再來一個終端，通過A.a1調用B.b1，這里我們可以發

現，這個人吃辣條這個場景，人類A和笑笑牌辣條類B之間是一個緊耦合的關系，假如我們這里還有一個只吃花生

的人，怎么辦?如果這里把這個動作抽象化，定義一個接口C，接口C中有一個吃的方法，然后創建一個花生類，

里面有一個自己被吃的打印方法c1。以后如果還有別的功能，那么實現接口。就可以了。同理，如果這里人分為

大人和小人，那么就可以定義一個抽象類（人），然后再定義一個兩個類大人和小孩，繼承這個類。這樣一來，

我們這個場景就可以減少類間的耦合性，提高系統穩定性，減少并行開發引起的風險，提高代碼的可讀性和可維

護性以為可擴展性。

客戶端不應該依賴它不需要的接口

一個類對另一個類的依賴應該建立在最小的接口上

   這里的意思是建立單一的接口，接口盡量細化，如果有不需要的接口，客戶端需要什么接口，就給什么接 

口，把不需要的接口剔除了。---     

    接口隔離原則與單一職現原則其實也沒有，主要是角度不一樣，單一職責原則要求類和接口只應該響應一

個變化，接口隔離原則要求接口的方法盡可能少，盡可能的去細化

    總之呢：接口要盡量小，接口要高內聚，接口設計是有限度的。一個接口只服務一地一個子模塊或者業務。

這個要劃分開了，不要糅合在一起。接口要不斷的精簡，使之更加完善。如果接口是壞的，改之。如果背鍋的

可能性大。就采用適配器去處理。盡量不要去背鍋，這個會很難受。

    這個也叫最少知識原則(Low knowledge Principle)。最早是在1987年由美國Northeastern 

University的Ian Holland提出。類與類之間的關系越好(緊密)，耦合度越高（大），當一個類發生改變時，

對另一個類的影響也越大。于是就提出了迪米特法則。通俗的來講，就是一個類對自己依賴的類知道的越少越

好。也就是說，對于被依賴的類來說，無論邏輯多么復雜，都盡量地的將邏輯封裝在類的內部，對外除了提供

的public方法，不對外泄漏任何信息。

    打個比方，有一個辣條類，老板叫員工去清算辣條的包數。這里我們創建一個辣條類A,創建一個員工類B,

里面有一個接收辣條列表參數功能為清算辣條數量的方法b1。然后我們一個老板類C，里面有一個功能為命令

員工清算辣條的方法c1。里面初始化了辣條的數量。我們通過調用這個命令來達到清算辣條的數量。這里是我

們經常做的，沒有不一樣，但是我們可以發現，這里老板居然去初始化辣條。這里就有違反了迪米特原則。它

破壞了老板類的健壯性。我們只需要在老板類中寫一個命令的方法就可以了，只調用員工清算的方法就可以了

，讓main方法（客戶端）去創建辣條。這樣就保證了類與類之間的健壯性。

    總之核心觀念就是類間解耦，弱耦合，只有弱耦合后，類的復用率才可以提高。其結果就是產生了大量的

中轉或跳轉類，導致系統復雜，為維護帶來了難度。所以，我們在實踐時要反復權衡，即要讓結構清晰，又做

到高內聚低耦合。   

  設計模式就是實現了這些原則，從而達到了代碼復用、增加可維護性的目的 

  設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了
  
  可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性             

幾種常見的設計模式

如果有侵權，馬上刪除