作者： Cherami 1.1 設(shè)計(jì)正在“腐爛”的征兆（Symptoms of Rotting Design） 有四個(gè)主要的征兆告訴我們?cè)撥浖O(shè)計(jì)正在“腐爛”中。它們并不是互相獨(dú)立的，而是互相關(guān)聯(lián)，它們是過(guò)于僵硬、過(guò)于脆弱、不可重用性和粘滯性過(guò)高。 1. 過(guò)于僵硬Rigidity Rigidity 致使軟件難以更改，每一個(gè)改動(dòng)都會(huì)造成一連串的互相依靠的模塊的改動(dòng)，項(xiàng)目經(jīng)理不敢改動(dòng)，因?yàn)樗肋h(yuǎn)也不知道一個(gè)改動(dòng)何時(shí)才能完成。 2. 過(guò)于脆弱Fragility Fragility 致使當(dāng)軟件改動(dòng)時(shí)，系統(tǒng)會(huì)在許多地方出錯(cuò)。并且錯(cuò)誤經(jīng)常會(huì)發(fā)生在概念上與改動(dòng)的地方?jīng)]有聯(lián)系的模塊中。這樣的軟件無(wú)法維護(hù)，每一次維護(hù)都使軟件變得更加難以維護(hù)。（惡性循環(huán)） 3. 不可重用性immobility immobility 致使我們不能重用在其它項(xiàng)目中、或本項(xiàng)目中其它位置中的軟件。工程師發(fā)現(xiàn)將他想重用的部分分離出來(lái)的工作量和風(fēng)險(xiǎn)太大，足以抵消他重用的積極性，因此軟件用重寫(xiě)代替了重用。 4. 粘滯性過(guò)高viscosity viscosity有兩種形式：設(shè)計(jì)的viscosity和環(huán)境的viscosity.當(dāng)需要進(jìn)行改動(dòng)時(shí)，工程師通常發(fā)現(xiàn)有不止一個(gè)方法可以達(dá)到目的。但是這些方法中，一些會(huì)保留原有的設(shè)計(jì)不變，而另外一些則不會(huì)（也就是說(shuō)，這些人是hacks）。一個(gè)設(shè)計(jì)假如使工程師作錯(cuò)比作對(duì)輕易得多，那么這個(gè)設(shè)計(jì)的viscosity 就會(huì)很高。 環(huán)境的viscosity高是指開(kāi)發(fā)環(huán)境速度很慢且效率很低。 2 面向?qū)ο蟮念愒O(shè)計(jì)原則2.1 開(kāi)放關(guān)閉原則The Open Closed PRinciple （OCP） A module should be open for extension but closed for modification.一個(gè)模塊應(yīng)該只在擴(kuò)展的時(shí)候被打開(kāi)（暴露模塊內(nèi)部），在修改的時(shí)候是關(guān)閉的（模塊是黑盒子）。 在所有的面向?qū)ο笤O(shè)計(jì)原則中，這一條最重要。該原則是說(shuō)：我們應(yīng)該能夠不用修改模塊的源代碼，就能更改模塊的行為。 2.1.1 動(dòng)態(tài)多態(tài)性（Dynamic Polymorphism） 2.1.2 靜態(tài)多態(tài)性（Static Polymorphism） 另外一種使用OCP的技術(shù)就是使用模板或范型，如Listing 2-3.LogOn函數(shù)不用修改代碼就可以擴(kuò)展出多種類型的modem. 2.1.3 OCP的體系結(jié)構(gòu)目標(biāo)（Architectural Goals of the OCP） 通過(guò)遵照OCP應(yīng)用這些技術(shù)，我們能創(chuàng)建不用更改內(nèi)部代碼就可以被擴(kuò)展的模塊。這就是說(shuō)，在將來(lái)我們給模塊增添新功能是，只要增加新的代碼，而不用更改原先的代碼。 第 3 頁(yè)，共 17 頁(yè)使軟件完全符合OCP可能是很難的，但即使只是部分符合OCP，整個(gè)軟件的結(jié)構(gòu)性能也會(huì)有很大的提高。我們應(yīng)該記住，讓變化不要波及已經(jīng)正常工作的代碼總是好的。 2.2 Liskov 替換原則The Liskov Substitution Principle（LSP） Subclasses should be substitutable for their base classes.子類應(yīng)該可以替換其基類。 如下圖2-14所示。Derived類應(yīng)該能替換其Base類。也就是說(shuō)，Base基類的一個(gè)用戶User假如被傳遞給一個(gè)Devrived類而不是Base類作為參數(shù)，也能正常的工作。 2.3 依靠性倒置原則The Dependency Inversion Principle （DIP）1 Depend upon Abstractions. Do not depend upon concretions.依靠抽象，不要依靠具體。 假如說(shuō)OCP聲明了OO體系結(jié)構(gòu)的目的，DIP則闡述了其主要機(jī)制。依靠性倒置的策略就是要依靠接口、或抽象函數(shù)、或抽象類，而不是依靠于具體的函數(shù)和類。這條原則就是支持組件設(shè)計(jì)、COM、CORBA、EJB等等的背后力量。 2.3.1 依靠抽象Depending upon Abstractions. 實(shí)現(xiàn)該原則十分簡(jiǎn)單。設(shè)計(jì)中的每一個(gè)依靠都應(yīng)該是接口、抽象類，不要依靠任何一個(gè)具體類。 顯然這樣的限制比較嚴(yán)重，但是我們應(yīng)該盡可能的遵守這條原則。原因很簡(jiǎn)單，具體的模塊變化太多，抽象的則變化少得多。而且，抽象是“鉸鏈”點(diǎn)，在這些位置，設(shè)計(jì)可以彎曲或者擴(kuò)展，而不用進(jìn)行更改（OCP）。 2.4 接口隔離原則The Interface Segregation Principle （ISP） ‘Many client specific interfaces are better than one general purpose interface多個(gè)和客戶相關(guān)的接口要好于一個(gè)通用接口。 ISP是另一條在底層支持組件如COM技術(shù)的原則。沒(méi)有它，組件和類的易用性和重用性都會(huì)大打折扣。該原則的實(shí)質(zhì)很簡(jiǎn)單：假如一個(gè)類有幾個(gè)使用者，與其讓這個(gè)類載入所有使用者需要使用的所有方法，還不如為每一個(gè)使用者創(chuàng)建一個(gè)特定的接口，并讓該類分別實(shí)現(xiàn)這些接口。 3 包體系結(jié)構(gòu)的原則Principles of Package Architecture 類是必不可少的，但對(duì)于組織一個(gè)設(shè)計(jì)來(lái)說(shuō)還不夠，粒度更大的包有助于此。但是我們應(yīng)該怎樣協(xié)調(diào)類和包之間的從屬關(guān)系？下面的三條原則都屬于包聚合原則，能對(duì)我們有所幫助。 3.1 包聚合原則 3.1.1 發(fā)布重用等價(jià)原則The Release Reuse Equivalency Principle （REP）1 重用的粒度就是發(fā)布的粒度。The granule of reuse is the granule of release.一個(gè)可重用的元件（組件、一個(gè)類、一組類等），只有在它們被某種發(fā)布（Release）系統(tǒng)治理以后，才能被重用。用戶不愿意使用那些每次改動(dòng)以后都要被強(qiáng)迫升級(jí)的元件。因此，即使開(kāi)發(fā)者發(fā)布了可重用元件的新版本，他也必須支持和維護(hù)舊版本，這樣才有時(shí)間讓用戶熟悉新版本。 因此，將什么類放在一個(gè)包中的判定標(biāo)準(zhǔn)之一就是重用，并且因?yàn)榘前l(fā)布的最小單元，它們同樣也是重用的最小單元。體系結(jié)構(gòu)師應(yīng)該將可重用的類都放在包中。 3.1.2 共同封閉原則The Common Closure Principle （CCP）2 一起變化的類放在一起。Classes that change together， belong together.一個(gè)大的開(kāi)發(fā)項(xiàng)目通常分割成很多網(wǎng)狀互聯(lián)的包。治理、測(cè)試和發(fā)布這些包的工作可不是微不足道的工作。在任何一個(gè)發(fā)布的版本中，假如改動(dòng)的包數(shù)量越多，重建、測(cè)試和部署也就會(huì)越多。因此我們應(yīng)該盡量減少在產(chǎn)品的發(fā)布周期中被改動(dòng)的包的數(shù)量，這就要求我們將一起變化的類放在一起（同一個(gè)包）。 3.1.3 共同重用原則The Common Reuse Principle （CRP）3 不一起重用的類不應(yīng)該放在一起。Classes that aren‘t reused together should not be grouped together.對(duì)一個(gè)包的依靠就是對(duì)包里面所有東西的依靠。當(dāng)一個(gè)包改變時(shí)，這個(gè)包的所有使用者都必須驗(yàn)證是否還能正常運(yùn)行，即使它們所用到的沒(méi)有任何改變也不行。 比如我們就經(jīng)常碰到操作系統(tǒng)需要升級(jí)。當(dāng)開(kāi)發(fā)商發(fā)布一個(gè)新版本以后，我們的升級(jí)是遲早的問(wèn)題，因?yàn)殚_(kāi)發(fā)商將會(huì)不支持舊版本，即使我們對(duì)新版本沒(méi)有任何愛(ài)好，我們也得升級(jí)。 假如把不一起使用的類放在一起，同樣的事情我們也會(huì)碰到。一個(gè)和我們無(wú)關(guān)的類的改變也產(chǎn)生包的一個(gè)新版本，我們被強(qiáng)迫升級(jí)和驗(yàn)證這個(gè)包是否影響正常的運(yùn)行。 3.1.4 包聚合原則之間的張力Tension between the Package Cohesion Principles 這三條原則實(shí)際上是互斥的。它們不能被同時(shí)滿足，因?yàn)槊恳粭l原則都只針對(duì)某一方面，只對(duì)某一部分人有好處。REP和CRP都想重用元件的人有好處，CCP對(duì)維護(hù)人員有好處。CCP使得包有盡可能大的趨勢(shì)（究竟，假如所有的類都屬于一個(gè)包，那么將只會(huì)有一個(gè)包變化）；CRP盡量使得包更小。 幸運(yùn)的是，包并不是一成不變的。實(shí)際上，在開(kāi)發(fā)過(guò)程中，包的轉(zhuǎn)義和增刪都是很正常的。在項(xiàng)目開(kāi)發(fā)的早期，軟件建筑師建立包的結(jié)構(gòu)體系，此時(shí)CCP占主導(dǎo)地位，維護(hù)只是輔助。在體系結(jié)構(gòu)穩(wěn)定以后，軟件建筑師會(huì)對(duì)包結(jié)構(gòu)進(jìn)行重構(gòu)，此時(shí)盡可能的運(yùn)用REP和CRP，從而最大的方便重用元件的人員。 3.2 包耦合原則The Package Coupling Principles. 下面三條原則主要關(guān)心包之間的關(guān)系。 3.2.1 無(wú)依靠回路原則The Acyclic Dependencies Principle （ADP）1 包與包之間的依靠不能形成回路。The dependencies between packages must not form cycles.因?yàn)榘前l(fā)布的粒度。人們傾向于節(jié)省人力資源，所以工程師們通常只編寫(xiě)一個(gè)包而不是十幾個(gè)包。這種傾向由于包聚合原則被放大，后來(lái)人們就將相關(guān)的類組成一組。 因此，工程師發(fā)現(xiàn)他們只會(huì)改動(dòng)較少的幾個(gè)包，一旦這些改動(dòng)完成，他們就可以發(fā)布他們改動(dòng)的包。但是在發(fā)布前，他們必須進(jìn)行測(cè)試。為了測(cè)試，他們必須編譯和連編他們的包所依靠的所有的包。 3.2.2 依靠穩(wěn)定原則（Stable Dependencies Principle，SDP） 朝穩(wěn)定的方向依靠Depend in the direction of stability.雖然這條原則看起來(lái)很明顯，但是關(guān)于這方面還是有很多需要說(shuō)明的地方，穩(wěn)定性并不一定為大家所了解。 穩(wěn)定性是什么？站在一個(gè)硬幣上，這穩(wěn)定嗎？很可能你說(shuō)不。然而，除非被打攪，硬幣將保持那個(gè)位置很長(zhǎng)時(shí)間。硬幣沒(méi)有變化，但是很難認(rèn)為它是穩(wěn)定的。穩(wěn)定性與需要改動(dòng)所要做的工作量相關(guān)。硬幣不穩(wěn)定是因?yàn)橹恍枰苄〉墓ぷ髁烤湍馨阉^(guò)來(lái)。換個(gè)角度，桌子就要穩(wěn)定得多。 對(duì)于軟件這說(shuō)明什么？一個(gè)軟件包很難被改動(dòng)受很多因素影響：代碼大小、復(fù)雜度、透明度等等。這些我們先不說(shuō)，可以肯定的一點(diǎn)是，假如有很多其它的包依靠于一個(gè)軟件包，那么該軟件包就難以改動(dòng)。一個(gè)包假如被許多其它包依靠，那么該包是很穩(wěn)定的，因?yàn)檫@個(gè)包的任何一個(gè)改動(dòng)都可能需要改動(dòng)很多其它的包。 3.2.3 穩(wěn)定抽象原則（ Stable Abstractions Principle ，SAP） 穩(wěn)定的包應(yīng)該是抽象包。Stable packages should be abstract packages.我們可以想象應(yīng)用程序的包結(jié)構(gòu)應(yīng)該是一個(gè)互相聯(lián)系的包的集合，其中不穩(wěn)定的包在頂端，穩(wěn)定的包在底部，所有的依靠方向朝下。那些頂端的包是不穩(wěn)定而且靈活的，但那些底部的包就很難改動(dòng)。這就導(dǎo)致一個(gè)兩難局面：我們想要將包設(shè)計(jì)為難以改動(dòng)的嗎？ 明顯地，難以改動(dòng)的包越多，我們整個(gè)軟件設(shè)計(jì)的靈活性就越差。但是似乎有一點(diǎn)希望解決這個(gè)問(wèn)題，位于依靠網(wǎng)絡(luò)最底部的高穩(wěn)定性的包的確難以改動(dòng)，但是假如遵從OCP，這樣的包并不難以擴(kuò)展。進(jìn)入討論組討論。
