設計模式（一）設計模式遵循的七大原則

原文來自搬磚工，如需轉載請注明出處

---

最近幾年來，人們積極的提倡和使用設計模式，其根本緣由就是為了實現(xiàn)代碼的復用性，增加代碼的可保護性。設計模式的實現(xiàn)遵守了1些原則，從而到達代碼的復用性及增加可保護性的目的，設計模式對理解面向對象的3大特點有很好的啟發(fā)，不看設計模式，很難深層地體會到面向對象開發(fā)帶來的好處 。在剛開始學習中，很難做到將這些模式融匯貫通，所以這個需要我們在編碼前多思考，等想充分了，在開始實踐編碼。下面是設計模式應當遵守的7大原則

1、開閉原則（Open Close Principle）
定義：1個軟件實體如類、模塊和函數(shù)應當對擴大開放，對修改關閉。

開放-封閉原則的意思就是說，你設計的時候，時刻要斟酌，盡可能讓這個類是足夠好，寫好了就不要去修改了，如果新需求來，我們增加1些類就完事了，原來的代碼能不動則不動。這個原則有兩個特性，1個是說“對擴大是開放的”，另外一個是說“對更改是封閉的”。面對需求，對程序的改動是通過增加新代碼進行的，而不是更改現(xiàn)有的代碼。這就是“開放-封閉原則”的精神所在

比如，剛開始需求只是寫加法程序，很快在client類中完成后，此時變化沒有產(chǎn)生，需求讓再添加1個減法功能，此時會發(fā)現(xiàn)增加功能需要修改原來這個類，這就背背了開放-封閉原則，因而你就應當斟酌重構程序，增加1個抽象的運算類，通過1些面向對象的手段，如繼承、動態(tài)等來隔離具體加法、減法與client耦合，需求仍然可以滿足，還能應對變化。此時需求要添加乘除法功能，就不需要再去更改client及加減法類，而是增加乘法和除方法類便可。

絕對的修改關閉是不可能的，不管模塊是多么的‘封閉‘，都會存在1些沒法對之封閉的變化，既然不可能完全封閉，設計人員必須對他設計的模塊應當對哪一種變化封閉做出選擇。他必須先猜想出最有可能產(chǎn)生的變化種類，然后構造抽象來隔離那些變化。在我們最初編寫代碼時，假定變化不會產(chǎn)生，當變化產(chǎn)生時，我們就創(chuàng)建抽象來隔離以后產(chǎn)生同類的變化。

我們希望的是在開發(fā)工作展開不久就知道可能產(chǎn)生的變化，查明可能產(chǎn)生的變化所等待的時候越長，要創(chuàng)建正確的抽象就越困難。開放-封閉原則是面向對象設計的核心所在，遵守這個原則可以帶來面向對象技術所宣稱的巨大好處，也就是可保護、可擴大、可復用、靈活性好。開發(fā)人員應當僅對程序中顯現(xiàn)出現(xiàn)頻繁變化的那些部份做出抽象，但是對利用程序中的每一個部份都刻意地進行抽象一樣不是1個好主張，謝絕不成熟的抽象和抽象本身1樣重要。開放-封閉原則，可以保證之前代碼的正確性，由于沒有修改之前代碼，所以可以保證開發(fā)人員專注于將設計放在新擴大的代碼上。

簡單的用1句經(jīng)典的話來講：過去的事已成歷史，是不可修改的，由于時光不可倒流，但現(xiàn)在或明天計劃做甚么，是可以自己決定(即擴大)的。

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

定義1：如果對每個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 P 的行動沒有產(chǎn)生變化，那末類型 T2 是類型 T1 的子類型。

定義2：子類型必須能夠替換掉它們的父類型。

描寫：1個軟件實體如果使用的是1個父類的話，那末1定適用于其子類，而且它發(fā)覺不出父類對象和子類對象的區(qū)分，也就是說，在軟件里面，把父類都替換成它的子類，程序的行動沒有變化

例子：在生物學分類上，企鵝是1種鳥，但在編程世界里，企鵝卻不能繼承鳥。在面向對象設計時，子類具有父類所有非private的行動和屬性，鳥會飛，但企鵝不會飛，所以企鵝不能繼承鳥類。

只有當子類可以替換掉父類，軟件單位的功能不受影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行動，正是有里氏代換原則，使得繼承復用成了可能。正是由于子類型的可替換性才使得使用父類類型的模塊在無需修改的情況下就能夠擴大，不然還談甚么擴大開放，修改關閉呢

里氏替換原則通俗的來說就是：子類可以擴大父類的功能，但不能改變父類原本的功能。它包括以下4層含義
1.子類可以實現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法。
2.子類中可以增加自己獨有的方法。
3.當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。

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

看上去很不可思議，由于我們會發(fā)現(xiàn)在自己編程中常常會違背里氏替換原則，程序照樣跑的好好的。所以大家都會產(chǎn)生這樣的疑問，假設我非要不遵守里氏替換原則會有甚么后果？
后果就是：你寫的代碼出問題的概率將會大大增加。

3、依賴倒轉原則（Dependence Inversion Principle）
定義：高層模塊不應當依賴低層模塊，2者都應當依賴其抽象；抽象不應當依賴細節(jié)；細節(jié)應當依賴抽象。即針對接口編程，不要針對實現(xiàn)編程
依賴倒轉其實就是誰也不要依托誰，除約定的接口，大家都可以靈活自若。依賴倒轉可以說是面向對象設計的標志，用哪一種語言來編寫程序不重要，如果編寫時斟酌的都是如何針對抽象編程而不是針對細節(jié)編程，即程序中所有的依賴關系都是終止于抽象類或接口，那就是面向對象的設計，反之那就是進程化的設計了。如果設計的各個部件或類相互依賴，這樣就是耦合度高，難以保護和擴大，這也就體現(xiàn)不出面向對象的好處了。
依賴倒轉原則，好比1個團隊，有需求組，開發(fā)組，測試組，開發(fā)組和測試組都是面對一樣的需求后，做自己相應的工作，而不應當是測試組依照開發(fā)組理解的需求去做測試用例，也就是說開發(fā)組和測試組都是直接面向需求組工作，大家的目的是1樣的，保證產(chǎn)品按時上線，需求是不依賴于開發(fā)和測試的。
依賴顛倒原則基于這樣1個事實：相對細節(jié)的多變性，抽象的東西要穩(wěn)定的多。以抽象為基礎搭建起來的架構比以細節(jié)為基礎搭建起來的架構要穩(wěn)定的多。在Java中，抽象指的是接口或抽象類，細節(jié)就是具體的實現(xiàn)類，使用接口或抽象類的目的是制定好規(guī)范和契約，而不去觸及任何具體的操作，把展現(xiàn)細節(jié)的任務交給他們的實現(xiàn)類去完成。

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

在實際編程中，我們1般需要做到以下3點：
1.低層模塊盡可能都要有抽象類或接口，或二者都有。
2.變量的聲明類型盡可能是抽象類或接口。
3.使用繼承時遵守里氏替換原則。
總之，依賴顛倒原則就是要我們面向接口編程，理解了面向接口編程，也就理解了依賴顛倒。

4、接口隔離原則（Interface Segregation Principle）
接口隔離原則的含義是：建立單1接口，不要建立龐大臃腫的接口，盡可能細化接口，接口中的方法盡可能少。也就是說，我們要為各個類建立專用的接口，而不要試圖去建立1個很龐大的接口供所有依賴它的類去調(diào)用。在程序設計中，依賴幾個專用的接口要比依賴1個綜合的接口更靈活。接口是設計時對外部設定的“契約”，通過分散定義多個接口，可以預防外來變更的分散，提高系統(tǒng)的靈活性和可保護性。
說到這里，很多人會覺的接口隔離原則跟單1職責原則很相似，其實不然。其1，單1職責原則原重視的是職責；而接口隔離原則重視對接口依賴的隔離。其2，單1職責原則主要是束縛類，其次才是接口和方法，它針對的是程序中的實現(xiàn)和細節(jié)；而接口隔離原則主要束縛接口接口，主要針對抽象，針對程序整體框架的構建。
采取接口隔離原則對接口進行束縛時，要注意以下幾點：
1. 接口盡可能小，但是要有限度。對接口進行細化可以提高程序設計靈活性是不掙的事實，但是如果太小，則會造成接口數(shù)量過量，使設計復雜化。所以1定要適度。
2. 為依賴接口的類定制服務，只暴露給調(diào)用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為1個模塊提供定制服務，才能建立最小的依賴關系。
3. 提高內(nèi)聚，減少對外交互。使接口用最少的方法去完成最多的事情。
應用接口隔離原則，1定要適度，接口設計的過大或太小都不好。設計接口的時候，只有多花些時間去思考和籌劃，才能準確地實踐這1原則。

5、組合/聚合復用原則
就是說要盡可能的使用合成和聚合，而不是繼承關系到達復用的目的
該原則就是在1個新的對象里面使用1些已有的對象，使之成為新對象的1部份：新的對象通過向這些對象的委派到達復用已有功能的目的。
其實這里終究要的地方就是辨別“has-a”和“is-a”的區(qū)分。相對合成和聚合，
繼承的缺點在于：父類的方法全部暴露給子類。父類如果產(chǎn)生變化，子類也得產(chǎn)生變化。聚合的復用的時候就對另外的類依賴的比較的少。
1.合成/聚合復用
優(yōu)點：
新對象存取成份對象的唯1方法是通過成份對象的接口；
這類復用是黑箱復用，由于成份對象的內(nèi)部細節(jié)是新對象所看不見的；
這類復用支持包裝；
這類復用所需的依賴較少；
每個新的類可以將焦點集中在1個任務上；
這類復用可以在運行時動態(tài)進行，新對象可使用合成/聚合關系將新的責任委派到適合的對象。
缺點：
通過這類方式復用建造的系統(tǒng)會有較多的對象需要管理。
2.繼承復用
優(yōu)點：
新的實現(xiàn)較為容易，由于基類的大部份功能可以通過繼承關系自動進入派生類；
修改或擴大繼承而來的實現(xiàn)較為容易。
缺點：
繼承復用破壞包裝，由于繼承將基類的實現(xiàn)細節(jié)暴露給派生類，這類復用也稱為白箱復用；
如果基類的實現(xiàn)產(chǎn)生改變，那末派生類的實現(xiàn)也不能不產(chǎn)生改變；
從基類繼承而來的實現(xiàn)是靜態(tài)的，不可能在運行時產(chǎn)生改變，不夠靈活。

6、迪米特法則（Law Of Demeter）
迪米特法則其根本思想，是強調(diào)了類之間的松耦合，類之間的耦合越弱,越有益于復用，1個處在弱耦合的類被修改，不會對有關系的類造成影響，也就是說，信息的隱藏增進了軟件的復用。
自從我們接觸編程開始，就知道了軟件編程的總的原則：低耦合，高內(nèi)聚。不管是面向進程編程還是面向對象編程，只有使各個模塊之間的耦合盡可能的低，才能提高代碼的復用率。低耦合的優(yōu)點不言而喻，但是怎樣樣編程才能做到低耦合呢？那正是迪米特法則要去完成的。
迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來說，就是1個類對自己依賴的類知道的越少越好。也就是說，對被依賴的類來講，不管邏輯多么復雜，都盡可能地的將邏輯封裝在類的內(nèi)部，對外除提供的public方法，不對外泄漏任何信息。迪米特法則還有1個更簡單的定義：只與直接的朋友通訊。首先來解釋1下甚么是直接的朋友：每一個對象都會與其他對象有耦合關系，只要兩個對象之間有耦合關系，我們就說這兩個對象之間是朋友關系。耦合的方式很多，依賴、關聯(lián)、組合、聚合等。其中，我們稱出現(xiàn)成員變量、方法參數(shù)、方法返回值中的類為直接的朋友，而出現(xiàn)在局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要作為局部變量的情勢出現(xiàn)在類的內(nèi)部。
1句話總結就是：1個對象應當對其他對象保持最少的了解。

7、單1職責原則（Single Responsibility Principle）
定義：不要存在多于1個致使類變更的緣由。通俗的說，即1個類只負責1項職責，應當唯一1個引發(fā)它變化的緣由
說到單1職責原則，很多人都會嗤之以鼻。由于它太簡單了。稍有經(jīng)驗的程序員即便歷來沒有讀過設計模式、歷來沒有聽說過單1職責原則，在設計軟件時也會自覺的遵照這1重要原則，由于這是常識。在軟件編程中，誰也不希望由于修改了1個功能致使其他的功能產(chǎn)生故障。而避免出現(xiàn)這1問題的方法便是遵守單1職責原則。雖然單1職責原則如此簡單，并且被認為是常識，但是即使是經(jīng)驗豐富的程序員寫出的程序，也會有背背這1原則的代碼存在。為何會出現(xiàn)這類現(xiàn)象呢？由于有職責分散。所謂職責分散，就是由于某種緣由，職責P被分化為粒度更細的職責P1和P2。
遵守單1職責原的優(yōu)點有：
1.可以下降類的復雜度，1個類只負責1項職責，其邏輯肯定要比負責多項職責簡單的多；
2.提高類的可讀性，提高系統(tǒng)的可保護性；
3.變更引發(fā)的風險下降，變更是必定的，如果單1職責原則遵照的好，當修改1個功能時，可以顯著下降對其他功能的影響。
需要說明的1點是單1職責原則不只是面向對象編程思想所獨有的，只要是模塊化的程序設計，都需要遵守這1重要原則。