自從計算機誕生以來，生產效率大大的提高，尤其是微型計算機能夠進入千家萬戶。讓大眾能夠利用強大的計算資源，但是單純的計算機硬體雖然能夠提供機械強大的計算能力，但是要有效的利用這樣的能力就需要用軟體去操作，就像不同國家的人說著不同的語言，我們需要通過翻譯才能夠順利溝通，同樣計算機也需要明白人類需要它做什麼事情，所以計算機對應的語言就叫做機器語言即一般來說的二進位制編碼。這是一種跟人類語言相差很大的語言，雖然能夠輕鬆並且高效的被計算機識別，當時的情況是這樣的，使用者需要藉助計算機來完成某項計算活動必須找到指定的編碼人員，然後編碼人員將對應的運算操作翻譯成計算機指令編碼（紙帶卡片輸入計算機系統），隨著計算機的廣泛應用，早期的計算機使用的高門檻阻礙了計算機的推廣，因此出現了一些更加靠近人類能夠識別的指令系統，例如組合語言，組合語言經過彙編器能夠翻譯成機器能夠看懂的機器碼，降低了計算機使用者的門檻，後來還出現了更加接近人類的高階語言，例如C語言（嚴格意義C語言算中級語言，手動管理記憶體），還有更加高階的Java語言。
面向物件分析（OOA）是更加貼近人類思維模式的程式語言，以Java C++ 為代表的面嚮物件語言（OOP）一直是現代軟體開發的主流語言，由於相關歷史原因（主要是獲得開源社群的支援），由此延伸出的相關技術與工具也蓬勃發展。作為軟體開發的重要環節，面向物件設計的重要性不言而喻，軟體的構建過程本質上就是從現實世界抽象的過程，使用面向物件技術構建軟體架構就是為一個系統開始規劃輪廓，具體的細節應該可以靈活的變動或者是可以新增新的抽象元件與細節。面向物件設計要考慮具體的業務需求場景，但是在大量前人的實踐面前，總結出了一套設計的規範，這些規範大量運用在一些優秀的架構中，更確切的說在大量的架構設計的結果發現很多設計是有一些共同點的，這些共同點被總結成精煉的思想，為了便於開發者交流，我們起名叫做設計模式。
軟體被視為知識密集型產品，一個軟體產品從使用者需求到一個成熟穩定的產品最重要是在對需求的把握並作出良好的設計，抽象的事物往往是穩定的，從現實世界到軟體世界的主要過程就是在於抽象出產品對應的實體，而軟體架構即是這樣的重要成果。架構往往分為業務架構和技術架構，業務架構需要懂得業務的人根據使用者場景組織現有的產品形態，業務架構更多是需要人去組織並執行，技術架構也面臨著一樣的需求，但是技術架構往往面臨的是各種產品與技術的銜接。技術與業務缺一不可，因此在軟體抽象建模的過程中往往面臨著的大的業務場景是不同的，但是在複雜的業務往往都具有很多相似的小的功能需求。獨立出這些功能點，設計模式能夠幫助我們在面臨類似需求的場景作出專家級的解決方案，不用過多去重複的做出一些不太明確的設計。但是設計模式只是一個指導性規範，不會要求使用者強制使用，為了模式而模式而忽視業務場景，往往導致過度設計這是捨本逐末。如果以面向物件的思想看待軟體產品，從具體到抽象，可以發現對應的層次是在例項 -> 類 -> 抽象類 -> 介面 -> 框架 -> 模式,越趨於抽象的東西也就愈加穩定，同理學習各種技術的態度也應該是學習它的本質，而不應該浮於表面，在學校就應該好好學習資料結構和作業系統原理、彙編原理等等課程，越靠近產品（例如web前端）各種技術迭代更新越快，而計算機通訊的二進位制傳輸，幾十年都不會變化，linux核心雖然有更新，但是都是向下相容，不會有太大的改動，考慮到linux應用的廣泛因此學習linux相比追求新潮的技術是更加保值的。甚至曾經有人說道學習設計模式的最好方式就是“學習完就忘掉它”，我們看待設計模式應該抱著學習它本身的思想，而不應該拘泥於具體的案例。設計不僅僅要考慮到當前，大量的網際網路應用的產生，很多情況下是不能預知未來的產品走向，很多時候軟體的開端並沒有明確的需求，因此我們需要作出具有前瞻性的系統設計，在極端的情況下“反模式”甚至在有的時候是最佳解決方案，這依賴於具體的業務場景。模式幫助我們節省設計的時間，作為一種比較標準的參考方案，提升設計的效率重點內容質量。
設計模式被明確的提出是上世紀90年代的《GOF可複用面向物件設計》，大名鼎鼎的四人幫的著作，文中明確的指出了大量存在於各個面向物件設計中的23種設計模式，這些模式被大量的實踐並且證明是十分優秀的設計。本部落格也將詳細介紹這23種設計模式。接下來將以分五個章節講解設計模式的相關內容，第一章節主要介紹了設計模式的起源以及設計模式的意義。
23種設計模式：
1、Abstract Factory (抽象工廠模式)
提供一個建立一系列產品或相互依賴物件介面無需指定具體的類。

2、Adapter (介面卡模式)
將一個類的介面轉換成客戶希望的另一個介面，Adapter使原本由於介面不相容而不能正常工作的類可以正常工作。

3、Bridge (橋接模式)
將抽象部分與實現部分分離，使它們可以獨立變化。

4、Build (建造者模式)
將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。

5、Chaine of Responsibility (責任鏈模式)
為接觸請求的傳送者和接受者之間的耦合，而使多個物件都有機會處理這個請求。將這些物件連成一條鏈，並沿著這條連傳遞該請求，知道有一個物件處理。

6、Command (命令模式)
將一個請求封裝為一個物件，從而使可以用不同的請求對客戶進行引數化，對請求排隊或記錄請求日誌，以及支援可取消操作。

7、Composite (組合模式)
將物件組合成樹形結構以表示 “部分-整體”的層次結構。它使得客戶對單個物件和符合物件的使用具有一致性。

8、Decator (裝飾模式)
動態地給一個物件新增一些額外的職責，就擴充套件功能而言，它比生成子類方式更加靈活。

9、Facade (外觀模式)
為子系統中的一組介面提供一個一致的介面，Facade模式定義一個高層介面，這個介面使得這一子系統更加容易使用。

10、Factory Method (工廠方法模式)
定義一個建立物件的介面，讓子類決定將哪一個類例項化。使一個類例項化延遲到子類。

11、Flyweight (享元模式)
運用共享技術有效支援大量細粒度物件。

12、Intecepter (直譯器模式)
給定一個語言，定義它的文法的一種表示，並定義一個直譯器，該直譯器使用該表示來解釋語言中句子。

13、Iterator (迭代器模式)
提供一種方法順序訪問一個聚合物件中各個元素而又不暴露該物件內部表示。

14、Mediator (中介者模式)
用一箇中介物件來封裝一系列物件互動，中介者使各物件不需要顯示的相互引用，從而使得其耦合鬆散，而且可以獨立的改變他們之間的互動。

15、Memento (備忘錄模式)
在補破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態，這樣以後就可將該物件回覆到儲存的狀態。

16、Observer (觀察者模式)
定義物件間的一種一對多的依賴關係，以便當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知並自動重新整理。

17、Prototype (原型模式)
用原型例項指定建立物件的種類，並且通過拷貝這個原型來建立新的物件。

18、Proxy (代理模式)
為其他物件提供一個代理以控制對這個物件的訪問。

19、Singleton (單例模式)
保證一個類僅有一個例項，並提供一個訪問它的全域性訪問。

20、State (狀態模式)
允許一個物件在其內部狀態改變時改變它的行為，物件看起來似乎屬於一個新的類。

21、Stratege (策略模式)
定義一系列演算法，把他們封裝起來，並且使它們可以相互替換，本模式使得演算法的變化可以獨立與使用它的客戶端。

22、Template Method (模板方法模式)
定義一個操作中的演算法骨架，而將一些步驟延遲到子類，Template Method使得子類可以不改變一個演算法結構即可重新定義該演算法某些特定步驟。

23、Visitor (訪問者模式)
表示一個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。