物件導向程式設計六大原則

2021-06-14 15:09:06 字數 2981 閱讀 3576

一、單一職責原則:

全稱:「single-responsibility principle」

說明:就乙個類而言,應該只專注於做一件事和僅有乙個引起它變化的原因。所謂職責,我們可以理解他為功能,就是設計的這個類功能應該只有乙個,而不是兩個或更多。也可以理解為引用變化的原因,當你發現有兩個變化會要求我們修改這個類,那麼你就要考慮撤分這個類了。因為職責是變化的乙個軸線,當需求變化時,該變化會反映類的職責的變化。

使用srp注意點

1、乙個合理的類,應該僅有乙個引起它變化的原因,即單一職責;

2、在沒有變化徵兆的情況下應用srp或其他原則是不明智的;

3、在需求實際發生變化時就應該應用srp等原則來重構**;

4、使用測試驅動開發會迫使我們在設計出現臭味之前分離不合理**;

5、如果測試不能迫使職責分離,僵化性和脆弱性的臭味會變得很強烈,那就應該用facade或proxy模式對**重構;srp優點:消除耦合,減小因需求變化引起**僵化。

二、黎克特制代換原則

全稱:「liskov substitution principle」

說明:子型別必須能夠替換它們的基型別。乙個軟體實體如果使用的是乙個基類,那麼當把這個基類替換成繼承該基類的子類,程式的行為不會發生任何變化。軟體實體察覺不出基類物件和子類物件的區別。

優點:可以很容易的實現同一父類下各個子類的互換,而客戶端可以毫不察覺。

三、依賴倒置原則

全稱:「dependence inversion principle」

說明:要依賴於抽象,不要依賴於具體。客戶端依賴於抽象耦合。

抽象不應當依賴於細節;細節應當依賴於抽象;

要針對介面程式設計,不針對實現程式設計。

優點:使用傳統過程化程式設計所建立的依賴關係,策略依賴於細節,這是糟糕的,因為策略受到細節改變的影響。依賴倒置原則使細節和策略都依賴於抽象,抽象的穩定性決定了系統的穩定性。

怎樣做到依賴倒置?

以抽象方式耦合是依賴倒轉原則的關鍵。抽象耦合關係總要涉及具體類從抽象類繼承,並且需要保證在任何引用到基類的地方都可以改換成其子類,因此,黎克特制代換原則是依賴倒轉原則的基礎。

在抽象層次上的耦合雖然有靈活性,但也帶來了額外的複雜性,如果乙個具體類發生變化的可能性非常小,那麼抽象耦合能發揮的好處便十分有限,這時可以用具體耦合反而會更好。

層次化:所有結構良好的物件導向構架都具有清晰的層次定義,每個層次通過乙個定義良好的、受控的介面向外提供一組內聚的服務。

依賴於抽象:建議不依賴於具體類,即程式中所有的依賴關係都應該終止於抽象類或者介面。盡量做到:

1、任何變數都不應該持有乙個指向具體類的指標或者引用。

2、任何類都不應該從具體類派生。

3、任何方法都不應該覆寫它的任何基類中的已經實現的方法。

四、介面隔離原則

全稱:「inte***ce segregation principle」

說明:使用多個專一功能的介面比使用乙個的總介面總要好。從乙個客戶類的角度來講:乙個類對另外乙個類的依賴性應當是建立在最小介面上的。過於臃腫的介面是對介面的汙染,不應該強迫客戶依賴於它們不用的方法。

優點:會使乙個軟體系統功能擴充套件時,修改的壓力不會傳到別的物件那裡。

如何實現介面隔離原則

不應該強迫使用者依賴於他們不用的方法。

1、利用委託分離介面。

2、利用多繼承分離介面。

五、迪公尺特原則

全稱:「law of demeter」

說明:物件與物件之間應該使用盡可能少的方法來關聯,避免千絲萬縷的關係。

如何實現迪公尺特法則?

迪公尺特法則的主要用意是控制資訊的過載,在將其運用到系統設計中應注意以下幾點:

1) 在類的劃分上,應當建立有弱耦合的類。類之間的耦合越弱,就越有利於復用。

2) 在類的結構設計上,每乙個類都應當盡量降低成員的訪問許可權。乙個類不應當public自己的屬性,而應當提供取值和賦值的方法讓外界間接訪問自己的屬性。

3) 在類的設計上,只要有可能,乙個類應當設計成不變類。

4) 在對其它物件的引用上,乙個類對其它物件的引用應該降到最低。

六、開放-封閉原則

全稱:「open-closed principle」

說明:對擴充套件開放,對修改關閉。

優點:按照ocp原則設計出來的系統,降低了程式各部分之間的耦合性,其適應性、靈活性、穩定性都比較好。當已有軟體系統需要增加新的功能時,不需要對作為系統基礎的抽象層進行修改,只需要在原有基礎上附加新的模組就能實現所需要新增的功能。增加的新模組對原有的模組完全沒有影響或影響很小,這樣就無須為原有模組進行重新測試。

如何實現「開-閉」原則?

在物件導向設計中,不允許更改的是系統的抽象層,而允許擴充套件的是系統的實現層。換言之,定義乙個一勞永逸的抽象設計層,允許盡可能多的行為在實現層被實現。

解決問題關鍵在於抽象化,抽象化是物件導向設計的第乙個核心本質。

對乙個事物抽象化,實質上是在概括歸納總結它的本質。抽象讓我們抓住最最重要的東西,從更高一層去思考。這降低了思考的複雜度,我們不用同時考慮那麼多的東西。換言之,我們封裝了事物的本質,看不到任何細節。

在物件導向程式設計中,通過抽象類及介面,規定了具體類的特徵作為抽象層,相對穩定,不需更改,從而滿足「對修改關閉」;而從抽象類匯出的具體類可以改變系統的行為,從而滿足「對擴充套件開放」。

對實體進行擴充套件時,不必改動軟體的源**或者二進位制**。關鍵在於抽象。

物件導向 六大原則

舉乙個簡單的例子,登入功能。一般登入需要包括幾個基本的功能 1.登入頁面 2.接受使用者輸入 3.提交使用者輸入資料到服務端驗證 4.返回驗證結果並提示給使用者 按照單一原則我們就可以將登入功能拆分成兩個類,登入頁類和網路請求類。其實因為單一原則並不是很容易劃分,很多時候需要根據個人經驗和實際情況 ...

物件導向六大原則

先來看物件導向的六大原則吧 一 單一職責原則 二 開閉原則 三 黎克特制替換原則 四 依賴倒置原則 五 介面隔離原則 六 迪公尺特原則class imageloader 就像上面的 一樣我們把所有功能寫到乙個類中,隨著我們專案越來越大功能也越來越大,會導致這個類很龐大也很脆弱。這時候可以拆分出來每個...

物件導向六大原則

引用一段經典的話,武學的最高境界是無招勝有招 在程式設計領域,設計模式就可以認為是招數,而真正的內功心法是設計原則 下面講述一下程式設計中應該遵循的基本原則 乙個類只負責一種職責,只有這種職責的改變會導致這個類的變更。繞口一點的正統說法 不要存在多於乙個原因導致類變更 假如 類t 負責有兩種職責 p...