設計模式的六大原則

2021-08-27 19:19:32 字數 1985 閱讀 6364

關於設計模式的六大原則,經典的總結是「單一職責原則告訴我們實現類要職責單一;黎克特制替換原則告訴我們不要破壞繼承體系;依賴倒置原則告訴我們要面向介面程式設計;介面隔離原則告訴我們在設計介面的時候要精簡單一;迪公尺特法則告訴我們要降低耦合。而開閉原則是總綱,他告訴我們要對擴充套件開放,對修改關閉。」

乙個類只負責一項職責,好處:變更引起的風險降低,變更是必然的,如果單一職責原則遵守的好,當修改乙個功能時,可以顯著降低對其他功能的影響。

包含了四層意思:

1、子類可以實現父類的抽象方法,但不能覆蓋父類的非抽象方法。 2

、子類中可以增加自己特有的方法。 3

、覆蓋或實現父類的方法時前置條件更寬鬆(輸入引數可以被放大,即子類的輸入型別可以是父類輸入型別的超類) 4

、覆蓋或實現父類的方法時後置條件更嚴格(輸出結果可以被縮小,即子類返回的型別可以是父類返回型別的子類)

實現父類依賴倒置原則的核心思想是面向介面程式設計

介面隔離原則的含義是:建立單一介面,不要建立龐大臃腫的介面,盡量細化介面,介面中的方法盡量少。也就是說,我們要為各個類建立專用的介面,而不要試圖去建立乙個很龐大的介面供所有依賴它的類去呼叫。

說到這裡,很多人會覺的介面隔離原則跟之前的單一職責原則很相似,其實不然。其一,單一職責原則原注重的是職責;而介面隔離原則注重對介面依賴的隔離。其二,單一職責原則主要是約束類,其次才是介面和方法,它針對的是程式中的實現和細節;而介面隔離原則主要約束介面介面,主要針對抽象,針對程式整體框架的構建。

採用介面隔離原則對介面進行約束時,要注意以下幾點:

1、介面盡量小,但是要有限度。對介面進行細化可以提高程式設計靈活性是不掙的事實,但是如果過小,則會造成介面數量過多,使設計複雜化。所以一定要適度。 2

、為依賴介面的類定**務,只暴露給呼叫的類它需要的方法,它不需要的方法則隱藏起來。只有專注地為乙個模組提供定**務,才能建立最小的依賴關係。 3

、提高內聚,減少對外互動。使介面用最少的方法去完成最多的事情。

定義:乙個物件應該對其他物件保持最少的了解。

問題由來:類與類之間的關係越密切,耦合度越大,當乙個類發生改變時,對另乙個類的影響也越大。

解決方案:盡量降低類與類之間的耦合。

原文:「

software entities should be open for extension,but closed for modification」。

翻譯過來就是:「軟體實體應當對擴充套件開放,對修改關閉」。

通俗來說就是:軟體系統中包含的各種元件,例如模組(

modules

)、類(

classes

)以及功能(

functions

)等等,應該在不修改現有**的基礎上,引入新功能。開閉原則中「開」,是指對於元件功能的擴充套件是開放的,是允許對其進行功能擴充套件的;開閉原則中「閉」,是指對於原有**的修改是封閉的,即不應該修改原有的**。

遵循開閉原則設計出的模組具有兩個主要特徵:(1

)對於擴充套件是開放的(

open for extension

)。這意味著模組的行為是可以擴充套件的。當應用的需求改變時,我們可以對模組進行擴充套件,使其具有滿足那些改變的新行為。也就是說,我們可以改變模組的功能。 (

2)對於修改是關閉的(

closed for modification

)。對模組行為進行擴充套件時,不必改動模組的源**或者二進位制**。模組的二進位制可執行版本,無論是可鏈結的庫、

dll或者

.exe

檔案,都無需改動。

實現開閉原則的關鍵就在於「抽象」。把系統的所有可能的行為抽象成乙個抽象底層,這個抽象底層規定出所有的具體實現必須提供的方法的特徵。作為系統設計的抽象層,要預見所有可能的擴充套件,從而使得在任何擴充套件情況下,系統的抽象底層不需修改;同時,由於可以從抽象底層匯出乙個或多個新的具體實現,可以改變系統的行為,因此系統設計對擴充套件是開放的。我們在軟體開發的過程中,一直都是提倡需求導向的。這就要求我們在設計的時候,要非常清楚地了解使用者需求,判斷需求中包含的可能的變化,從而明確在什麼情況下使用開閉原則。

設計模式六大原則

0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝,封裝好了才能很好的復用,達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...

設計模式六大原則

0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝,封裝好了才能很好的復用,達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...

設計模式六大原則

參考文章 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責,或者可以定義為 就乙個類而言,應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放,對修改關閉。...