OO設(shè)計(jì)模式和設(shè)計(jì)原則(轉(zhuǎn)帖)

很好的文章，下面是摘錄，請(qǐng)直接下載原文閱讀。

1.1 設(shè)計(jì)正在“腐爛”的征兆（Symptoms of Rotting Design）
有四個(gè)主要的征兆告訴我們?cè)撥浖O(shè)計(jì)正在“腐爛”中。它們并不是互相獨(dú)立的，而是互相關(guān)聯(lián)，它們是過于僵硬、過于脆弱、不可重用性和粘滯性過高。
1. 過于僵硬Rigidity
Rigidity 致使軟件難以更改，每一個(gè)改動(dòng)都會(huì)造成一連串的互相依靠的模塊的改動(dòng)，項(xiàng)目經(jīng)理不敢改動(dòng)，因?yàn)樗肋h(yuǎn)也不知道一個(gè)改動(dòng)何時(shí)才能完成。
2. 過于脆弱Fragility
Fragility 致使當(dāng)軟件改動(dòng)時(shí)，系統(tǒng)會(huì)在許多地方出錯(cuò)。并且錯(cuò)誤經(jīng)常會(huì)發(fā)生在概念上與改動(dòng)的地方?jīng)]有聯(lián)系的模塊中。這樣的軟件無法維護(hù)，每一次維護(hù)都使軟件變得更加難以維護(hù)。（惡性循環(huán)）
3. 不可重用性immobility
immobility 致使我們不能重用在其它項(xiàng)目中、或本項(xiàng)目中其它位置中的軟件。工程師發(fā)現(xiàn)將他想重用的部分分離出來的工作量和風(fēng)險(xiǎn)太大，足以抵消他重用的積極性，因此軟件用重寫代替了重用。
4. 粘滯性過高viscosity
viscosity有兩種形式：設(shè)計(jì)的viscosity和環(huán)境的viscosity。
當(dāng)需要進(jìn)行改動(dòng)時(shí)，工程師通常發(fā)現(xiàn)有不止一個(gè)方法可以達(dá)到目的。但是這些方法中，一些會(huì)保留原有的設(shè)計(jì)不變，而另外一些則不會(huì)（也就是說，這些人是hacks）。一個(gè)設(shè)計(jì)如果使工程師作錯(cuò)比作對(duì)容易得多，那么這個(gè)設(shè)計(jì)的viscosity 就會(huì)很高。
環(huán)境的viscosity高是指開發(fā)環(huán)境速度很慢且效率很低。

2 面向?qū)ο蟮念愒O(shè)計(jì)原則
2.1 開放關(guān)閉原則The Open Closed Principle (OCP)
A module should be open for extension but closed for modification.一個(gè)模塊應(yīng)該只在擴(kuò)展的時(shí)候被打開（暴露模塊內(nèi)部），在修改的時(shí)候是關(guān)閉的（模塊是黑盒子）。
在所有的面向?qū)ο笤O(shè)計(jì)原則中，這一條最重要。該原則是說：我們應(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）
通過遵照OCP應(yīng)用這些技術(shù)，我們能創(chuàng)建不用更改內(nèi)部代碼就可以被擴(kuò)展的模塊。這就是說，在將來我們給模塊增添新功能是，只要增加新的代碼，而不用更改原先的代碼。 第 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類。也就是說，Base基類的一個(gè)用戶User如果被傳遞給一個(gè)Devrived類而不是Base類作為參數(shù)，也能正常的工作。
2.3 依賴性倒置原則The Dependency Inversion Principle (DIP)1
Depend upon Abstractions. Do not depend upon concretions.依賴抽象，不要依賴具體。
如果說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ù)的原則。沒有它，組件和類的易用性和重用性都會(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ì)來說還不夠，粒度更大的包有助于此。但是我們應(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í)的元件。因此，即使開發(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è)大的開發(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)行，即使它們所用到的沒有任何改變也不行。
比如我們就經(jīng)常遇到操作系統(tǒng)需要升級(jí)。當(dāng)開發(fā)商發(fā)布一個(gè)新版本以后，我們的升級(jí)是遲早的問題，因?yàn)殚_發(fā)商將會(huì)不支持舊版本，即使我們對(duì)新版本沒有任何興趣，我們也得升級(jí)。
如果把不一起使用的類放在一起，同樣的事情我們也會(huì)遇到。一個(gè)和我們無關(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í)際上，在開發(fā)過程中，包的轉(zhuǎn)義和增刪都是很正常的。在項(xiàng)目開發(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 無依賴回路原則The Acyclic Dependencies Principle (ADP)1
包與包之間的依賴不能形成回路。The dependencies between packages must not form cycles.
因?yàn)榘前l(fā)布的粒度。人們傾向于節(jié)省人力資源，所以工程師們通常只編寫一個(gè)包而不是十幾個(gè)包。這種傾向由于包聚合原則被放大，后來人們就將相關(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.
雖然這條原則看起來很明顯，但是關(guān)于這方面還是有很多需要說明的地方，穩(wěn)定性并不一定為大家所了解。
穩(wěn)定性是什么？站在一個(gè)硬幣上，這穩(wěn)定嗎？很可能你說不。然而，除非被打擾，硬幣將保持那個(gè)位置很長(zhǎng)時(shí)間。硬幣沒有變化，但是很難認(rèn)為它是穩(wěn)定的。穩(wěn)定性與需要改動(dòng)所要做的工作量相關(guān)。硬幣不穩(wěn)定是因?yàn)橹恍枰苄〉墓ぷ髁烤湍馨阉^來。換個(gè)角度，桌子就要穩(wěn)定得多。
對(duì)于軟件這說明什么？一個(gè)軟件包很難被改動(dòng)受很多因素影響：代碼大小、復(fù)雜度、透明度等等。這些我們先不說，可以肯定的一點(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ǎng)絡(luò)最底部的高穩(wěn)定性的包的確難以改動(dòng)，但是如果遵從OCP，這樣的包并不難以擴(kuò)展。

完整版下載

日志評(píng)價(jià)

(3個(gè)投票，平均值： 4，最大值：5) －－點(diǎn)擊星星直接投票