第14章-原則和模式

1、第14章原則和模式為了有效地使用像UML這樣的設(shè)計(jì)表示法，只是掌握不同類型的語(yǔ)法和語(yǔ)義是不夠的。形式表示法的可用性并不能保證會(huì)很好地使用這些表示法，好的設(shè)計(jì)和不好的設(shè)計(jì)都可以用UML表達(dá)。當(dāng)然，好的設(shè)計(jì)和不好的設(shè)計(jì)之間的不同特征是很難用純粹的形式詞語(yǔ)描述的，很可能在任何完備程度上也不可能做到。推薦某些方法，保證設(shè)計(jì)師做出的設(shè)計(jì)一定是好的設(shè)計(jì)也非常困難。然而現(xiàn)在已經(jīng)有了面向?qū)ο蠼：驮O(shè)計(jì)的大量經(jīng)驗(yàn)，使我們可以更好地理解怎樣做可能會(huì)使設(shè)計(jì)成

2、功或不成功。面向?qū)ο笤O(shè)計(jì)師們積累的經(jīng)驗(yàn)可以分為兩個(gè)不同的范疇。一類是一些廣泛認(rèn)可的高級(jí)設(shè)計(jì)原則。這些原則描述了設(shè)計(jì)應(yīng)當(dāng)具有的或者應(yīng)當(dāng)避開(kāi)的值得注意的性質(zhì)。對(duì)于依據(jù)這些原則的基本原理所指出的設(shè)計(jì)特征建立的系統(tǒng)，經(jīng)驗(yàn)證實(shí)，可以預(yù)知其結(jié)果。這些高級(jí)原則是很重要的，但是對(duì)于試圖針對(duì)具體應(yīng)用建模的設(shè)計(jì)師，卻幾乎不能提供可操作的指導(dǎo)。針對(duì)這些情況，需要一些記實(shí)性地描述不同種類的設(shè)計(jì)知識(shí)，這些知識(shí)更關(guān)注特定的問(wèn)題和解決這些問(wèn)題的策略。當(dāng)前在設(shè)計(jì)模式方

3、面的工作就是通過(guò)識(shí)別共同的建模問(wèn)題，并對(duì)這些問(wèn)題提供經(jīng)過(guò)驗(yàn)證的解決方案的方式，滿足這種需要。本章將討論若干已知的廣泛接受的面向?qū)ο笤O(shè)計(jì)的原則，然后介紹設(shè)計(jì)模式的概念。模式的用法將通過(guò)考慮對(duì)本書(shū)前面章節(jié)中出現(xiàn)的程序的修改予以介紹。14.1開(kāi)閉原則開(kāi)（放）（封）閉原則是BertrMeyer1988年在他的有影響的著作《面向?qū)ο蟮能浖?gòu)造》中闡述的。這個(gè)原則關(guān)注的是系統(tǒng)內(nèi)部改變的影響，特別是最大限度地使模塊免受它所使用的其它模塊改變的影響的辦

4、法?？紤]系統(tǒng)中一個(gè)模塊使用另一個(gè)模塊提供的服務(wù)的情況。通常稱前一個(gè)模塊為客戶（client），后一個(gè)模塊為供應(yīng)者（supplier）。雖然這兩個(gè)概念有更廣泛的使用，本章詳細(xì)考慮的只是用于類之間的關(guān)系，即可以用UML的使用依賴建模的關(guān)系。圖14.1表示了這種情況。訪問(wèn)級(jí)在UML中也稱為可見(jiàn)性，它指明了客戶可以看到一個(gè)類的哪些特征。圖14.2中供應(yīng)者類中的操作聲明為公有的因此客戶可以看到，而屬性是私有的因而是不可見(jiàn)的。從客戶的視角看，類的接

5、口是僅有的可見(jiàn)的特征。如果可見(jiàn)的接口保持不變，不可見(jiàn)的特征可以改變、去掉或增加，都不會(huì)對(duì)客戶產(chǎn)生影響。例如，在Java中，圖14.2中的供應(yīng)者類可以如下實(shí)現(xiàn)。這個(gè)類中公有方法的實(shí)現(xiàn)可以改變而不會(huì)對(duì)客戶類有任何影響，類似地，支持該類的方法實(shí)現(xiàn)所需要的私有域也可以增加或去掉。為了避免影響客戶，必須保持不變的只是由該類公有方法的名稱和特征標(biāo)記（signature）組成的可見(jiàn)接口。然而實(shí)現(xiàn)開(kāi)閉原則的這種方式有許多局限。從根本上講，由于系統(tǒng)的修改

6、要求改變客戶類的代碼，客戶模塊在技術(shù)上是不可能關(guān)閉的。如果更實(shí)質(zhì)的目標(biāo)可以達(dá)到，這種改變可以作為字面上的違反來(lái)看待，而不是違背了開(kāi)閉原則的精神實(shí)質(zhì)，但是數(shù)據(jù)抽象方式還存在另外的更本質(zhì)的問(wèn)題。首先，雖然在Java中私有域可以被增加到類中而不會(huì)影響客戶，但并不是所有程序設(shè)計(jì)環(huán)境都是如此。例如，在C中類的定義典型地是由頭文件和實(shí)現(xiàn)文件分擔(dān)的，頭文件實(shí)際上是被合并到客戶模塊中去的。這樣，對(duì)頭文件的任何改變，例如，增加一個(gè)新的域，就需要重新編譯客

7、戶模塊，即使這種改變對(duì)客戶模塊是不可見(jiàn)的。如果開(kāi)閉原則的實(shí)現(xiàn)可以做到獨(dú)立于語(yǔ)言，是更可取的。其次，在數(shù)據(jù)抽象方式中，客戶模塊所需要的接口仍處在隱含的狀態(tài)?？蛻艨赡苁褂霉?yīng)者提供給他的可見(jiàn)到的所有特征，但也可能并不需要。實(shí)際上一個(gè)模塊的不同客戶或許使用的只是一個(gè)模塊可見(jiàn)接口的不同子集。這就很難準(zhǔn)確地知道，對(duì)一個(gè)模塊的哪些改變會(huì)影響給定的客戶。通過(guò)將客戶模塊所需要的接口用文檔明確地加以描述，將會(huì)改進(jìn)文檔的編制和可維護(hù)性。1412抽象接口類抽