所有的設(shè)計(jì)模式都是對(duì)不同的可變性的封裝，從而使系統(tǒng)在不同角度達(dá)到“開閉原則”的要求。

在軟件軟件系統(tǒng)中，一個(gè)模塊設(shè)計(jì)得好不好的最主要、最重要的標(biāo)志，就是該模塊在多大程度上將自己的內(nèi)部數(shù)據(jù)和其他與實(shí)現(xiàn)有關(guān)的細(xì)節(jié)隱藏起來。一個(gè)設(shè)計(jì)得好的模塊可以將它所有的實(shí)現(xiàn)細(xì)節(jié)隱藏起來，徹底地將提供給外界的API和自己的實(shí)現(xiàn)分隔開來。這樣一來，模塊與模塊之間就可以僅僅通過彼此的API相互通信，而不理會(huì)模塊內(nèi)部的工作細(xì)節(jié)。

設(shè)計(jì)根本的指導(dǎo)原則是提高可維護(hù)性和可復(fù)用性。這些原則主要有：

1.開閉原則

一個(gè)軟件實(shí)體應(yīng)該對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。

在設(shè)計(jì)一個(gè)模塊的時(shí)候，就當(dāng)使這個(gè)模塊可以在不被修改的前提下被擴(kuò)展。換言之，就當(dāng)可以在不必修改源代碼的情況下改變這個(gè)模塊的行為。

如何做到既不修改，又可以擴(kuò)展？

解決問題的關(guān)鍵在于抽象化：在Java語言里，可以給出一個(gè)或多個(gè)抽象Java類或Java接口，規(guī)定出所有的具體類必須提供的方法特征作為系統(tǒng)設(shè)計(jì)的抽象層。這個(gè)抽象層預(yù)見了所有的可能擴(kuò)展，因此，在任何擴(kuò)展情況下都不會(huì)改變。這就使得系統(tǒng)的抽象層不需要修改，從而滿足了—對(duì)修改關(guān)閉。

同時(shí)，由于從抽象層導(dǎo)出一個(gè)或多個(gè)新的具體類可以改變系統(tǒng)的行為，因此系統(tǒng)的設(shè)計(jì)對(duì)擴(kuò)展是開放的。

開閉原則實(shí)際上是對(duì)“對(duì)可變性的封閉原則“：找到一個(gè)系統(tǒng)的可變因素，將之封裝起來。這個(gè)原則意昧著兩點(diǎn)：

1)一個(gè)可變性不應(yīng)當(dāng)散落在代碼的很多角落里，而應(yīng)當(dāng)被封裝到一個(gè)對(duì)象里面。同一種可變性的不同表象意昧著同一個(gè)繼承等級(jí)結(jié)構(gòu)中的具體子類。

繼承就當(dāng)被看作是封裝變化的方法，而不應(yīng)當(dāng)被認(rèn)為是從一般的對(duì)象生成特殊對(duì)象的方法。

2)一種可變性不應(yīng)當(dāng)與另一種可變性混合在一起。（所有類圖的繼承結(jié)構(gòu)一般不會(huì)超過兩層，不然就意昧著將兩種不同的可變性混合在了一起。）

開閉原則是總的原則，其它幾條是開閉原則的手段和工具。

2.依賴倒轉(zhuǎn)原則

依賴倒轉(zhuǎn)原則講的是：要依賴于抽象，不要信賴于實(shí)現(xiàn)。

開閉原則是目標(biāo)，而達(dá)到這一目標(biāo)的手段是依賴倒轉(zhuǎn)原則。

抽象層次包含的是應(yīng)用系統(tǒng)的商務(wù)邏輯和宏觀的、對(duì)整個(gè)系統(tǒng)來說重要的戰(zhàn)略性決定，是必然性的體現(xiàn)；而具體層次則含有一些次要的與實(shí)現(xiàn)有關(guān)的算法和邏輯，以及戰(zhàn)術(shù)性的決定，帶有相當(dāng)大的偶然性選擇。具體層次的代碼是會(huì)經(jīng)常有變動(dòng)的，不能避免出現(xiàn)錯(cuò)誤。

抽象層次含有一個(gè)應(yīng)用系統(tǒng)最重要的宏觀商務(wù)邏輯，是做戰(zhàn)略判斷和決定的地方，那么抽象層次就應(yīng)當(dāng)是較為穩(wěn)定的，應(yīng)當(dāng)是復(fù)用的重點(diǎn)；也應(yīng)當(dāng)是維護(hù)的重點(diǎn)。

在很多情況下，一個(gè)Java程序需要引用一個(gè)對(duì)象。這個(gè)時(shí)候，如果這個(gè)對(duì)象有一個(gè)抽象類型的話，應(yīng)當(dāng)使用這個(gè)抽象類型作為變量的靜態(tài)類型。這就是針對(duì)接口編程的含義。

一般而言，在創(chuàng)建一個(gè)對(duì)象時(shí)，Java語言要求使用new關(guān)鍵詞以及這個(gè)類本身。而一旦這個(gè)對(duì)象已經(jīng)被創(chuàng)建出來，那么就可以靈活地使用這個(gè)對(duì)象的抽象類型來引用它。比如：Listemployees=newVector()；因此，Java語言中創(chuàng)建一個(gè)對(duì)象的過程是違背“開閉原則”以及依賴倒轉(zhuǎn)原則的（因?yàn)橄壬闪司唧w的類型，再使用抽象的引用），雖然在這個(gè)類被創(chuàng)建出來以后，可以通過多態(tài)性使得客戶端依賴于其抽象類型。正是由于這個(gè)問題，設(shè)計(jì)模式給出了多個(gè)創(chuàng)建模式，特別是幾個(gè)工廠模式，用于解決對(duì)象創(chuàng)建過程中的依賴倒轉(zhuǎn)問題。

工廠模式將創(chuàng)建一個(gè)類的實(shí)例的過程封裝起來，消費(fèi)這個(gè)實(shí)例的客戶端僅僅取得實(shí)例化的結(jié)果，以及這個(gè)實(shí)例的抽象類型。當(dāng)然，任何方法都無法回避Java語言所要求的new關(guān)鍵字和直接調(diào)用具體類的構(gòu)造子的做法（這違背了里氏代換原則）。簡單工廠模式將這個(gè)違反“開閉原則”和依賴倒轉(zhuǎn)原則的做法封裝到了一個(gè)類里面，而工廠方法模式將這個(gè)違反原則的做法推遲到了具體工廠角色中。通過適當(dāng)?shù)姆庋b，工廠模式可以凈化大部分的結(jié)構(gòu)，而將違反原則的做法孤立到易于控制的地方。

聯(lián)合使用Java接口和Java抽象類：聲明類型的工作由Java接口承擔(dān)，但是同時(shí)給出的還有一個(gè)Java抽象類，為這個(gè)接口給出一個(gè)缺省實(shí)現(xiàn)。如果一個(gè)具體類直接實(shí)現(xiàn)這個(gè)Java接口的話，它就必須自行實(shí)現(xiàn)所有的接口；相反，如果它繼承自抽象類的話，它就可以省去一些不必要的方法，因?yàn)樗梢詮某橄箢愔凶詣?dòng)得到這些方法的缺省實(shí)現(xiàn)。這其實(shí)就是缺省適配模式。

依賴倒轉(zhuǎn)的缺點(diǎn)：

1)因?yàn)橐蕾嚨罐D(zhuǎn)的緣故，對(duì)象的創(chuàng)建很可能要使用對(duì)象工廠，以避免對(duì)具體類的直接引用，此原則的使用還會(huì)導(dǎo)致大量的類。對(duì)不熟悉面向?qū)ο蠹夹g(shù)的工程師來說，維護(hù)這樣的系統(tǒng)需要較好地面向?qū)ο蟮脑O(shè)計(jì)知識(shí)。

2)依賴倒轉(zhuǎn)原則假定所有的具體類都是會(huì)變化的，這也不總是正確的。有一些具體類可能相當(dāng)穩(wěn)定、不會(huì)發(fā)生變化，消費(fèi)這個(gè)具體類實(shí)例的客戶端完全可以依賴這個(gè)具體類型，而不必為此發(fā)明一個(gè)抽象類型。

3.里氏代換原則

任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。

開閉原則的關(guān)鍵步驟是抽象化。而基類與子類的繼承關(guān)系就是抽象化的具體體現(xiàn)，里氏代換原則是對(duì)實(shí)現(xiàn)抽象化的具體步驟的規(guī)范。

4.合成/聚合復(fù)用原則

要盡量使用合成/聚合，而不是繼承關(guān)系達(dá)到復(fù)用的目的。

合成/聚合原則要求我們首先考慮合成/聚合關(guān)系，里氏代換原則要求在使用繼承時(shí)，必須確定這個(gè)繼承關(guān)系符合一定的條件（繼承是用來封裝變化的；任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。）

合成/聚合原則就是在一個(gè)新的對(duì)象里面使用一些已有的對(duì)象，使之成為新對(duì)象的一部分；新的對(duì)象通過向這些對(duì)象的委派達(dá)到得復(fù)用已有功能的目的。

5.迪米特原則

一個(gè)軟件實(shí)體應(yīng)當(dāng)盡可能少的其他實(shí)體發(fā)生相互作用。模塊之間的交互要少。這樣做的結(jié)果是當(dāng)系統(tǒng)的功能需要擴(kuò)展時(shí)，會(huì)相對(duì)更容易地做到對(duì)修改的關(guān)閉。

一個(gè)對(duì)象應(yīng)當(dāng)對(duì)其他對(duì)象有盡可能少的了解。

迪米特原則的具體操作：

1)優(yōu)先考慮將一個(gè)類設(shè)置成不變類。不變類易于設(shè)計(jì)、實(shí)現(xiàn)和使用。比如JavaAPI中的String，BigInteger等類。

一個(gè)對(duì)象與外界的通信大體上分成兩種，一種是改變這個(gè)對(duì)象的狀態(tài)，另一種是不改變這個(gè)對(duì)象的狀態(tài)的。如果一個(gè)對(duì)象的內(nèi)部狀態(tài)根本就是不可能改變的，那么它與外界的通信當(dāng)然就大大地減少。

當(dāng)涉及任何一個(gè)類的時(shí)候，都首先考慮這個(gè)類的狀態(tài)是否需要改變。即便一個(gè)類必須是可變類，在給它的屬性設(shè)置賦值方法的時(shí)候，也要保持吝嗇的態(tài)度。除非真的需要，否則不要為一個(gè)屬性設(shè)置賦值方法。

2)盡量降低一個(gè)類的訪問權(quán)限。

3)謹(jǐn)慎使用Serializable，一旦將一個(gè)類設(shè)置成Serializable，就不能再在新版本中修改這個(gè)類的內(nèi)部結(jié)構(gòu)，包括private的方法和句段。

4)盡量降低成員的訪問權(quán)限。

6.接口隔離原則

應(yīng)當(dāng)為客戶端提供盡可能小的單獨(dú)接口，而不要提供大的總接口。也即是使用多個(gè)專門的接口比使用單一的總接口要好。

接口隔離原則與迪米特都是對(duì)一個(gè)軟件實(shí)體與其他的軟件實(shí)體的通信限制。迪米特原則要求盡可能地限制通信的寬度和深度，接品隔離原則要求通信的寬度盡可能地窄。這樣做的結(jié)果使一個(gè)軟件系統(tǒng)在功能擴(kuò)展過程當(dāng)中，不會(huì)將修改的壓力傳遞到其他對(duì)象。

一個(gè)接口相當(dāng)于劇本中的一種角色，而此角色在一個(gè)舞臺(tái)上由哪一個(gè)演員來演則相當(dāng)于接口的實(shí)現(xiàn)。因此，一個(gè)接口應(yīng)當(dāng)簡單地代表一個(gè)角色，而不是多個(gè)角色。如果系統(tǒng)涉及到多個(gè)角色的話，那么每一個(gè)角色都應(yīng)當(dāng)由一個(gè)特定的接口代表。

定制服務(wù)：如果客戶端僅僅需要某一些方法的話，那么就應(yīng)當(dāng)向客戶端提供這些需要的方法，而不要提供不需要的方法。（向客戶端提供public接口是一種承諾，沒有必要做出不必要的承諾，過多的承諾會(huì)給系統(tǒng)的維護(hù)造成不必要的負(fù)擔(dān)。）

咨詢