設計模式系列

包括7大設計原則和23大設計模式。

7大設計原則

這7大設計原則不只是23大設計模式要去遵照的，也是咱們日常開發過程當中要時刻去遵照的準則，因此說很是很是重要。

1，單一職責原則

1）定義：就一個類而言，應該僅有一個引發它變化的緣由。簡而言之，就是功能要單一。
2）若是一個類承擔的職責過多，就等於把這些職責耦合在一塊兒，一個職責的變化可能會削弱或者抑制這個類完成其它職責的能力。這種耦合會致使脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。(敏捷軟件開發)。
3）軟件設計真正要作的許多內容，就是發現職責並把那些職責相互分離。
4）單一職責原則能夠看作是低耦合、高內聚在面向對象原則上的引伸，將職責定義爲引發變化的緣由，以提升內聚性來減小引發變化的緣由。責任過多，引發它變化的緣由就越多，這樣就會致使職責依賴，大大損傷其內聚性和耦合度。

2，開放關閉原則

1）定義：就是說軟件實體(類，方法等等)應該能夠擴展（擴展能夠理解爲增長），可是不能在原來的方法或者類上修改，也能夠這樣說，對增長代碼開放，對修改代碼關閉。
2）兩個特徵： 對於擴展（增長）是開放的，由於它不影響原來的，這是新增長的。對於修改是封閉的，若是老是修改，邏輯會愈來愈複雜。
3）開放封閉原則是面向對象設計的核心思想。遵循這個原則能夠爲咱們面向對象的設計帶來巨大的好處：可維護（維護成本小，作管理簡單，影響最小）、可擴展（有新需求，增長就好）、可複用（不耦合，可使用之前代碼）、靈活性好（維護方便、簡單）。開發人員應該僅對程序中出現頻繁變化的那些部分作出抽象，可是不能過激，對應用程序中的每一個部分都刻意地進行抽象一樣也不是一個好主意。拒毫不成熟的抽象和抽象自己同樣重要。

3，里氏代替原則

1）定義：子類型必須可以替換掉它們的父類型。更直白的說，里氏代替原則是實現面向接口編程的基礎。
2）任何基類能夠出現的地方，子類必定能夠出現，因此咱們能夠實現面向接口編程。 里氏代替原則是繼承複用的基石，只有當子類能夠替換掉基類，軟件的功能不受到影響時，基類才能真正被複用，而子類也可以在基類的基礎上增長新的行爲。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。

4，依賴倒置原則

1）定義：高層模塊不該該依賴低層模塊，二者都應該依賴其抽象；抽象不該該依賴細節，細節應該依賴抽象。簡單說就是，咱們要針對接口編程，而不要針對實現編程。
2）高層模塊不該該依賴低層模塊，兩個都應該依賴抽象，由於抽象是穩定的。抽象不該該依賴具體（細節），具體（細節）應該依賴抽象。
3）依賴倒置原則其實能夠說是面向對象設計的標誌，若是在咱們編碼的時候考慮的是面向接口編程，而不是簡單的功能實現，體現了抽象的穩定性，只有這樣才符合面向對象的設計。

5，接口隔離原則

1）定義：指的是使用多個專門的接口比使用單一的總接口要好。也就是說不要讓一個單一的接口承擔過多的職責，而應把每一個職責分離到多個專門的接口中，進行接口分離。過於臃腫的接口是對接口的一種污染。
2）使用多個專門的接口比使用單一的總接口要好。
3）一個類對另一個類的依賴性應當是創建在最小的接口上的。
4）一個接口表明一個角色，不該當將不一樣的角色都交給一個接口。沒有關係的接口合併在一塊兒，造成一個臃腫的大接口，這是對角色和接口的污染。
5）不該該強迫客戶依賴於它們不用的方法。接口屬於客戶，不屬於它所在的類層次結構。」這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，若是強迫用戶使用它們不使用的方法，那麼這些客戶就會面臨因爲這些不使用的方法的改變所帶來的改變。
6）接口隔離原則告訴咱們，在作接口設計的時候，要儘可能設計的接口功能單一，功能單一，使它變化的因素就少，這樣就更穩定，其實這體現了高內聚，低耦合的原則，這樣作也避免接口的污染。

6，組合複用原則

1）定義：就是在一個新的對象裏面使用一些已有的對象，使之成爲新對象的一部分。新對象經過向這些對象的委派達到複用已用功能的目的。簡單地說，就是要儘可能使用合成/聚合，儘可能不要使用繼承。
2）要使用好組合複用原則，首先須要區分」Has—A」和「Is—A」的關係。 「Is—A」是指一個類是另外一個類的「一種」，是屬於的關係，而「Has—A」則不一樣，它表示某一個角色具備某一項責任。致使錯誤的使用繼承而不是聚合的常見的緣由是錯誤地把「Has—A」當成「Is—A」.例如：雞是動物，這就是「Is-A」的表現，某人有一個手槍，People類型裏面包含一個Gun類型，這就是「Has-A」的表現。
3）組合/聚合複用原則可使系統更加靈活，類與類之間的耦合度下降，一個類的變化對其餘類形成的影響相對較少，所以通常首選使用組合/聚合來實現複用；其次才考慮繼承，在使用繼承時，須要嚴格遵循里氏替換原則，有效使用繼承會有助於對問題的理解，下降複雜度，而濫用繼承反而會增長系統構建和維護的難度以及系統的複雜度，所以須要慎重使用繼承複用。

7，迪米特法則

1）定義：迪米特法則又叫最少知識原則（Least Knowledge Principle，LKP），指的是一個對象應當對其餘對象有儘量少的瞭解。也就是說，一個模塊或對象應儘可能少的與其餘實體之間發生相互做用，使得系統功能模塊相對獨立，這樣當一個模塊修改時，影響的模塊就會越少，擴展起來更加容易。
2）關於迪米特法則其餘的一些表述有：只與你直接的朋友們通訊；不要跟「陌生人」說話。
3）外觀模式（Facade Pattern)和中介者模式（Mediator Pattern）就使用了迪米特法則。
4）迪米特法則的初衷是下降類之間的耦合，實現類型之間的高內聚，低耦合，這樣能夠解耦。可是凡事都有度，過度的使用迪米特原則，會產生大量這樣的中介和傳遞類，致使系統複雜度變大。因此在採用迪米特法則時要反覆權衡，既作到結構清晰，又要高內聚低耦合。

建立型

建立型設計模式提供了一種在建立對象的同時隱藏建立邏輯的方式，而不是使用 new 運算符直接實例化對象。這使得程序在判斷針對某個給定實例須要建立哪些對象時更加靈活。

建立型設計模式包括如下5種：

設計模式系列1：單例模式（Singleton Pattern）

設計模式系列2：工廠方法模式（Factory Method Pattern）

設計模式系列3：抽象工廠模式（Abstract Factory Pattern）

設計模式系列4：建造者模式（Builder Pattern）

設計模式系列5：原型模式（Prototype Pattern）

結構型

結構型設計模式關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象得到新功能的方式。

結構型設計模式包括如下7種：

設計模式系列6：適配器模式（Adapter Pattern）

設計模式系列7：橋接模式（Bridge Pattern）

設計模式系列8：裝飾模式（Decorator Pattern）

設計模式系列9：組合模式（Composite Pattern）

設計模式系列10：外觀模式（Facade Pattern）

設計模式系列11：享元模式（Flyweight Pattern）

設計模式系列12：代理模式（Proxy Pattern）

行爲型

行爲型設計模式主要討論的是在不一樣對象之間劃分責任和算法的抽象化的問題。

行爲型設計模式包括如下11種：

設計模式系列13：模板方法模式（Template Method Pattern）

設計模式系列14：命令模式（Command Pattern）

設計模式系列15：迭代器模式（Iterator Pattern）

設計模式系列16：觀察者模式（Observer Pattern）

設計模式系列17：中介者模式（Mediator Pattern）

設計模式系列18：狀態模式（State Pattern）

設計模式系列19：策略模式（Stragety Pattern）

設計模式系列20：責任鏈模式（Chain of Resp Pattern）

設計模式系列21：訪問者模式（Vistor Pattern）

設計模式系列22：備忘錄模式（Memento Pattern）

設計模式系列23：解釋器模式（Interpreter Pattern）

參考資料

1. https://www.dofactory.com/net/design-patterns
2. http://www.runoob.com/design-pattern/design-pattern-tutorial.html
3. http://www.javashuo.com/article/p-qcqmitdp-hn.html
4. https://www.cnblogs.com/abcdwxc/archive/2007/10/30/942834.html

源代碼

Github地址：https://github.com/mcgrady525/GettingStarted.DesignPattern