UML類設計原則是什么

這篇文章將為大家詳細講解有關UML類設計原則是什么，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

面向對象的設計原則－UML類設計原則

在面向對象設計中，如何通過很小的設計改變就可以應對設計需求的變化，這是令設計者極為關注的問題。為此不少OO先驅提出了很多有關面向對象的設計原則用于指導OO的設計和開發。下面是幾條與類設計相關的設計原則。

1.開閉原則（theOpenClosedPrincipleOCP）

UML類設計原則中開閉原則是指一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。因此在進行面向對象設計時要盡量考慮接口封裝機制、抽象機制和多態技術。該原則同樣適合于非面向對象設計的方法，是軟件工程設計方法的重要原則之一。

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

圖1是一個應用OCP生成的收音機類圖的例子：

圖1OCP應用（收音機）

2.替換原則(theLiskovSubstitutionPrincipleLSP)

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

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

Liskov的相關圖示見圖2：

圖2Liskov原則

運用替換原則時，我們盡量把類B設計為抽象類或者接口，讓C類繼承類B（接口B）并實現操作A和操作B，運行時，類C實例替換B，這樣我們即可進行新類的擴展（繼承類B或接口B），同時無須對類A進行修改。

3.依賴原則(theDependencyInversionPrincipleDIP)

在進行業務設計時，與特定業務有關的依賴關系應該盡量依賴接口和抽象類，而不是依賴于具體類。具體類只負責相關業務的實現，修改具體類不影響與特定業務有關的依賴關系。

在結構化設計中，我們可以看到底層的模塊是對高層抽象模塊的實現（高層抽象模塊通過調用底層模塊），這說明，抽象的模塊要依賴具體實現相關的模塊，底層模塊的具體實現發生變動時將會嚴重影響高層抽象的模塊，顯然這是結構化方法的一個"硬傷"。

面向對象方法的依賴關系剛好相反，具體實現類依賴于抽象類和接口（見圖-3）。

為此，我們在進行業務設計時，應盡量在接口或抽象類中定義業務方法的原型，并通過具體的實現類（子類）來實現該業務方法，業務方法內容的修改將不會影響到運行時業務方法的調用。

圖3依賴原則圖示

4.接口分離原則（theInterfaceSegregationPrincipleISP）

采UML類設計原則中用多個與特定客戶類有關的接口比采用一個通用的涵蓋多個業務方法的接口要好。

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

這個原則的本質相當簡單。如果你擁有一個針對多個客戶的類，為每一個客戶創建特定業務接口，然后使該客戶類繼承多個特定業務接口將比直接加載客戶所需所有方法有效。

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

圖4帶有集成接口的服務類

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

圖5使用接口分離的服務類設計

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

關于“UML類設計原則是什么”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。