1、單一職能原則（Single Responsibility Principle, SRP）

定義

There should never be more than one reason for a class to change.

應(yīng)該有且僅有一個(gè)原因引起類(lèi)的變更

換言之，也就是一個(gè)接口或類(lèi)只有一個(gè)職責(zé)

好處

• 類(lèi)的復(fù)雜性降低，實(shí)現(xiàn)什么職責(zé)都有清晰明確的定義；
• 可讀性提高，復(fù)雜性降低，那當(dāng)然可讀性提高了；
• 可維護(hù)性提高，可讀性提高，那當(dāng)然更容易維護(hù)了；
• 變更引起的風(fēng)險(xiǎn)降低，變更時(shí)必不可少的，如果接口的單一職責(zé)做得好，一個(gè)接口修改只對(duì)相應(yīng)的實(shí)現(xiàn)類(lèi)有影響，對(duì)其他的接口無(wú)影響，這對(duì)系統(tǒng)的擴(kuò)展性、維護(hù)性都有非常大的幫助。

最佳實(shí)踐

職責(zé)的劃分很難，要想完全符合單一職責(zé)的設(shè)計(jì)更難，原則是接口一定要做到單一職責(zé)，類(lèi)的設(shè)計(jì)盡量做到只有一個(gè)原因引起變化

2、里氏替換原則（LiskovSubstitution Principle，LSP）

繼承的利與弊

• 優(yōu)點(diǎn)
  • 代碼共享，減少創(chuàng)建類(lèi)的工作量，每個(gè)子類(lèi)都擁有父類(lèi)的方法和屬性；
  • 提高代碼的重用性；
  • 子類(lèi)可以形似父類(lèi)，但又異于父類(lèi)；
  • 提高代碼的可擴(kuò)展性，實(shí)現(xiàn)父類(lèi)的方法就可以“為所欲為”了；
  • 提高產(chǎn)品或項(xiàng)目的開(kāi)放性。
• 缺點(diǎn)
  • 繼承是侵入性的。只要繼承，就必須擁有父類(lèi)的所有屬性和方法；
  • 降低代碼的靈活性。子類(lèi)必須擁有父類(lèi)的屬性和方法，讓子類(lèi)自由的世界中多了些約束；
  • 增強(qiáng)了耦合性。當(dāng)父類(lèi)的常量、變量和方法被修改時(shí)，需要考慮子類(lèi)的修改，而且在缺乏規(guī)范的環(huán)境下，這種修改可能帶來(lái)非常糟糕的結(jié)果——大段的代碼需要重構(gòu)。

定義

If for each object o1 of type S there is an object o2 oftype T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 issubstituted for o2 then S is a subtype of T.

如果對(duì)每一個(gè)類(lèi)型為S的對(duì)象o1，都有類(lèi)型為T(mén)的對(duì)象o2，使得以T定義的所有程序P在所有的對(duì)象o1都代換成o2時(shí)，程序P的行為沒(méi)有發(fā)生變化，那么類(lèi)型S是類(lèi)型T的子類(lèi)型。

以上是LSP"最正宗"的定義，但是可能不太容易理解，它還有另外一種相對(duì)清晰明確的定義：

Functions that use pointers or references to base classes must be able to useobjects of derived classes without knowing it.

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

通俗點(diǎn)講，只要父類(lèi)能出現(xiàn)的地方子類(lèi)就可以出現(xiàn)，而且替換為子類(lèi)也不會(huì)產(chǎn)生任何錯(cuò)誤或異常，使用者可能根本就不需要知道是父類(lèi)還是子類(lèi)。但是，反過(guò)來(lái)就不行了，有子類(lèi)出現(xiàn)的地方，父類(lèi)未必就能適應(yīng)。(LSP可以正著用但不能反著用)

規(guī)范

里氏替換原則為良好的繼承定義了一個(gè)規(guī)范，一句簡(jiǎn)單的定義包含了4層含義：

• 子類(lèi)必須完全實(shí)現(xiàn)父類(lèi)的方法

  如果子類(lèi)不能完整地實(shí)現(xiàn)父類(lèi)的方法，或者父類(lèi)的某些方法在子類(lèi)中已經(jīng)發(fā)生“畸變”，則建議斷開(kāi)父子繼承關(guān)系，采用依賴(lài)、聚集、組合等關(guān)系代替繼承。

• 子類(lèi)可以有自己的個(gè)性

• 覆蓋或?qū)崿F(xiàn)父類(lèi)的方法時(shí)輸入?yún)?shù)可以被放大(重載而非覆蓋)

• 覆寫(xiě)或?qū)崿F(xiàn)父類(lèi)的方法時(shí)輸出結(jié)果可以被縮小

  父類(lèi)的一個(gè)方法的返回值是一個(gè)類(lèi)型T，子類(lèi)的相同方法（重載或覆寫(xiě)）的返回值為S，那么里氏替換原則就要求S必須小于等于T，也就是說(shuō)，要么S和T是同一個(gè)類(lèi)型，要么S是T的子類(lèi)。

最佳實(shí)踐

在項(xiàng)目中，采用里氏替換原則時(shí)，盡量避免子類(lèi)的“個(gè)性”，一旦子類(lèi)有“個(gè)性”，這個(gè)子類(lèi)和父類(lèi)之間的關(guān)系就很難調(diào)和了，把子類(lèi)當(dāng)做父類(lèi)使用，子類(lèi)的“個(gè)性”被抹殺——委屈了點(diǎn)；把子類(lèi)單獨(dú)作為一個(gè)業(yè)務(wù)來(lái)使用，則會(huì)讓代碼間的耦合關(guān)系變得撲朔迷離——缺乏類(lèi)替換的標(biāo)準(zhǔn)。

3、依賴(lài)倒置原則（Dependence Inversion Principle,DIP）

定義

High level modules should not depend upon low level modules.Both should depend uponabstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

• 高層模塊不應(yīng)該依賴(lài)低層模塊，兩者都應(yīng)該依賴(lài)其抽象；
• 抽象不應(yīng)該依賴(lài)細(xì)節(jié)；
• 細(xì)節(jié)應(yīng)該依賴(lài)抽象。

依賴(lài)倒置原則在Java中的體現(xiàn)：

• 模塊間的依賴(lài)通過(guò)抽象發(fā)生，實(shí)現(xiàn)類(lèi)之間不發(fā)生直接的依賴(lài)關(guān)系，其依賴(lài)關(guān)系是通過(guò)接口或抽象類(lèi)產(chǎn)生的；
• 接口或抽象類(lèi)不依賴(lài)于實(shí)現(xiàn)類(lèi)；
• 實(shí)現(xiàn)類(lèi)依賴(lài)接口或抽象類(lèi)。

更加精簡(jiǎn)的定義就是“面向接口編程”。

依賴(lài)的三種寫(xiě)法

• 構(gòu)造函數(shù)傳遞依賴(lài)對(duì)象（構(gòu)造函數(shù)注入），在類(lèi)中通過(guò)構(gòu)造函數(shù)聲明依賴(lài)對(duì)象
• Setter方法傳遞依賴(lài)對(duì)象（Setter依賴(lài)注入），在抽象中設(shè)置Setter方法聲明依賴(lài)關(guān)系
• 在接口的方法中聲明依賴(lài)對(duì)象（接口注入）

最佳實(shí)踐

依賴(lài)倒置原則的本質(zhì)就是通過(guò)抽象（接口或抽象類(lèi)）使各個(gè)類(lèi)或模塊的實(shí)現(xiàn)彼此獨(dú)立，不互相影響，實(shí)現(xiàn)模塊間的松耦合，我們?cè)趺丛陧?xiàng)目中使用這個(gè)規(guī)則呢？只要遵循以下的幾個(gè)規(guī)則就可以：

• 每個(gè)類(lèi)盡量都有接口或抽象類(lèi)，或者抽象類(lèi)和接口兩者都具備

  這是依賴(lài)倒置的基本要求，接口和抽象類(lèi)都是屬于抽象的，有了抽象才可能依賴(lài)倒置

• 變量的表面類(lèi)型盡量是接口或者是抽象類(lèi)

• 任何類(lèi)都不應(yīng)該從具體類(lèi)派生

• 盡量不要覆寫(xiě)基類(lèi)的方法

• 結(jié)合里氏替換原則使用

  父類(lèi)出現(xiàn)的地方子類(lèi)就能出現(xiàn)，再DIP，我們可以得出這樣一個(gè)通俗的規(guī)則： 接口負(fù)責(zé)定義public屬性和方法，并且聲明與其他對(duì)象的依賴(lài)關(guān)系，抽象類(lèi)負(fù)責(zé)公共構(gòu)造部分的實(shí)現(xiàn)，實(shí)現(xiàn)類(lèi)準(zhǔn)確的實(shí)現(xiàn)業(yè)務(wù)邏輯，同時(shí)在適當(dāng)?shù)臅r(shí)候?qū)Ω割?lèi)進(jìn)行細(xì)化。

依賴(lài)倒置原則是6個(gè)設(shè)計(jì)原則中最難以實(shí)現(xiàn)的原則，它是實(shí)現(xiàn)開(kāi)閉原則的重要途徑，依賴(lài)倒置原則沒(méi)有實(shí)現(xiàn)，就別想實(shí)現(xiàn)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。在項(xiàng)目中，大家只要記住是“面向接口編程”就基本上抓住了依賴(lài)倒置原則的核心。

4、接口隔離原則（Interface Segregations Principle, ISP）

定義

接口隔離原則有以下兩種定義：

Clients should not be forced to depend upon interfaces that they don't use.

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

解釋?zhuān)嚎蛻舳诵枰裁唇涌诰吞峁┦裁唇涌冢巡恍枰慕涌谔蕹?，那就需要?duì)接口進(jìn)行細(xì)化，保證其純潔性；

The dependency of one class to another one should depend on the smallest possible interface.

類(lèi)間的依賴(lài)關(guān)系應(yīng)該建立在最小的接口上。

解釋?zhuān)阂笫亲钚〉慕涌冢彩且蠼涌诩?xì)化，接口純潔，與第一個(gè)定義如出一轍，只是一個(gè)事物的兩種不同描述。

概括：建立單一接口，不要建立臃腫龐大的接口。再通俗一點(diǎn)講：接口盡量細(xì)化，同時(shí)接口中的方法盡量少。

接口隔離原則 VS 單一職責(zé)原則

• 接口隔離原則與單一職責(zé)的審視角度是不相同的

• 單一職責(zé)要求的是類(lèi)和接口職責(zé)單一，注重的是職責(zé)，這是業(yè)務(wù)邏輯上的劃分；

• 接口隔離原則要求接口的方法盡量少。

例如一個(gè)接口的職責(zé)可能包含10個(gè)方法，這10個(gè)方法都放在一個(gè)接口中，并且提供給多個(gè)模塊訪問(wèn)，各個(gè)模塊按照規(guī)定的權(quán)限來(lái)訪問(wèn)，在系統(tǒng)外通過(guò)文檔約束“不使用的方法不要訪問(wèn)”，按照單一職責(zé)原則是允許的，按照接口隔離原則是不允許的，因?yàn)樗蟆氨M量使用多個(gè)專(zhuān)門(mén)的接口”。專(zhuān)門(mén)的接口指什么？就是指提供給每個(gè)模塊的都應(yīng)該是單一接口，提供給幾個(gè)模塊就應(yīng)該有幾個(gè)接口，而不是建立一個(gè)龐大的臃腫的接口，容納所有的客戶端訪問(wèn)。

// TODO 還是感覺(jué)差不太多...

規(guī)范

• 接口要盡量小

  • 要有限度
  • 不能違背單一職責(zé)原則（業(yè)務(wù)上的劃分）

• 接口要高內(nèi)聚

  高內(nèi)聚具體到接口隔離原則就是，要求在接口中盡量少公布public方法，接口是對(duì)外的承諾，承諾越少對(duì)系統(tǒng)的開(kāi)發(fā)越有利，變更的風(fēng)險(xiǎn)也就越少，同時(shí)也有利于降低成本。

• 定制服務(wù)（只提供訪問(wèn)者需要的方法）

  舉例說(shuō)明：一個(gè)用于查詢(xún)用戶的接口，應(yīng)該提供具體的根據(jù)用戶ID查詢(xún)或者根據(jù)用戶名查詢(xún)等于業(yè)務(wù)相關(guān)的特定接口，而不是提供一個(gè)帶有Map（或者說(shuō)類(lèi)似Mybatis Example）參數(shù)的查詢(xún)接口

• 接口設(shè)計(jì)是有限度的

  • 接口的設(shè)計(jì)粒度越小，系統(tǒng)越靈活；
  • 但是，靈活的同時(shí)也帶來(lái)了結(jié)構(gòu)的復(fù)雜化，開(kāi)發(fā)難度增加，可維護(hù)性降低，這不是一個(gè)項(xiàng)目或產(chǎn)品所期望看到的；
  • 所以接口設(shè)計(jì)一定要注意適度，這個(gè)“度”如何來(lái)判斷呢？根據(jù)經(jīng)驗(yàn)和常識(shí)判斷，沒(méi)有一個(gè)固化或可測(cè)量的標(biāo)準(zhǔn)。

最佳實(shí)踐

接口隔離原則是對(duì)接口的定義，同時(shí)也是對(duì)類(lèi)的定義，接口和類(lèi)盡量使用原子接口或原子類(lèi)來(lái)組裝。但是，這個(gè)原子該怎么劃分是設(shè)計(jì)模式中的一大難題，在實(shí)踐中可以根據(jù)以下幾個(gè)規(guī)則來(lái)衡量：

• 一個(gè)接口只服務(wù)于一個(gè)子模塊或業(yè)務(wù)邏輯；
• 通過(guò)業(yè)務(wù)邏輯壓縮接口中的public方法，接口時(shí)常去回顧，盡量讓接口達(dá)到“滿身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；
• 已經(jīng)被污染了的接口，盡量去修改，若變更的風(fēng)險(xiǎn)較大，則采用適配器模式進(jìn)行轉(zhuǎn)化處理；
• 了解環(huán)境，拒絕盲從。每個(gè)項(xiàng)目或產(chǎn)品都有特定的環(huán)境因素，環(huán)境不同，接口拆分的標(biāo)準(zhǔn)就不同。深入了解業(yè)務(wù)邏輯，結(jié)合實(shí)際情況進(jìn)行接口設(shè)計(jì)。

5、迪米特法則（Law of Demeter，LoD）

也稱(chēng)為最少知識(shí)原則（Least KnowledgePrinciple，LKP）

定義

一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象有最少的了解

通俗地講，一個(gè)類(lèi)應(yīng)該對(duì)自己需要耦合或調(diào)用的類(lèi)知道得最少，你（被耦合或調(diào)用的類(lèi)）的內(nèi)部是如何復(fù)雜都和我沒(méi)關(guān)系，那是你的事情，我就知道你提供的這么多public方法，我就調(diào)用這么多，其他的我一概不關(guān)心。

含義

• 只和朋友交流

  迪米特法則還有一個(gè)英文解釋是：

  Only talk to your immediate friends.

  只與直接的朋友通信。

  一個(gè)類(lèi)只和朋友交流，不與陌生類(lèi)交流，不要出現(xiàn)getA().getB().getC().getD()這種情況（在一種極端的情況下允許出現(xiàn)這種訪問(wèn)，即每一個(gè)點(diǎn)號(hào)后面的返回類(lèi)型都相同），類(lèi)與類(lèi)之間的關(guān)系是建立在類(lèi)間的，而不是方法間，因此一個(gè)方法盡量不引入一個(gè)類(lèi)中不存在的對(duì)象，當(dāng)然，JDK API提供的類(lèi)除外。

• 朋友間也是有距離的

  迪米特法則要求類(lèi)“羞澀”一點(diǎn)，盡量不要對(duì)外公布太多的public方法和非靜態(tài)的public變量，盡量?jī)?nèi)斂，多使用private、package-private、protected等訪問(wèn)權(quán)限。

• 是自己的就是自己的

  在實(shí)際應(yīng)用中經(jīng)常會(huì)出現(xiàn)這樣一個(gè)方法：放在本類(lèi)中也可以，放在其他類(lèi)中也沒(méi)有錯(cuò)，那怎么去衡量呢？你可以堅(jiān)持這樣一個(gè)原則：如果一個(gè)方法放在本類(lèi)中，既不增加類(lèi)間關(guān)系，也對(duì)本類(lèi)不產(chǎn)生負(fù)面影響，那就放置在本類(lèi)中。

• 謹(jǐn)慎使用Serializable

最佳實(shí)踐

• 迪米特法則的核心觀念就是類(lèi)間解耦，弱耦合，只有弱耦合了以后，類(lèi)的復(fù)用率才可以提高。其要求的結(jié)果就是產(chǎn)生了大量的中轉(zhuǎn)或跳轉(zhuǎn)類(lèi)，導(dǎo)致系統(tǒng)的復(fù)雜性提高，同時(shí)也為維護(hù)帶來(lái)了難度。在采用迪米特法則時(shí)需要反復(fù)權(quán)衡，既做到讓結(jié)構(gòu)清晰，又做到高內(nèi)聚低耦合。

• 迪米特法則要求類(lèi)間解耦，但解耦是有限度的，除非是計(jì)算機(jī)的最小單元——二進(jìn)制的0和1。那才是完全解耦，在實(shí)際的項(xiàng)目中，需要適度地考慮這個(gè)原則，別為了套用原則而做項(xiàng)目。原則只是供參考，如果違背了這個(gè)原則，項(xiàng)目也未必會(huì)失敗，這就需要大家在采用原則時(shí)反復(fù)度量，不遵循是不對(duì)的，嚴(yán)格執(zhí)行就是“過(guò)猶不及”。

6、開(kāi)閉原則（Open Closed Principle, OCP）

開(kāi)閉原則是Java世界里最基礎(chǔ)的設(shè)計(jì)原則，它指導(dǎo)我們?nèi)绾谓⒁粋€(gè)穩(wěn)定的、靈活的系統(tǒng)

定義

Software entities like classes,modules and functions should be open for extension but closed formodifications.

一個(gè)軟件實(shí)體如類(lèi)、模塊和函數(shù)應(yīng)該對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。

換句話說(shuō)，一個(gè)軟件實(shí)體應(yīng)該通過(guò)擴(kuò)展來(lái)實(shí)現(xiàn)變化，而不是通過(guò)修改已有的代碼來(lái)實(shí)現(xiàn)變化。

重要性

開(kāi)閉原則是最基礎(chǔ)的一個(gè)原則，前面節(jié)介紹的五個(gè)原則都是開(kāi)閉原則的具體形態(tài)，也就是說(shuō)前五個(gè)原則就是指導(dǎo)設(shè)計(jì)的工具和方法，而開(kāi)閉原則才是其精神領(lǐng)袖。換一個(gè)角度來(lái)理解，依照J(rèn)ava語(yǔ)言的稱(chēng)謂，開(kāi)閉原則是抽象類(lèi)，其他五大原則是具體的實(shí)現(xiàn)類(lèi)，開(kāi)閉原則在面向?qū)ο笤O(shè)計(jì)領(lǐng)域中的地位就類(lèi)似于牛頓第一定律在力學(xué)、勾股定律在幾何學(xué)、質(zhì)能方程在狹義相對(duì)論中的地位，其地位無(wú)人能及。

如何使用開(kāi)閉原則

• 抽象約束

  • 通過(guò)接口或抽象類(lèi)約束擴(kuò)展，對(duì)擴(kuò)展進(jìn)行邊界限定，不允許出現(xiàn)在接口或抽象類(lèi)中不存在的public方法；
  • 參數(shù)類(lèi)型、引用對(duì)象盡量使用接口或者抽象類(lèi)，而不是實(shí)現(xiàn)類(lèi)；
  • 抽象層盡量保持穩(wěn)定，一旦確定即不允許修改。

• 元數(shù)據(jù)（metadata）控制模塊行為

  何謂元數(shù)據(jù)？就是用來(lái)描述環(huán)境和數(shù)據(jù)的數(shù)據(jù)，通俗地說(shuō)就是配置參數(shù)，參數(shù)可以從文件中獲得，也可以從數(shù)據(jù)庫(kù)中獲得。

• 制定項(xiàng)目章程（團(tuán)隊(duì)約定）

• 封裝變化

  • 將相同的變化封裝到一個(gè)接口或抽象類(lèi)中；
  • 將不同的變化封裝到不同的接口或抽象類(lèi)中，不應(yīng)該有兩個(gè)不同的變化出現(xiàn)在同一個(gè)接口或抽象類(lèi)中。
  • 封裝變化，也就是受保護(hù)的變化（protected variations），找出預(yù)計(jì)有變化或不穩(wěn)定的點(diǎn)，我們?yōu)檫@些變化點(diǎn)創(chuàng)建穩(wěn)定的接口，準(zhǔn)確地講是封裝可能發(fā)生的變化，一旦預(yù)測(cè)到或“第六感”發(fā)覺(jué)有變化，就可以進(jìn)行封裝，23個(gè)設(shè)計(jì)模式都是從各個(gè)不同的角度對(duì)變化進(jìn)行封裝的

最佳實(shí)踐

• 開(kāi)閉原則也只是一個(gè)原則

  開(kāi)閉原則只是精神口號(hào)，實(shí)現(xiàn)擁抱變化的方法非常多，并不局限于這6大設(shè)計(jì)原則，但是遵循這6大設(shè)計(jì)原則基本上可以應(yīng)對(duì)大多數(shù)變化。因此，我們?cè)陧?xiàng)目中應(yīng)盡量采用這6大原則，適當(dāng)時(shí)候可以進(jìn)行擴(kuò)充，例如通過(guò)類(lèi)文件替換的方式完全可以解決系統(tǒng)中的一些缺陷。大家在開(kāi)發(fā)中比較常用的修復(fù)缺陷的方法就是類(lèi)替換，比如一個(gè)軟件產(chǎn)品已經(jīng)在運(yùn)行中，發(fā)現(xiàn)了一個(gè)缺陷，需要修正怎么辦？如果有自動(dòng)更新功能，則可以下載一個(gè).class文件直接覆蓋原有的class，重新啟動(dòng)應(yīng)用（也不一定非要重新啟動(dòng)）就可以解決問(wèn)題，也就是通過(guò)類(lèi)文件的替換方式修正了一個(gè)缺陷，當(dāng)然這種方式也可以應(yīng)用到項(xiàng)目中，正在運(yùn)行中的項(xiàng)目發(fā)現(xiàn)需要增加一個(gè)新功能，通過(guò)修改原有實(shí)現(xiàn)類(lèi)的方式就可以解決這個(gè)問(wèn)題，前提條件是：類(lèi)必須做到高內(nèi)聚、低耦合，否則類(lèi)文件的替換會(huì)引起不可預(yù)料的故障。

• 項(xiàng)目規(guī)章非常重要

  如果你是一位項(xiàng)目經(jīng)理或架構(gòu)師，應(yīng)盡量讓自己的項(xiàng)目成員穩(wěn)定，穩(wěn)定后才能建立高效的團(tuán)隊(duì)文化，章程是一個(gè)團(tuán)隊(duì)所有成員共同的知識(shí)結(jié)晶，也是所有成員必須遵守的約定。優(yōu)秀的章程能帶給項(xiàng)目帶來(lái)非常多的好處，如提高開(kāi)發(fā)效率、降低缺陷率、提高團(tuán)隊(duì)士氣、提高技術(shù)成員水平，等等。

• 預(yù)知變化

  在實(shí)踐中過(guò)程中，架構(gòu)師或項(xiàng)目經(jīng)理一旦發(fā)現(xiàn)有發(fā)生變化的可能，或者變化曾經(jīng)發(fā)生過(guò)，則需要考慮現(xiàn)有的架構(gòu)是否可以輕松地實(shí)現(xiàn)這一變化。架構(gòu)師設(shè)計(jì)一套系統(tǒng)不僅要符合現(xiàn)有的需求，還要適應(yīng)可能發(fā)生的變化，這才是一個(gè)優(yōu)良的架構(gòu)。

開(kāi)閉原則是一個(gè)終極目標(biāo)，任何人包括大師級(jí)人物都無(wú)法百分之百做到，但朝這個(gè)方向努力，可以非常顯著地改善一個(gè)系統(tǒng)的架構(gòu)，真正做到“擁抱變化”。

7、總結(jié)

首先，無(wú)論是6大設(shè)計(jì)原則還是23種設(shè)計(jì)模式，根本目標(biāo)其實(shí)就是一個(gè)"擁抱變化"，包括需求的變化、運(yùn)行環(huán)境的變化、性能要求的提升等等，實(shí)現(xiàn)一個(gè)需求并不難，但是當(dāng)變化來(lái)臨時(shí)，能否泰然處之，那就是個(gè)技術(shù)活了。

其次，"擁抱變化"落實(shí)到代碼層面是什么？——你的代碼是可維護(hù)的、可擴(kuò)展的，還是說(shuō)"牽一發(fā)動(dòng)全身"，一點(diǎn)小的改動(dòng)很多東西都要跟著變動(dòng)。

再次，要做到"擁抱變化"，讓你的代碼很容易維護(hù)和擴(kuò)展，核心理念就是"高內(nèi)聚、低耦合"，以及"面向接口編程（面向抽象編程）”

最后，設(shè)計(jì)原則、設(shè)計(jì)模式是前輩總結(jié)的"經(jīng)驗(yàn)"，但不是"條款"，盡可能遵循這些規(guī)范會(huì)讓你的設(shè)計(jì)無(wú)限接近完美，但世界上本就沒(méi)有十全十美的東西，凡事都要有個(gè)度，不要認(rèn)死理，不要為了"套模式"而應(yīng)用設(shè)計(jì)模式，要具體問(wèn)題具體分析，根據(jù)實(shí)際情況進(jìn)行權(quán)衡。

設(shè)計(jì)做得再漂亮，代碼寫(xiě)得再完美，項(xiàng)目做得再符合標(biāo)準(zhǔn)，一旦項(xiàng)目虧本，產(chǎn)品投入大于產(chǎn)出，那整體就是扯淡！

參考文獻(xiàn)：《設(shè)計(jì)模式之禪》