我用過的設計模式（1）-- 本門心法

文章目錄

單一職責原則

什么是“單一職責原則”？

飽受爭議的原則

“單一職責原則”的優勢

怎么用？自己看著辦

里氏替換原則

什么是“里氏替換原則”？

關于里氏替換原則

依賴倒置原則

什么是“依賴倒置原則”

關于依賴倒置原則的小故事

依賴倒置，讓項目并駕齊驅

最佳實踐

接口隔離原則

什么是“接口隔離原則”？

接口要高內聚

最佳實踐

迪米特法則

松耦合的法則：迪米特法則

開-閉原則

何為“開閉原則”

如何應對需求變化？

單一職責原則

什么是“單一職責原則”？

如果要理解為：一個類只有一個職責，當然也是可以的，簡單化嘛。

單一職責的原話解釋是這樣的：There should never be more than one reason for a class to change.

什么意思？那里，應該，沒有，多于，一個，原因，使得，類，去，改變。

啊，咱這蹩腳英語，勉強能翻譯啊。

不過，能看懂是一回事，具體實現就是另一個故事了。。。

飽受爭議的原則

為什么飽受爭議呢？看著多單純一原則啊。

這樣，我們來看一個打電話的過程：

class 電話{

public:

void 撥出電話(string 電話號碼);

void 瞎比比(Object *嗶嗶類對象); //總不能傳個string吧，說一句就沒啦？

void 掛電話();

}；

這個有沒有問題？是有那么小問題的嘞。

你說我哪天，撥號的方法要改一下，我變成撥不通就一直撥，那這個類變一下。

然后我通信的方法再改一下，我現在不允許兩個人同時說話，一個說完另一個再說，那這個類再變一下。

這個類，有兩個職責：協議管理和數據傳送。

那怎么搞？把那倆接口獨立出來唄，然后將兩個職責融合在一個類中。

現在變成了一個類融合了兩個接口，確實那個實現類還是有兩個原因引起變化，但是別忘了，我們是面向接口編程（后面會提到，依賴倒置原則）。我們對外公布的是接口，又不是實現類。

如果你非要對這個栗子實現單一原則，也可以，你要有那個權力或精力（因為我估計沒人愿意陪你這樣玩）。

“單一職責原則”的優勢

類的復雜性降低，實現什么職責都有明確的定義。

這是最首要的，如果不能降低復雜度，那就別分開

可讀性提高

可維護性提高

變更引起的風險降低

怎么用？自己看著辦

對于接口，我們在實現的時候一定要做到單一

，但是對于實現類就需要多方面考慮了。

生搬硬套的話會有什么不良反應，去試試就知道了。

單一職責很難在項目中得到體現，就拿上面那栗子來說，能把接口分開就謝天謝地吧。

當然，單一職責也可以用于類方法，說來慚愧，我曾經用一個類方法實現五個功能（通過巧妙設置參數）。。。。

現在想想，真是好笑啊。

里氏替換原則

什么是“里氏替換原則”？

這個原則，說簡單也簡單，說拗口也拗口。

是這樣說的：Function that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

所有引用基類的地方，必須能透明的使用其子類對象。

什么意思呢？就是子類必須實現父類的所有方法。有父類出現的地方，子類就可以出現。

關于里氏替換原則

關于里氏替換原則，我并不想講太多，無非就是父類弄成純虛基類，然后客端調用的時候以子類來new出父類聲明的對象：父類 * 對象 = new 某子類();

這種格式后面會常見，見到的時候自然就明白了。

依賴倒置原則

什么是“依賴倒置原則”

這是我最喜歡的一個原則，也是受益最大的。

它的定義是：High level modules should not depend upon low level modules. Both should depend upon abstractions. Absteactions should not depend upon details.Details should depend upon abstractions.

高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象。

抽象不應該依賴于細節。

細節應該依賴于抽象。

關于依賴倒置原則的小故事

故事是別人的，不過放在這里也是很應景啦。

故事是這樣的：

有個適齡小伙子，他還單著。有一天，他喜歡的那個姑娘突然給他打電話，說她的電腦壞了，一用就藍屏警告。姑娘講著講著就要哭出來了，小伙子那個急啊，他心疼啊。所幸，小伙子憑借高超的技術，當機立斷：內存條壞了。但是又苦于所愛隔山水啊，所以他只能當遠程指揮官了。他指導姑娘：扒開電腦主機后蓋，把內存條扯出來，然后開機看看，如果還藍屏，那就把那條內存條插回去，把另一條拔出來。一頓操作猛如虎，姑娘在小伙無私又認真的指揮下，把電腦修好了。

過兩天，姑娘又打電話給小伙子，說她收音機壞了，希望小伙能再遠程指導一次。但是這次小伙無能了，他不行了，他不會，太難了。他放棄了，他把電話掛了。姑娘很失望。

但是姑娘不知道，電腦，是松耦合，強內聚的，哪個部件壞了就換哪個，但是收音機不一樣，收音機是緊耦合的，牽一發而動全身，收音機沒聲音，可能是擴音器壞了，可能是信號接收其壞了，可能是解頻罷工了···畢竟她是外行嘛，悲催的小伙子。

那么，就要切入到我們的正題了，松耦合、強內聚的電腦，是怎么組裝的呢？

像內存條這種東西啊，管你是哪家生產的，只要符合規格，再比如鼠標、鍵盤、電池（電池得配套），反正哪個部件壞了就換哪個部件。為什么這些部件不論插在哪一臺電腦上都能使用呢？是這些部件配合電腦主板設計，還是電腦主板配合這些零部件設計呢？

想來答案已經很明確了。就拿CPU來說，CPU的對外都是針腳式或觸點式的標準接口，只要接口設計好，內部再復雜和外界也沒有關系。哪個主板要插CPU，那就得和CPU的接口對上。那么這時候如果電腦的內存條壞了，就不該成為你更換麥克風的理由。這不是開玩笑，要是收音機的外放壞了，可能得整部收音機脫胎換骨了。

PC的接口始終是有限的，但是軟件設計得好，卻可以不斷地拓展的。

依賴倒置，讓項目并駕齊驅

我們來思考一下依賴倒置對并行開發的影響。

如果兩個類之間有依賴關系，只要定制出兩者之間的接口（或抽象類），就可以獨立開發了。就像我最近做的一個圖書管理項目，只要合理地運用依賴倒置，便可以很好的將界面與后臺數據訪問解耦合，從而實現并行開發。

最佳實踐

依賴倒置原則的本質就是通過抽象使得各個類或模塊的實現彼此獨立，不互相影響，實現模塊之間的松耦合，我們怎么在項目中使用這個規則呢？只要通過以下的幾個規則：

每個類盡量都有接口或抽象類，或者抽象和接口二者都具備。

變量的表面類型盡量是接口或者抽象類。

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

盡量不要覆寫基類的方法。

結合里氏替換原則。

反正我以前是一條都沒對上。

“依賴倒轉原則”在小項目上很難體現出來。

接口隔離原則

什么是“接口隔離原則”？

它建立在“依賴倒置原則”之上，

它的定義有倆：

Client should not be forced to depend upon interfaces that they don’t use.

客戶端不應該依賴于它不需要的接口。

The dependency of one class to another one should depend on the smallest possible interface.

類之間的依賴關系應該建立在最小的接口上。

簡單易懂啊，如果對前面那個原則有一定的把握。

建立單一接口，接口盡量細化。

接口要高內聚

什么是高內聚？高內聚就是提高接口、類、模塊的處理能力，減少對外的交互。比如說你告訴你的保鏢，今天去給我買一打愛馬仕，他就去了。你也不用問他花了多少錢，他也不用問你是不是抽風了，這種不問條件執行的行為就是高內聚。

接口是對外的承諾，承諾越少對系統的開發越有利，變更的風險也越大，同時也有利于降低成本。

最佳實踐

- 一個接口只服務于一個子模塊或業務邏輯 - 通過業務邏輯壓縮接口中的public方法，接口要勤快點重構 - 已經被污染的接口，盡量去修改 - 了解環境，拒絕盲從

1

2

3

4

5

6

迪米特法則

松耦合的法則：迪米特法則

英文解釋：Only talk to your immedate friends.

只與直接的朋友通信。

如果兩個類之間不能直接通信，那么這兩個類就不應該發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。

迪米特法則首先強調在類的設計上，每一個類都應該盡量降低成員的訪問權限，強調了類之間的松耦合。

類之間的耦合越弱，越有利于重復利用，一個處在弱耦合的類被修改，不會對相關類造成波及。

開-閉原則

何為“開閉原則”

Software entities like classes, modules and functions should be open for extension but closed for modifications.

一個軟件實體，應該對拓展開放，對修改關閉。

抽象實體：

項目或軟件產品中按照一定的邏輯規則劃分的模塊。 抽象類 方法

1

2

3

這個原則很重要，后面會很經常見。

多說無益，我就稍微說兩句，后面慢慢看它真面目。

如何應對需求變化？

既然說，對修改要關閉，那需求變化了怎么辦？

有如下方法：

1、修改接口 2、修改實現類 3、通過拓展實現變化

1

2

3

至于為什么需要這個原則、如何使用、何時使用這個原則，跟著我的步伐，往后看。

今天的分享到此告一段落，算是我回歸設計模式模塊的禮物。

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。