前言

最近要開始學習設計模式了，以前是偶爾會看看設計模式的書或是在網上翻到了某種設計模式，就順便看看，也沒有仔細的學習過。前段時間看完了JVM的知識，然后就想著JVM那么費勁的東西都看完了，說明自己學習耐力還是有的，所以就打算仔細的研究研究設計模式，然后也將設計模式的學習過程記錄下來。

GoF的設計模式

Gang of Four，簡稱GoF，分別是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides，這四位軟件工程學者在1994年歸納發表了23種在軟件開發中使用頻率較高的設計模式，旨在用模式來統一溝通面向對象方法在分析、設計和實現間的鴻溝。軟件開發發展到現在設計模式已經不至23種了，但是GoF的23種設計模式還是軟件開發種很常用的，所以一般講解設計模式都是指的GoF的23種設計模式，我以后要學習的設計模式也是這23種設計模式。并且舉例子也都是以Java語言為主的。

面向對象設計原則

單一職責原則（Simple Responsibility Principle,SRP）

一個類應該只有一個功能領域的職責，對外只提供一種功能，而引起類變化的原因應該只有一個。單一原則要達到的目的就是高內聚，低耦合。例如有一個用戶類，這個用戶類中包含用戶的屬性和用戶的行為，這就造成了業務對象和業務邏輯被放在了一起，使得這個類有兩種職責，違背了單一職責原則。應該將屬性和行為分開，分別設立單獨的接口（屬性接口，行為接口）和實現類（屬性實現類，行為實現類），這樣就可以將業務對象和業務邏輯單獨分開了。

開閉原則（Open Close Principle,OPC）

一個對象對擴展開放，對修改關閉。通俗的理解是：對類的改動是通過增加代碼進行的，而不是改動現有的代碼。例如有一個用戶行為接口，這個接口已經有兩個實現類了，這時有一個需求是要給這個用戶新增一個行為，這個時候需要更改用戶行為接口，但是這樣就違背了開閉原則。真正符號開閉原則的做法是，再寫一個新的接口（或抽象類）繼承自用戶行為接口，然后所有的用戶行為實現類都實現這個新的接口（或繼承自新的抽象類）。

里氏替換原則（Liskov Substitution Principle,LSP）

在任何父類出現的地方都可以用它的子類來替代。也就是說同一個繼承體系中的對象應該有共同的行為特征。在里氏替換原則中，所有引用基類的地方必須能夠透明地使用其子類對象。只要有父類出現的地方，子類就能夠出現，而且替換為子類不會產生任何錯誤或異常。反過來，子類出現的地方，替換為父類就可能出現問題了。

里氏替換原則為良好的繼承定義了一個規范，具體有4個：

• 子類必須完成實現父類的方法。
• 子類可以有自己的特性。
• 覆蓋或者實現父類的方法時輸入參數可以被放大。
• 覆蓋或者實現父類的方法時輸出結果可以被縮小。

依賴注入原則（Dependence Inversion Principle,DIP）

編程時要依賴于抽象，不要依賴于具體的實現。在應用程序中，所有的類如果使用或依賴于其他的類，則都應該依賴于這些其他類的抽象類（或接口），而不是依賴于這些其他類的具體實現類。

依賴注入原則需要注意的是：高層次模塊不應該依賴低層次模塊，即使用接口或抽象類進行變量的聲明、參數類型的聲明、方法返回類型的聲明、數據類型狀態等，而不要用具體實現類來做這些。

依賴注入的實現方式有三種：

• 通過構造函數傳遞依賴對象。
• 通過setter方法傳遞依賴對象。
• 接口聲明實現依賴對象。

接口分離原則（Interface Segregation Priciple,ISP）

不應該強迫客戶程序依賴它們不需要使用的方法。意思就是說，一個接口不需要提供太多的行為，一個接口應該只提供一種對外的功能，不應該把所以的操作都封裝到一個接口中。

在使用接口分離原則時需要注意幾點：

• 接口盡量小：這主要是為了保證一個接口只服務于一個子模塊或一類子模塊。
• 接口高內聚：接口高內聚是對內高度依賴，對外盡可能隔離。即一個接口內部聲明的方法相互之間都與某一個子模塊相關，且使這個模塊必需的。
• 接口設計是有限度的：如果完全遵循接口分離原則，接口粒度會越來越小，接口數量劇增，會導致系統復雜度大大增加，所以在設計接口時不應該一味的去分離接口。

迪米特原則（最少知識原則-LeastKonwledge Priciple,LKP）

一個軟件實體應該盡可能少的與其他軟件實體發生相互作用。就是說各個對象或各個類之間應該盡可能降低耦合，提高系統的可維護性。在模塊之間應該通過接口來通信，而不理會模塊的內部工作原理，它可以使各個模塊耦合度降到最低，促進軟件的復用。

設計模式類型

五個創建型設計模式

工廠方法模式（含簡單工廠，Factory Method Pattern）

抽象工廠模式（Abstract Factory Pattern）

單利模式（Singleton Pattern）

原型模式（Prototype Pattern）

建造者模式（Builder Pattern）

七個結構型設計模式

適配器模式（Adapter Pattern）

橋接模式（Bridge Pattern）

組合模式（Composite Pattern）

裝飾模式（Decorator Pattern）

外觀模式（Facade Pattern）

享元模式（Flyweight Pattern）

代理模式（Proxy Pattern）

十一個行為模式

責任鏈模式（Chain of Responsibility Pattern）

命令模式（Command Pattern）

解釋器模式（Interpreter Pattern）

迭代器模式（Iterator Pattern）

中介者模式（Mediator Pattern）

備忘錄模式（Memento Pattern）

觀察者模式（Observer Pattern）

狀態模式（State Pattern）

策略模式（Strategy Pattern）

模板方法模式（Template Method Pattern）

訪問者模式（Visitor Pattern）

這些模式的學習文章寫好后，會把鏈接賦到名稱后面的。這一篇文章也算是作為我設計模式學習的開篇吧，本來想直接寫簡單工廠模式的，但是后來發現要學設計模式需先把設計模式的來源以及遵循的原則搞清楚，所以就有了這么一個開篇文章，以后添加上了鏈接也可以作為我學習設計模式的文章的目錄。