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

    為了方便地編寫java程序，我們會(huì)使用類庫(kù)，但設(shè)計(jì)模式不是類庫(kù)。

    與類型庫(kù)相比，設(shè)計(jì)模式是一個(gè)更為普遍的概念。類庫(kù)是由程序組合而成的組件，而設(shè)計(jì)模式則是來表現(xiàn)內(nèi)

部組件是如何被組裝的，以及每一個(gè)組件是如何通過相互關(guān)聯(lián)構(gòu)成一個(gè)龐大的系統(tǒng)。

                                                 -- 引用自《圖解設(shè)計(jì)模式》 結(jié)城浩 著

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

式描述了一個(gè)不斷重復(fù)發(fā)生的問題，以及該問題解決方案的核心設(shè)計(jì)。在他的另一本書<<建筑者模式語(yǔ)言>>中提

到了現(xiàn)在已經(jīng)定義的253種模式。

     盡管Alexander的著作是針對(duì)建筑領(lǐng)域的，但他的觀點(diǎn)適用于所以的工程設(shè)計(jì)領(lǐng)域，其中也包含軟件設(shè) 計(jì)

領(lǐng)域。"軟件設(shè)計(jì)模式"，這個(gè)術(shù)語(yǔ)是由1990年代由Erich Gamma等2 從建筑設(shè)計(jì)領(lǐng)域引入到計(jì)算機(jī)科學(xué)中來的。

目前主要有23種。當(dāng)然，設(shè)計(jì)模式不僅僅中有23種。

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

彎路，他是一套被反復(fù)使用的、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。

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

這需要非常的智慧和經(jīng)驗(yàn)。設(shè)計(jì)模式是在這方面開始探索的一塊里程碑。    

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

式是軟件工程的基石脈絡(luò)，如同大廈的結(jié)構(gòu)一樣

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

     就一個(gè)類而言，應(yīng)該僅有僅有一個(gè)引起它變化的原因。簡(jiǎn)單來說，這個(gè)類應(yīng)該是一組相關(guān)性很高的函數(shù)，數(shù)
     
據(jù)的封裝。單一職責(zé)的劃分界限并不是總那么清晰，很多的時(shí)候都是需要靠個(gè)人經(jīng)驗(yàn)去界定。

     類只因一個(gè)類的原因去變化，面對(duì)對(duì)象編程時(shí)，試圖把一個(gè)事物對(duì)象成一個(gè)類，事務(wù)這個(gè)類具備的功能都是

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

是引起這個(gè)類變化的兩個(gè)原因，就應(yīng)該寫成兩個(gè)類。

     如果混在一起寫，在修改的一個(gè)職責(zé)的時(shí)候，就會(huì)影響到另一個(gè)職責(zé)。當(dāng)另一個(gè)類只使用其中一個(gè)職責(zé)的時(shí)
     
候，另一不會(huì)用到的職責(zé)會(huì)消耗更多的資源。

     "對(duì)于擴(kuò)展是開放的，對(duì)于修改是關(guān)閉的",這就是開閉原則原理

     開閉原則明確的告訴我們：軟件實(shí)現(xiàn)應(yīng)該對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉，其含義就是說：一個(gè)軟件應(yīng)該通過

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

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

界定他還能買一根香腸。那么現(xiàn)在是對(duì)已經(jīng)代碼的一種擴(kuò)展。

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

維護(hù)性。

    "任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。 里氏代換原則是繼承復(fù)用的基石，只有當(dāng)衍生類可以

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

的行為"。

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

 上兩點(diǎn)就是里氏代換原則。  

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

"駝鳥"也可以出現(xiàn)，而且替換為子類不會(huì)產(chǎn)生任何的Error或Exception，但是，"駝鳥"出現(xiàn)的地 方，"鳥"未

必就能適應(yīng)。

高層模塊不應(yīng)該依賴低層模塊，兩者都應(yīng)該依賴其抽象

抽象不依賴實(shí)現(xiàn)

實(shí)現(xiàn)依賴抽象

   以上三點(diǎn)就是依賴倒轉(zhuǎn)的原則，什么意思呢？指的是模塊與模塊之間的信賴是通過抽象發(fā)生的，實(shí)現(xiàn)類之間
   
相互獨(dú)立，之間不發(fā)生直接的信賴關(guān)系，其依賴關(guān)系是通過接口或者抽象類產(chǎn)生的，接口或者抽象類不依賴實(shí)現(xiàn)，

實(shí)現(xiàn)依賴接口或者抽象類。更加精簡(jiǎn)的意思叫做“面向接口編程” 。

   采用依賴倒置原則可以減少類間的耦合性，提高系統(tǒng)的穩(wěn)定性，減少并行開發(fā)引起的風(fēng)險(xiǎn)，提高代碼的可讀性

和可維護(hù)性。

   這里打個(gè)比方：人，和一包笑笑牌辣條。創(chuàng)建一個(gè)人類A，里面有一個(gè)吃辣條的動(dòng)作a1方法，再來一個(gè)笑笑

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

現(xiàn)，這個(gè)人吃辣條這個(gè)場(chǎng)景，人類A和笑笑牌辣條類B之間是一個(gè)緊耦合的關(guān)系，假如我們這里還有一個(gè)只吃花生

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

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

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

我們這個(gè)場(chǎng)景就可以減少類間的耦合性，提高系統(tǒng)穩(wěn)定性，減少并行開發(fā)引起的風(fēng)險(xiǎn)，提高代碼的可讀性和可維

護(hù)性以為可擴(kuò)展性。

客戶端不應(yīng)該依賴它不需要的接口

一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上

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

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

    接口隔離原則與單一職現(xiàn)原則其實(shí)也沒有，主要是角度不一樣，單一職責(zé)原則要求類和接口只應(yīng)該響應(yīng)一

個(gè)變化，接口隔離原則要求接口的方法盡可能少，盡可能的去細(xì)化

    總之呢：接口要盡量小，接口要高內(nèi)聚，接口設(shè)計(jì)是有限度的。一個(gè)接口只服務(wù)一地一個(gè)子模塊或者業(yè)務(wù)。

這個(gè)要?jiǎng)澐珠_了，不要糅合在一起。接口要不斷的精簡(jiǎn)，使之更加完善。如果接口是壞的，改之。如果背鍋的

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

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

University的Ian Holland提出。類與類之間的關(guān)系越好(緊密)，耦合度越高（大），當(dāng)一個(gè)類發(fā)生改變時(shí)，

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

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

的public方法，不對(duì)外泄漏任何信息。

    打個(gè)比方，有一個(gè)辣條類，老板叫員工去清算辣條的包數(shù)。這里我們創(chuàng)建一個(gè)辣條類A,創(chuàng)建一個(gè)員工類B,

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

員工清算辣條的方法c1。里面初始化了辣條的數(shù)量。我們通過調(diào)用這個(gè)命令來達(dá)到清算辣條的數(shù)量。這里是我

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

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

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

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

中轉(zhuǎn)或跳轉(zhuǎn)類，導(dǎo)致系統(tǒng)復(fù)雜，為維護(hù)帶來了難度。所以，我們?cè)趯?shí)踐時(shí)要反復(fù)權(quán)衡，即要讓結(jié)構(gòu)清晰，又做

到高內(nèi)聚低耦合。   

  設(shè)計(jì)模式就是實(shí)現(xiàn)了這些原則，從而達(dá)到了代碼復(fù)用、增加可維護(hù)性的目的 

  設(shè)計(jì)模式是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了
  
  可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性             

幾種常見的設(shè)計(jì)模式

如果有侵權(quán)，馬上刪除