前言背景

　　這是一條望不到盡頭的程式設計之路，自踏入程式設計之路開始。就面臨著各式各樣的挑戰，而我們也需要不斷的挑戰自己、不斷學習充實自己、打好堅實的基礎。以使我們可以走的更遠。剛踏入程式設計的時候。根據需求程式設計，需求改程式碼改。需求加程式碼加。重複來重複去。一切都覺得還不錯。功能實現了，專案跑起來了。但是真的就不錯了嗎？當然不是，也許過了幾年你再回頭看這些程式碼或許你也不知道寫的啥了。這樣寫出來的程式碼你自己都可能看不到，更何況其他人呢？對吧。偶爾一次闖入一處祕境。發現了一本名叫”設計模式”的”武功”祕籍。也是程式設計之路之上不可獲取的能力之一。它解決了程式碼重複使用，程式碼冗餘的問題。使程式碼結構簡潔易懂。使程式碼的思路清晰明瞭。程式碼優美，結構完善合理。我們一起看看這個至高的祕籍。

關卡模式詳細介紹

　　下面我們看看此祕籍具體到底有些啥。放心、絕對不會像那啥”欲練神功必先自宮”一般的祕籍了。

　　此本祕籍分為三大部分：

一、建立型模式

二、結構型模式

三、行為型模式

　　第一部分的建立型模式共分為：

第一章　單例模式（Singleton）

保證一個類僅有一個例項，全域性呼叫。該模式是將物件建立的數量控制為一個。

第二章　工廠方法模式（Factory Method）

工廠模式講究的是一個工廠對應一個產品的模式，平行的等級結構，這裡重點針對”單個物件”的變化

第三章　抽象工廠模式（Abstract Factory）

抽象工廠模式關注的更多是多系列的或相互依賴的產品變化，提供一個建立一系列相關或相互依賴物件的介面，無需指定它們的類。

第四章　建造者模式（Builder）

該模式解決的主要是”一個複雜物件”的建立工作的問題，各個子物件組合一個複雜物件。組合的演算法穩定，子物件易變化的情況

第五章　原型模式（Prototype）

通過原型例項來建立物件，然後通過拷貝原型來建立新物件

第二部分的結構型模式共分為：

第六章　介面卡模式（Adapter）

該模式主要關注的是介面轉換的問題，將匹配的介面通過適配對接工作

第七章　橋接模式（Bridge）

該模式關注的是分離介面與其具體實現，使其變化獨立

第八章　裝飾模式（Decorator）

該模式關注的是動態的給物件增加一些額外的職責，穩定介面不變。此模式比生成子類繼承更加的靈活

第九章　組合模式（Composite）

將物件組合成樹形結構以表示“部分-整體”的層次結構，它使得客戶對單個物件和複合物件的使用具有一致性。

第十章　外觀模式（Facade）

該模式關注的是簡化介面，簡化元件系統與外部程式的依賴關係。

第十一章　享元模式（Flyweight）

該模式注重保留介面，在內部使用共享技術對物件儲存進行優化

第十二章　代理模式（Proxy）

對其他物件提供一種物件來控制對這個物件的訪問。

第三部分的行為型模式共分為：

第十三章　模版方法模式（Template Method）

該模式關注對演算法結構的封裝，定義穩定的演算法結構，但是支援允許演算法子步驟的變化。

第十四章　命令模式（Command）

將一個請求封裝為一個物件，從而使你可用不同的請求對客戶（客戶程式，也是行為的請求者）進行引數化；對請求排隊或記錄請求日誌，以及支援可撤銷的操作。命令模式的實現可以提供命令的撤銷和恢復功能。

第十五章　迭代器模式（Iterator）

提供一種方法順序訪問一個聚合物件中的各個元素，而又不暴露該物件的內部表示。

第十六章　觀察者模式（Observer）

定義物件間的一種一對多的依賴關係，以便當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知並自動更新。

第十七章　中介者模式（Mediator）

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

第十八章　狀態模式（State）

允許一個物件在其內部狀態改變時改變它的行為。從而使物件看起來似乎修改了其行為。

第十九章　策略模式（Strategy）

定義一系列演算法，把它們一個個封裝起來，並且使它們可互相替換。該模式使得演算法可獨立於使用它的客戶而變化。

第二十章　職責鏈模式(責任鏈模式--Chain of Responsibility)

避免請求傳送者與接收者耦合在一起，讓多個物件都有可能接受請求，將這些物件連線成一條鏈，並且沿著這條鏈傳遞請求，知道有物件處理它為止。

第二十一章　訪問者模式（Visitor）

表示一個作用於某物件結構中的各個元素的操作。它可以在不改變各元素的類的前提下定義作用於這些元素的新的操作。

第二十二章　備忘錄模式（Memento）

在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到儲存的狀態。

第二十三章　直譯器模式（Interpreter）

給定一個語言，定義它的文法的一種表示，並定義一種直譯器，這個直譯器使用該表示來解釋語言中的句子。

　　設計模式（Design pattern）代表了最佳的實踐，通常被有經驗的面向物件的軟體開發人員所採用。設計模式是軟體開發人員在軟體開發過程中面臨的一般問題的解決方案。這些解決方案是眾多軟體開發人員經過相當長的一段時間的試驗和錯誤總結出來的。

 　　設計模式是一套被反覆使用的、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。

闖關必備條件

　　話說之前有講到面向物件三大特性——封裝、繼承、多型。也有講到面向物件設計SOLID五大原則。今天我們也將開啟設計模式的闖關之路。其中到底有沒有聯絡呢？到底有沒有關係呢？

　　事實上面向物件三大特性在一定程度上提現了面向物件設計的五大原則。那麼與設計模式又有什麼關係你。其實面向物件設計的五大原則也可稱為設計模式五大原則。學習設計模式之前我們都得先了解其原則，學習期基礎。在此基礎之上學習設計模式才是最好的。

　　這裡再次簡單介紹設計模式的五大原則（SOLID）：

一、單一責任原則（SRP）

單一責任原則指出當需要修改某個類的時候原因有且只有一個。也就是說一個類應該只負責一件事情。

二、開放封閉原則（OCP）

開放封閉原則指的是程式模組應該遵循關閉修改，開放擴充套件。

三、里氏替換原則（LSP）

子型別必須可替代其基型別 –一個物件出現的地方都可以由其子類代替並且不會出錯，即是符合里氏替換原則的。

四、介面分離原則（ISP）

介面分離原則—client不應該被強迫依賴它不使用的方法，表明方法是分開或者隔離的。

五、依賴倒置原則（DIP）

依賴倒置原則-也是最後一個原則了。其原則指出—一個高階模組不應依賴於低階模組，兩個都應該取決於抽象。抽象不應該依賴具體細節，細節應該依賴於抽象。

總結開啟闖關之路

　　打好基礎，學習瞭解其設計的原則，學習設計模式必須在其原則的基礎上學習。學習設計模式的路並不平穩，在起初之期，比較多的概念規則都不是很清楚、基礎不紮實。會給學習之路帶來諸多麻煩。學習理解之後我們也需要更多的思考。選擇合適的設計模式使用，寧可不用、切勿亂用。用的好那麼皆大歡喜普天同樂。可是用不好的話也有可能下一個祭天的就是你了。設計模式需要許多的模式實踐。接下來的時間之中我們即將開啟C#設計模式的闖關之路了。

　　生命不息、戰鬥不止!

歡迎大家掃描下方二維碼，和我一起踏上設計模式的闖關之路吧!

&n