四大UML類設(shè)計原則詳盡解讀

作者：Gost382811918 2010-07-09 14:51:13

UML類設(shè)計原則你是否熟悉，現(xiàn)在不少OO先驅(qū)提出了很多有關(guān)面向?qū)ο蟮脑O(shè)計原則用于指導(dǎo)OO的設(shè)計和開發(fā)。本文就向大家介紹一下與UML類設(shè)計相關(guān)的幾條原則。

本文和大家重點(diǎn)討論一下UML類設(shè)計原則，主要包括開閉原則，替換原則，依賴原則和接口分離原則四種，希望通過本文的學(xué)習(xí)你對UML類設(shè)計原則有全面的認(rèn)識。

面向?qū)ο蟮脑O(shè)計原則－UML類設(shè)計原則

在面向?qū)ο笤O(shè)計中，如何通過很小的設(shè)計改變就可以應(yīng)對設(shè)計需求的變化，這是令設(shè)計者極為關(guān)注的問題。為此不少OO先驅(qū)提出了很多有關(guān)面向?qū)ο蟮脑O(shè)計原則用于指導(dǎo)OO的設(shè)計和開發(fā)。下面是幾條與類設(shè)計相關(guān)的設(shè)計原則。

1.開閉原則（theOpenClosedPrincipleOCP）

UML類設(shè)計原則中開閉原則是指一個模塊在擴(kuò)展性方面應(yīng)該是開放的而在更改性方面應(yīng)該是封閉的。因此在進(jìn)行面向?qū)ο笤O(shè)計時要盡量考慮接口封裝機(jī)制、抽象機(jī)制和多態(tài)技術(shù)。該原則同樣適合于非面向?qū)ο笤O(shè)計的方法，是軟件工程設(shè)計方法的重要原則之一。

我們以收音機(jī)的例子為例，講述面向?qū)ο蟮拈_閉原則。我們收聽節(jié)目時需要打開收音機(jī)電源，對準(zhǔn)電臺頻率和進(jìn)行音量調(diào)節(jié)。但是對于不同的收音機(jī)，實(shí)現(xiàn)這三個步驟的細(xì)節(jié)往往有所不同。比如自動收縮電臺的收音機(jī)和按鈕式收縮在操作細(xì)節(jié)上并不相同。因此，我們不太可能針對每種不同類型的收音機(jī)通過一個收音機(jī)類來實(shí)現(xiàn)（通過重載）這些不同的操作方式。但是我們可以定義一個收音機(jī)接口，提供開機(jī)、關(guān)機(jī)、增加頻率、降低頻率、增加音量、降低音量六個抽象方法。不同的收音機(jī)繼承并實(shí)現(xiàn)這六個抽象方法。這樣新增收音機(jī)類型不會影響其它原有的收音機(jī)類型，收音機(jī)類型擴(kuò)展極為方便。此外，已存在的收音機(jī)類型在修改其操作方法時也不會影響到其它類型的收音機(jī)。

圖1是一個應(yīng)用OCP生成的收音機(jī)類圖的例子：

圖1OCP應(yīng)用（收音機(jī)）

2.替換原則(theLiskovSubstitutionPrincipleLSP)

子類應(yīng)當(dāng)可以替換父類并出現(xiàn)在父類能夠出現(xiàn)的任何地方。UML類設(shè)計原則中這個原則是Liskov于1987年提出的設(shè)計原則。它同樣可以從BertrandMeyer的DBC(DesignbyContract)的概念推出。

我們以學(xué)生為例，夜校生為學(xué)生的子類，因此在任何學(xué)生可以出現(xiàn)的地方，夜校生均可出現(xiàn)。這個例子有些牽強(qiáng)，一個能夠反映這個原則的例子時圓和橢圓，圓是橢圓的一個特殊子類。因此任何出現(xiàn)橢圓的地方，圓均可以出現(xiàn)。但反過來就可能行不通。

Liskov的相關(guān)圖示見圖2：

圖2Liskov原則

運(yùn)用替換原則時，我們盡量把類B設(shè)計為抽象類或者接口，讓C類繼承類B（接口B）并實(shí)現(xiàn)操作A和操作B，運(yùn)行時，類C實(shí)例替換B，這樣我們即可進(jìn)行新類的擴(kuò)展（繼承類B或接口B），同時無須對類A進(jìn)行修改。#p#

3.依賴原則(theDependencyInversionPrincipleDIP)

在進(jìn)行業(yè)務(wù)設(shè)計時，與特定業(yè)務(wù)有關(guān)的依賴關(guān)系應(yīng)該盡量依賴接口和抽象類，而不是依賴于具體類。具體類只負(fù)責(zé)相關(guān)業(yè)務(wù)的實(shí)現(xiàn)，修改具體類不影響與特定業(yè)務(wù)有關(guān)的依賴關(guān)系。

在結(jié)構(gòu)化設(shè)計中，我們可以看到底層的模塊是對高層抽象模塊的實(shí)現(xiàn)（高層抽象模塊通過調(diào)用底層模塊），這說明，抽象的模塊要依賴具體實(shí)現(xiàn)相關(guān)的模塊，底層模塊的具體實(shí)現(xiàn)發(fā)生變動時將會嚴(yán)重影響高層抽象的模塊，顯然這是結(jié)構(gòu)化方法的一個"硬傷"。

面向?qū)ο蠓椒ǖ囊蕾囮P(guān)系剛好相反，具體實(shí)現(xiàn)類依賴于抽象類和接口（見圖-3）。

為此，我們在進(jìn)行業(yè)務(wù)設(shè)計時，應(yīng)盡量在接口或抽象類中定義業(yè)務(wù)方法的原型，并通過具體的實(shí)現(xiàn)類（子類）來實(shí)現(xiàn)該業(yè)務(wù)方法，業(yè)務(wù)方法內(nèi)容的修改將不會影響到運(yùn)行時業(yè)務(wù)方法的調(diào)用。

圖3依賴原則圖示

4.接口分離原則（theInterfaceSegregationPrincipleISP）

采UML類設(shè)計原則中用多個與特定客戶類有關(guān)的接口比采用一個通用的涵蓋多個業(yè)務(wù)方法的接口要好。

ISP原則是另外一個支持諸如COM等組件化的使能技術(shù)。缺少ISP，組件、類的可用性和移植性將大打折扣。

這個原則的本質(zhì)相當(dāng)簡單。如果你擁有一個針對多個客戶的類，為每一個客戶創(chuàng)建特定業(yè)務(wù)接口，然后使該客戶類繼承多個特定業(yè)務(wù)接口將比直接加載客戶所需所有方法有效。

圖4展示了一個擁有多個客戶的類。它通過一個巨大的接口來服務(wù)所有的客戶。只要針對客戶A的方法發(fā)生改變，客戶B和客戶C就會受到影響。因此可能需要進(jìn)行重新編譯和發(fā)布。這是一種不幸的做法。

圖4帶有集成接口的服務(wù)類

我們再看圖-5中所展示的技術(shù)。每個特定客戶所需的方法被置于特定的接口中，這些接口被Service類所繼承并實(shí)現(xiàn)。

圖5使用接口分離的服務(wù)類設(shè)計

如果針對客戶A的方法發(fā)生改變，客戶B和客戶C并不會受到任何影響，也不需要進(jìn)行再次編譯和重新發(fā)布。

以上四個UML類設(shè)計原則是面向?qū)ο笾谐３Ｓ玫降脑瓌t。此外，除上述四原則外，還有一些常用的經(jīng)驗(yàn)諸如類結(jié)構(gòu)層次以三到四層為宜、類的職責(zé)明確化（一個類對應(yīng)一個具體職責(zé)）等可供我們在進(jìn)行面向?qū)ο笤O(shè)計參考。但就上面的幾個原則看來，我們看到這些類在幾何分布上呈現(xiàn)樹型拓?fù)涞年P(guān)系，這是一種良好、開放式的線性關(guān)系、具有較低的設(shè)計復(fù)雜度。一般說來，在軟件設(shè)計中我們應(yīng)當(dāng)盡量避免出現(xiàn)帶有閉包、循環(huán)的設(shè)計關(guān)系，它們反映的是較大的耦合度和設(shè)計復(fù)雜化。

【編輯推薦】