設計模式的六大原則

2021-07-05 07:59:02 字數 2517 閱讀 4399

概括:

原則

含義

具體方法

開閉原則

對擴充套件開放,對修改關閉

多使用抽象類和介面

黎克特制代換原則

基類可以被子類替換

使用抽象類繼承,不使用具體類繼承

依賴倒轉原則

要依賴於抽象,不要依賴於具體

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

介面隔離原則

使用多個隔離的介面,比使用單個介面好

建立最小的介面

迪公尺特法則

乙個軟體實體淫蕩盡可能少地與其他實體發生相互作用

通過中間類建立聯絡

合成復用原則

盡量使用合成/聚合,而不是使用繼承

盡量使用合成/聚合,而不是使用繼承

一.開閉原則:

一句話概括:對擴充套件開放,對修改關閉.
為什麼要遵循開閉原則:

軟體開發完的**需要經過多種測試才能夠投入使用,如果對原來的**進行了修改,並不能保證軟體的其他功能還是依舊好使,需要重新對**進行全面的測試,有些改動需要對原來的**做大規模的改動甚至重新構造系統.

解決方法:多使用抽象類和介面.

二.黎克特制代換原則

一句話概括:子類必須能夠替換成它們的基類
更加詳細的解釋:在乙個軟體系統中,子類應該可以替換任何基類能夠出現的地方,並且經過替換以後,**還能正常工作.子類也能夠在基類的基礎上增加新的行為.

黎克特制代換是對開閉原則的補充,他講的是基類和子類的關係.只有當這種關係存在時,黎克特制代換關係才存在.

長方形與正方形的例子:

如果按左圖的來看,長方形求面積與正方形求面積的方法顯然是不一樣的,(假設這裡正方形面積為 ((width+height)/2)^2 ),那就不符合黎克特制替換了.

按照右圖則符合.

由此可見,在進行設計的時候,我們應該盡量從抽象類繼承,而不是從具體類繼承.如果從繼承等樹來看,所有葉子節點應當是具體類,而所有的樹枝節點應當是抽象類或者介面.當然這只是乙個一般性的指導原則,使用的時候還要具體情況具體分析.

三.依賴倒轉原則

一句話概括:要依賴於抽象,不要依賴於具體
依賴也就是耦合,分為三種:

1.零耦合(nil couping)關係:兩個類沒有依賴關係,(基本上就是這2個類沒有互相呼叫的關係,甚至是沒有關係)

2.具體耦合(concrete couping)關係:兩個具體的類之間有依賴關係,如果乙個類直接引用另乙個具體類,就是這種關係.(也就是我們最早寫的**,直接自己new物件)

3.抽象耦合(abstract couping)關係:這種關係發生在乙個具體類和乙個抽象類之間,這樣就使必須發生關係的類之間保持最大的靈活性.(在action中呼叫service,這個必須是有關係的,所以我們在做的時候使用介面,利用spring這個工廠來自動注入)

要做到依賴倒轉原則,使用抽象方式耦合是關鍵(必須耦合的地方,那就用介面).由於乙個抽象耦合總要涉及具體類從抽象類繼承,並且需要保證在任何引用到某類的地方都可以改換成其他子類,因此黎克特制代換是依賴倒轉原則的基礎,依賴倒轉原則是ood的核心原則,設計模式的研究和應用都是他作為指導原則的.

四.介面隔離原則

一句話概括:使用多個隔離的介面,比使用單個介面好.
舉個string的例子來看,左邊的是不符合介面隔離的,右邊的是符合的:

五.迪公尺特法則(最少知道原則)

一句話概括:talk only to your immediate friends.
乙個類少去了解其他類的內部.減少耦合.

六.合成復用原則

一句話概括:盡量使用聚合/組合,少使用繼承
使用繼承和組合/聚合的目的是為了復用

什麼時候使用繼承,必須滿足以下所有的條件:

1.子類是超類的乙個特殊種類,而不是超類的乙個角色,也就是區分"has -a " 與 " is -a" .

2.永遠不會出現需要將子類換成另外乙個子類的情況.如果不能肯定將來是否會變成另外乙個子類的話,就不要使用繼承.

3.子類具有擴充套件超類的責任,而不是具有置換掉(override)或登出掉(nullify)超類的責任,如果乙個子類需要大量的置換掉超類的行為,那麼這個類就不應該是這個超類的子類.

4.只有在分類學角度上有意義時,才可以使用繼承.不要從工具類繼承.

設計模式六大原則

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

設計模式六大原則

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

設計模式六大原則

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