C#設計模式開啓闖關之路

前言背景

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

關卡模式詳細介紹

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

　　此本祕籍分爲三大部分：

1、建立型模式

2、結構型模式

3、行爲型模式

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

第一章　單例模式（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）表明了最佳的實踐，一般被有經驗的面向對象的軟件開發人員所採用。設計模式是軟件開發人員在軟件開發過程當中面臨的通常問題的解決方案。這些解決方案是衆多軟件開發人員通過至關長的一段時間的試驗和錯誤總結出來的。

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

　　示例代碼下載——GitHub

闖關必備條件

　　話說以前有講到面向對象三大特性——封裝、繼承、多態。也有講到面向對象設計SOLID五大原則。今天咱們也將開啓設計模式的闖關之路。其中到底有沒有聯繫呢？到底有沒有關係呢？

　　事實上面向對象三大特性在必定程度上體現了面向對象設計的五大原則。那麼與設計模式又有什麼關係呢。其實面向對象設計的五大原則也可稱爲設計模式五大原則。學習設計模式以前咱們都得先了解其原則，學習其基礎。在此基礎之上學習設計模式纔是最好的。

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

1、單一責任原則（SRP）

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

2、開放封閉原則（OCP）

開放封閉原則指的是程序模塊應該遵循關閉修改，開放擴展。

3、里氏替換原則（LSP）

子類型必須可替代其基類型 –一個對象出現的地方均可以由其子類代替而且不會出錯，便是符合里氏替換原則的。

4、接口分離原則（ISP）

接口分離原則—client不該該被強迫依賴它不使用的方法，代表方法是分開或者隔離的。

5、依賴倒置原則（DIP）

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

 

總結開啓闖關之路

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

　　生命不息、戰鬥不止!

歡迎你們掃描下方二維碼，和我一塊兒踏上設計模式的闖關之路吧!