初識設計模式 設計模式的六大原則

2021-08-27 03:22:34 字數 1399 閱讀 7431

定義:就乙個類而言,應該僅有乙個引起它變化的原因

解釋:如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力,當變化發生時,設計會遭到意想不到的破壞。

定義:對於擴充套件是開放的,對於修改是封閉的。

解釋:對乙個已完成的類,如果需要修改或增加其中的功能,最好使用繼承的方式對其擴充套件,盡量不要改動類的本身。

定義:子型別必須能夠替換掉他們的父型別。

解釋:當只有子類可以替換掉父類,軟體的單位功能不會受到影響時,父類才能真正被復用,而子類可以在父類的基礎上增加新的行為。

定義:高層模組不應該依賴底層模組。兩個應該依賴抽象

抽象不應該依賴細節,細節應該依賴抽象

解釋:舉例說明:設計乙個類,其主要的功能就是鏈結資料庫,並對資料庫進行增刪改查等相關操作。如果我們把這個類只寫成鏈結mysql的類,那在使用過程中如果需要鏈結sqlserver,我們就需要在增加乙個類。這就是高層(呼叫類的**)依賴底層(鏈結資料庫的類)。所以在thinkphp或者yii中一般都建立乙個抽象的類或介面,所有的子類是實現鏈結或呼叫不同資料庫的類,在高層**中,通過不同的設計模式呼叫即可,無需修改大量**。(這個完全是自己的理解,可能不正確)

定義:如果兩個類不必彼此直接通訊,那麼兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話,可以通過第三者**這個呼叫。

解釋:還是舉例說明

**示例:

}第一張圖中base類中存在方法getaccesstoken(),其中呼叫proxy::cache()方法,proxy::cache()中呼叫thinkphp自帶的cache類庫,如果應用場景變為yii2擴建,我們只需要修改proxy::cache()中的**就可以,無需改變base中的**。

定義:盡量使用合成、聚合,盡量不要使用類的繼承。

解釋:優先使用類的合成/聚合將有助於你保持每個類被封裝,並被集中到單個任務上。這樣類和類繼承的層次會保持在最小規模上,並且不太可能增長成為不可控制的龐然大物。

這裡需要著重說明一下,在其他的資料中發現這個原則不在6大原則之內,而剩餘的另一大原則為【介面隔離原則】(isp),個人理解感覺這兩個原則很像,所以附加介面隔離原則的介紹**,我這裡就將這兩個原則合併為乙個原則了,感覺書上的說法比較籠統而已,因為合成/聚合確實在**中不常見,而且不知道怎麼實現。

初識設計模式——簡單工廠模式、策略模式及兩者的結合使用

設計模式六大原則

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

設計模式六大原則

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

設計模式六大原則

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