南通科迅教育培訓(xùn)中心
軟件開發(fā)設(shè)計根本的指導(dǎo)原則
所有的設(shè)計模式都是對不同的可變性的封裝，從而使系統(tǒng)在不同角度達(dá)到“開閉原則”的要求。
在軟件軟件系統(tǒng)中，一個模塊設(shè)計得好不好的最主要、最重要的標(biāo)志，就是該模塊在多大程度上將自己的內(nèi)部數(shù)據(jù)和其他與實現(xiàn)有關(guān)的細(xì)節(jié)隱藏起來。一個設(shè)計得好的模塊可以將它所有的實現(xiàn)細(xì)節(jié)隱藏起來，徹底地將提供給外界的API和自己的實現(xiàn)分隔開來。這樣一來，模塊與模塊之間就可以僅僅通過彼此的API相互通信，而不理會模塊內(nèi)部的工作細(xì)節(jié)。
設(shè)計根本的指導(dǎo)原則是提高可維護(hù)性和可復(fù)用性。這些原則主要有：
1. 開閉原則
一個軟件實體應(yīng)該對擴(kuò)展開放，對修改關(guān)閉。
在設(shè)計一個模塊的時候，就當(dāng)使這個模塊可以在不被修改的前提下被擴(kuò)展。換言之，就當(dāng)可以在不必修改源代碼的情況下改變這個模塊的行為。
如何做到既不修改，又可以擴(kuò)展？
解決問題的關(guān)鍵在于抽象化：在Java語言里，可以給出一個或多個抽象Java類或Java接口，規(guī)定出所有的具體類必須提供的方法特征作為系統(tǒng)設(shè)計的抽象層。這個抽象層預(yù)見了所有的可能擴(kuò)展，因此，在任何擴(kuò)展情況下都不會改變。這就使得系統(tǒng)的抽象層不需要修改，從而滿足了—對修改關(guān)閉。
同時，由于從抽象層導(dǎo)出一個或多個新的具體類可以改變系統(tǒng)的行為，因此系統(tǒng)的設(shè)計對擴(kuò)展是開放的。
開閉原則實際上是對“對可變性的封閉原則“：找到一個系統(tǒng)的可變因素，將之封裝起來。這個原則意昧著兩點：
1) 一個可變性不應(yīng)當(dāng)散落在代碼的很多角落里，而應(yīng)當(dāng)被封裝到一個對象里面。同一種可變性的不同表象意昧著同一個繼承等級結(jié)構(gòu)中的具體子類。
繼承就當(dāng)被看作是封裝變化的方法，而不應(yīng)當(dāng)被認(rèn)為是從一般的對象生成特殊對象的方法。
2) 一種可變性不應(yīng)當(dāng)與另一種可變性混合在一起。（所有類圖的繼承結(jié)構(gòu)一般不會超過兩層，不然就意昧著將兩種不同的可變性混合在了一起。）
開閉原則是總的原則，其它幾條是開閉原則的手段和工具。
2. 依賴倒轉(zhuǎn)原則
依賴倒轉(zhuǎn)原則講的是：要依賴于抽象，不要信賴于實現(xiàn)。
開閉原則是目標(biāo)，而達(dá)到這一目標(biāo)的手段是依賴倒轉(zhuǎn)原則。
抽象層次包含的是應(yīng)用系統(tǒng)的商務(wù)邏輯和宏觀的、對整個系統(tǒng)來說重要的戰(zhàn)略性決定，是必然性的體現(xiàn)；而具體層次則含有一些次要的與實現(xiàn)有關(guān)的算法和邏輯，以及戰(zhàn)術(shù)性的決定，帶有相當(dāng)大的偶然性選擇。具體層次的代碼是會經(jīng)常有變動的，不能避免出現(xiàn)錯誤。
抽象層次含有一個應(yīng)用系統(tǒng)最重要的宏觀商務(wù)邏輯，是做戰(zhàn)略判斷和決定的地方，那么抽象層次就應(yīng)當(dāng)是較為穩(wěn)定的，應(yīng)當(dāng)是復(fù)用的重點；也應(yīng)當(dāng)是維護(hù)的重點。
在很多情況下，一個Java程序需要引用一個對象。這個時候，如果這個對象有一個抽象類型的話，應(yīng)當(dāng)使用這個抽象類型作為變量的靜態(tài)類型。這就是針對接口編程的含義。
一般而言，在創(chuàng)建一個對象時，Java語言要求使用new關(guān)鍵詞以及這個類本身。而一旦這個對象已經(jīng)被創(chuàng)建出來，那么就可以靈活地使用這個對象的抽象類型來引用它。比如：List employees = new Vector()；因此，Java語言中創(chuàng)建一個對象的過程是違背“開閉原則”以及依賴倒轉(zhuǎn)原則的（因為先生成了具體的類型，再使用抽象的引用），雖然在這個類被創(chuàng)建出來以后，可以通過多態(tài)性使得客戶端依賴于其抽象類型。正是由于這個問題，設(shè)計模式給出了多個創(chuàng)建模式，特別是幾個工廠模式，用于解決對象創(chuàng)建過程中的依賴倒轉(zhuǎn)問題。
工廠模式將創(chuàng)建一個類的實例的過程封裝起來，消費(fèi)這個實例的客戶端僅僅取得實例化的結(jié)果，以及這個實例的抽象類型。當(dāng)然，任何方法都無法回避Java語言所要求的new關(guān)鍵字和直接調(diào)用具體類的構(gòu)造子的做法（這違背了里氏代換原則）。簡單工廠模式將這個違反“開閉原則”和依賴倒轉(zhuǎn)原則的做法封裝到了一個類里面，而工廠方法模式將這個違反原則的做法推遲到了具體工廠角色中。通過適當(dāng)?shù)姆庋b，工廠模式可以凈化大部分的結(jié)構(gòu)，而將違反原則的做法孤立到易于控制的地方。
聯(lián)合使用Java接口和Java抽象類：聲明類型的工作由Java接口承擔(dān)，但是同時給出的還有一個Java抽象類，為這個接口給出一個缺省實現(xiàn)。如果一個具體類直接實現(xiàn)這個Java接口的話，它就必須自行實現(xiàn)所有的接口；相反，如果它繼承自抽象類的話，它就可以省去一些不必要的方法，因為它可以從抽象類中自動得到這些方法的缺省實現(xiàn)。這其實就是缺省適配模式。
依賴倒轉(zhuǎn)的缺點：
1) 因為依賴倒轉(zhuǎn)的緣故，對象的創(chuàng)建很可能要使用對象工廠，以避免對具體類的直接引用，此原則的使用還會導(dǎo)致大量的類。對不熟悉面向?qū)ο蠹夹g(shù)的工程師來說，維護(hù)這樣的系統(tǒng)需要較好地面向?qū)ο蟮脑O(shè)計知識。
2) 依賴倒轉(zhuǎn)原則假定所有的具體類都是會變化的，這也不總是正確的。有一些具體類可能相當(dāng)穩(wěn)定、不會發(fā)生變化，消費(fèi)這個具體類實例的客戶端完全可以依賴這個具體類型，而不必為此發(fā)明一個抽象類型。
3. 里氏代換原則
任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。
開閉原則的關(guān)鍵步驟是抽象化。而基類與子類的繼承關(guān)系就是抽象化的具體體現(xiàn)，里氏代換原則是對實現(xiàn)抽象化的具體步驟的規(guī)范。
4. 合成/聚合復(fù)用原則
要盡量使用合成/聚合，而不是繼承關(guān)系達(dá)到復(fù)用的目的。
合成/聚合原則要求我們首先考慮合成/聚合關(guān)系，里氏代換原則要求在使用繼承時，必須確定這個繼承關(guān)系符合一定的條件（繼承是用來封裝變化的；任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。）
合成/聚合原則就是在一個新的對象里面使用一些已有的對象，使之成為新對象的一部分；新的對象通過向這些對象的委派達(dá)到得復(fù)用已有功能的目的。
5. 迪米特原則
一個軟件實體應(yīng)當(dāng)盡可能少的其他實體發(fā)生相互作用。模塊之間的交互要少。這樣做的結(jié)果是當(dāng)系統(tǒng)的功能需要擴(kuò)展時，會相對更容易地做到對修改的關(guān)閉。
一個對象應(yīng)當(dāng)對其他對象有盡可能少的了解。
迪米特原則的具體操作：
1) 優(yōu)先考慮將一個類設(shè)置成不變類。不變類易于設(shè)計、實現(xiàn)和使用。比如Java API中的String，BigInteger等類。
一個對象與外界的通信大體上分成兩種，一種是改變這個對象的狀態(tài)，另一種是不改變這個對象的狀態(tài)的。如果一個對象的內(nèi)部狀態(tài)根本就是不可能改變的，那么它與外界的通信當(dāng)然就大大地減少。
當(dāng)涉及任何一個類的時候，都首先考慮這個類的狀態(tài)是否需要改變。即便一個類必須是可變類，在給它的屬性設(shè)置賦值方法的時候，也要保持吝嗇的態(tài)度。除非真的需要，否則不要為一個屬性設(shè)置賦值方法。
2) 盡量降低一個類的訪問權(quán)限。
3) 謹(jǐn)慎使用Serializable，一旦將一個類設(shè)置成Serializable，就不能再在新版本中修改這個類的內(nèi)部結(jié)構(gòu)，包括private的方法和句段。
4) 盡量降低成員的訪問權(quán)限。
6. 接口隔離原則
應(yīng)當(dāng)為客戶端提供盡可能小的單獨(dú)接口，而不要提供大的總接口。也即是使用多個專門的接口比使用單一的總接口要好。
接口隔離原則與迪米特都是對一個軟件實體與其他的軟件實體的通信限制。迪米特原則要求盡可能地限制通信的寬度和深度，接品隔離原則要求通信的寬度盡可能地窄。這樣做的結(jié)果使一個軟件系統(tǒng)在功能擴(kuò)展過程當(dāng)中，不會將修改的壓力傳遞到其他對象。
一個接口相當(dāng)于劇本中的一種角色，而此角色在一個舞臺上由哪一個演員來演則相當(dāng)于接口的實現(xiàn)。因此，一個接口應(yīng)當(dāng)簡單地代表一個角色，而不是多個角色。如果系統(tǒng)涉及到多個角色的話，那么每一個角色都應(yīng)當(dāng)由一個特定的接口代表。
定制服務(wù)：如果客戶端僅僅需要某一些方法的話，那么就應(yīng)當(dāng)向客戶端提供這些需要的方法，而不要提供不需要的方法。（向客戶端提供public接口是一種承諾，沒有必要做出不必要的承諾，過多的承諾會給系統(tǒng)的維護(hù)造成不必要的負(fù)擔(dān)。）
