Java設計模式學習記錄-GoF設計模式概述

前言

最近要開始學習設計模式了，之前是偶爾會看看設計模式的書或是在網上翻到了某種設計模式，就順便看看，也沒有仔細的學習過。前段時間看完了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）

 

 

 

 

這些模式的學習文章寫好後，會把連接賦到名稱後面的。這一篇文章也算是做爲我設計模式學習的開篇吧，原本想直接寫簡單工廠模式的，可是後來發現要學設計模式需先把設計模式的來源以及遵循的原則搞清楚，因此就有了這麼一個開篇文章，之後添加上了連接也能夠做爲我學習設計模式的文章的目錄。