掌握編程語言僅僅意味着掌握了如何給計算機“下命令”，而到底要計算機如何去做，怎么指揮，則是另一個問題——如何編程。設計模式是一套程序員的“武功套路”，它教我們如何去編程。雖然不遵守這個套路也是可以編程的，但是為了做到讓整支程序員軍團以整齊一致的步伐協調工作，設計模式的存在還是很有必要的。它定義了一系列的“武功套路”以及對應的招式的名稱，相當於制定好了行業內的一套規范以及術語，方便程序員軍團成員之間相互溝通。
GoF的23種設計模式
GoF是指Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides四個人，他們四個人被稱為Gang of Four，縮寫GoF。這四個人曾經合著過一本書《Design Patterns: Elements of Reusable Object-Oriented Software》，也就是大名鼎鼎的《設計模式》一書。此書流傳很廣，已經是程序員界的聖經之一了。這本書中介紹了23種設計模式，雖然設計模式其實不止這23種，但是由於這23種太常用了，所以我們一般說到設計模式，就是指GoF的23種設計模式。本文后續說的設計模式也將默認設計模式為GoF的23種設計模式。另外，我的第一語言是Java，Java也幾乎是OO界默認的語言，所以后續文章將使用Java。文章中出現的示例代碼將同步更新到java-design-pattern-samples項目。
六大原則
所有的設計模式都遵循以下六個基本的設計原則。
- 單一職責原則: The Single Responsibility Principle(SRP)
- 開放封閉原則: The Open Closed Principle(OCP)
- 里氏替換原則: The Liskov Substitution Principle(LSP)
- 迪米特法則: The law of Demeter(LD)
- 接口隔離原則: The Interface Segregation Principle(ISP)
- 依賴倒置原則: The Dependency Inversion Principle(DIP)
六大設計原則取其英文首字母簡稱為SOLID原則。( ′◔ ‸◔`) 咦！不是六大原則嗎！為啥縮寫只有五個字母！
這個。。。我還真不知道！或許是把里氏替換原則和迪米特法則的兩個L合並成一個更好看吧！如果有知道原因的朋友可以在博客中留言告訴我！
單一職責原則
一個類只做一件事情，不要去做與這個類的主要職責無關的事情。
開放封閉原則
對擴展開放，對修改關閉。簡單的說就是類或者接口定義好之后不可進行破壞性的更新！如果沒有bug，或者修改類、接口不是為了改進內部實現機制就不應該去修改這個類。開閉原則的目的是為了保持類或者接口后續版本能夠向后兼容，這是一個最根本的原則。開閉原則是六大原則中最重要的一個，算是一個總原則吧！
雖然理論上我們應該嚴格遵守開閉原則，不過現實往往沒有那么理想化。任何一個軟件在設計的時候都無法預料到后續發展中的所有需求，所以現實情況是修改幾乎不可避免。比如Java8中為了stream加了個毀三觀的default方法，這就是一個活生生的例子。我們只能在進行設計的時候盡可能的去遵守這些原則！
和我一起在心里默念幾次程序員聖經中的上帝指示：對擴展開放，對修改關閉！對擴展開放，對修改關閉！對擴展開放，對修改關閉！
里氏替換原則
所有父類可以出現的地方，都可以透明的用子類替換。也就是說，子類可以擴展父類，但是不可以修改父類的原有功能。子類 is a 實現 of 父類。
迪米特法則
迪米特法則又叫最少知識原則Least Knowledge Principle(LKP)，意思是一個類應該對他自己所依賴的類知道的越少越好！我們的目標是：沒有蛀牙！😃 開玩笑的！應該是：高內聚，低耦合。
接口隔離原則
使用多個小的更具體的接口比使用一個臃腫的接口要更好！也就是說，優雅的程序需要精心呵護，所以為了保護她，我們應該鄙視太粗的接口，應該喜歡細一點的接口。😃 我知道你們在想什么，不過本司機指的不是你想的那個意思！
細一點的接口有利於重構！😃 原則就是被用來違反的！對修改關閉？怎么可能！誰寫的代碼可以一步到位永久不修改的嗎！
另外細一點的接口也有利於客戶端遵守最少知識原則。
依賴倒置原則
不要依賴具體實現，要依賴抽象！也就是面向“接口”編程而不是面向實現類編程！這樣做可以解除客戶端與實現類的耦合。
六大設計原則總結
開閉原則要求我們寫好的類不要去修改，如果需要增加功能，那么擴展它。單一職責原則要求我們一個類只做一件事情。里氏替換原則要求我們子類必須兼容父類。迪米特法則要求我們盡可能少的依賴其他的類。接口隔離原則要求我們定義接口的時候盡可能簡單一些。依賴倒置原則要求我們不能去依賴實現類！
設計模式分類
GoF23種設計模式一般分為三大類。
創建型模式
除此之外，簡單工廠模式(Simple Factory)應該也算。不過為了湊整23個模式，就不放到列表里了。
結構型模式
- 適配器模式(Adapter)
- 外觀模式(Facade)
- 享元模式(Flyweight)
- 組合模式(Composite)
- 裝飾器模式(Decorator)
- 代理模式(Proxy)
- 橋接模式(Bridge)
行為型模式
- 策略模式(Strategy)
- 狀態模式(State)
- 職責鏈模式(Chain of Responsibility)
- 觀察者模式(Observer)
- 模板方法模式(Template Method)
- 命令模式(Command)
- 備忘錄模式(Memento)
- 迭代器模式(Iterator)
- 調停者模式(Mediator)
- 解釋器模式(Interpreter)
- 訪問者模式(Visitor)
上述設計模式有鏈接的表示已經寫好了介紹的文章，可以直接戳鏈接去看對應的文章。