第14章-原則和模式

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

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

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

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

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

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

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