物件導向設計所需要遵循的六個原則

2021-08-30 11:31:04 字數 2047 閱讀 5377

在物件導向的開發中,主要遵循的有以下6個設計原則:

單一職責 ,開放封閉 ,黎克特制代換,依賴倒轉,迪公尺特法則,合成/聚合復用

下面將具體介紹這些設計原則:

單一職責原則:就乙個類而言,應該僅有乙個引起它發生變化的原因

如果乙個類的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱這個或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當發生變化時,這種高耦合會導致意想不到的變化

開放封閉原則:軟體實體(類,模組,函式等等)應該可以擴充套件,但是不能修改

面對需求的時候,對程式的改動是通過增加新的**來完成的,而不是通過對原**的改變來完成,對於原**的改變很麻煩,可能會導致意想不到的錯誤

開放封閉原則是物件導向設計的核心所在,遵循這個原則,實現了可維護,可擴充套件,可復用,靈活性好,開發人員應該進隊程式中呈現出頻繁變化的那些部分作出抽象,但是也不能可以地對每乙個部分進行抽象,拒絕不成熟的抽象一樣很重要

個人理解:簡單工廠模式並不是屬於23中設計模式之一,主要就是因為簡單工廠模式不符合開放封閉的原則,在類裡面增加switch...case語句,當有新的功能或者是類的時候,就要修改該工廠類,**的可維護性減低了

黎克特制代換原則:子型別必須能夠替換掉他們的父型別

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

如果沒有黎克特制代換原則,我們在開發的時候如果改變了子類的行為,同時對父類產生了影響,這樣你要修改子類,也就必須要修改父類了。

依賴倒轉原則:也叫依賴倒置原則,其內容如下:

a:高層模組不應該依賴底層模組,兩個都應該抽象

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

倒轉,假如使用者的需求需要改變,軟體開發的時候你用的是db2資料庫,但是最後要改為mysql資料庫,由於高層的模組依賴的是底層的模組,這就使得底層模組也要做修改。但是如果高層模組依賴的是介面或者是抽象類的話,因為介面和抽象類是不變的,所以如果你要更改資料庫的話,就不怕出現混亂,a和b兩個說的都是這樣的意思。因為依賴的是抽象類或者介面,有黎克特制代換規則可以知道,子類的變化對於父類造不成影響。

針對上面的例子,我們可以做乙個抽象的資料庫的類,讓db2繼承這個抽象類,加入現在要換為mysql資料庫,只要讓mysql去繼承這個類就可以,不管用哪個資料庫,我們都建立的是抽象資料類的引用,用它去指向你要訪問的類就ok了

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

對於這個原則,我是這樣理解的,兩個類之間相互知道了解,就是將乙個類直接暴露給了另外乙個類,這樣子違反了資訊的隱藏。如果多個類之間需要兩兩發生呼叫的話,那麼就需要呼叫者知道被呼叫這的全部資訊,這是我們可以通過乙個中介來**需要通訊的兩個類之間的請求,所有的類,只需要將自己暴露給中介就可以了,不需要給被呼叫者,這樣做簡化了**,這也就是設計模式中的中介者模式

這樣降低了類與類之間的耦合性,符合我們提倡的低耦合的觀點,耦合性越弱,越有利於復用,乙個處在弱耦合的類被修改,不會對有關係的類造成波及

合成/聚合復用原則:盡量使用合成/聚合,盡量不要使用類繼承

這樣的好處有助於保持每個類被封裝,並被集中在單個任務上,這樣類和繼承層級會保持較小的規模,並且不太可能增長為不可控制的龐然大物

拿橋接模式來舉例,加入不同的手機品牌,有不同的軟體,每種軟體都要安裝在不同的手機上面,如果這個時候用繼承的話,每個具體手機品牌繼承抽象類手機品牌,然後在每個手機品牌下面都有每個軟體的使用,這樣乙個軟體被實現了很多次,每個手機品牌都可以對其實現,如果我們要新增加乙個軟體的話,每個具體的手機品牌就又要分別實現,這樣違反了可維護性。

這時候我們可以讓軟體成為手機品牌的乙個組成部分,他們之間的關係是組合關係,只需要寫乙個具體的軟體抽象類,然後讓每個具體的軟體去繼承這個抽象類,這個時候如果要增加軟體實現類,只需要增加乙個具體的實現類就可以了

以上是我學習《大話設計模式》對於物件導向設計所遵循的六個設計原則的總結,希望對您有用。

物件導向設計時需要「六化」設計人員

物件導向設計方法目標 在系統設計時,設計人員如果能夠達到以下 六化 即模組化 角色化 流程化 規範化 簡單化 個性化,那最後的設計結果將會是非常令人滿意的。我們用總結如下。物件導向設計目標 特 點 說 明 1 模組化 把整個系統劃分成幾個相互關聯的模板 2 角色化 需要分別從不同使用者的角度出發去考...

物件導向的六大設計原則

open close principle,縮寫是ocp,軟體中的物件應該對於擴充套件是開放的,但是對於修改是封閉的。也就是在軟體需求變化時,應該盡量通過擴充套件的方式公升級 維護,而不是修改原有的 來實現。黎克特制替換原則的縮寫是lsp,定義是說,所有引用基類的地方必須能夠透明地使用其子類物件。這個...

物件導向設計的六大設計原則 iOS

原則二 單一職責原則 single responsibility principle 原則三 依賴倒置原則 dependency inversion principle 原則四 介面分離原則 inte ce segregation principle 原則五 迪公尺特法則 law of demete...