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

1.開(kāi)閉原則

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

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

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

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

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

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

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

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

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

開(kāi)閉原則是總的原則，其它幾條是開(kāi)閉原則的手段和工具。

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

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

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

抽象層次包含的是應(yīng)用系統(tǒng)的商務(wù)邏輯和宏觀的、對(duì)整個(gè)系統(tǒng)來(lái)說(shuō)重要的戰(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è)抽象類(lèi)型的話，應(yīng)當(dāng)使用這個(gè)抽象類(lèi)型作為變量的靜態(tài)類(lèi)型。這就是針對(duì)接口編程的含義。

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

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

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

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

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

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

3.里氏代換原則

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

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

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

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

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

合成/聚合原則就是在一個(gè)新的對(duì)象里面使用一些已有的對(duì)象，使之成為新對(duì)象的一部分；新的對(duì)象通過(guò)向這些對(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è)類(lèi)設(shè)置成不變類(lèi)。不變類(lèi)易于設(shè)計(jì)、實(shí)現(xiàn)和使用。比如JavaAPI中的String，BigInteger等類(lèi)。

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

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

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

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

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

6.接口隔離原則

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

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

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

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