C#設(shè)計(jì)模式開啟闖關(guān)之路

前言背景


　　這是一條望不到盡頭的編程之路，自踏入編程之路開始。就面臨著各式各樣的挑戰(zhàn)，而我們也需要不斷的挑戰(zhàn)自己、不斷學(xué)習(xí)充實(shí)自己、打好堅(jiān)實(shí)的基礎(chǔ)。以使我們可以走的更遠(yuǎn)。剛踏入編程的時(shí)候。根據(jù)需求編程，需求改代碼改。需求加代碼加。重復(fù)來(lái)重復(fù)去。一切都覺得還不錯(cuò)。功能實(shí)現(xiàn)了，項(xiàng)目跑起來(lái)了。但是真的就不錯(cuò)了嗎？當(dāng)然不是，也許過(guò)了幾年你再回頭看這些代碼或許你也不知道寫的啥了。這樣寫出來(lái)的代碼你自己都可能看不到，更何況其他人呢？對(duì)吧。偶爾一次闖入一處秘境。發(fā)現(xiàn)了一本名叫”設(shè)計(jì)模式”的”武功”秘籍。也是編程之路之上不可獲取的能力之一。它解決了代碼重復(fù)使用，代碼冗余的問(wèn)題。使代碼結(jié)構(gòu)簡(jiǎn)潔易懂。使代碼的思路清晰明了。代碼優(yōu)美，結(jié)構(gòu)完善合理。我們一起看看這個(gè)至高的秘籍。

關(guān)卡模式詳細(xì)介紹

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

　　此本秘籍分為三大部分：

一、創(chuàng)建型模式

二、結(jié)構(gòu)型模式

三、行為型模式

　　第一部分的創(chuàng)建型模式共分為：

第一章　單例模式（Singleton）
<https://www.cnblogs.com/hulizhong/p/11399634.html#_label1_0>

保證一個(gè)類僅有一個(gè)實(shí)例，全局調(diào)用。該模式是將對(duì)象創(chuàng)建的數(shù)量控制為一個(gè)。

第二章　工廠方法模式（Factory Method） <https://www.cnblogs.com/hulizhong/p/11404514.html>

工廠模式講究的是一個(gè)工廠對(duì)應(yīng)一個(gè)產(chǎn)品的模式，平行的等級(jí)結(jié)構(gòu)，這里重點(diǎn)針對(duì)”單個(gè)對(duì)象”的變化

第三章　抽象工廠模式（Abstract Factory）
<https://www.cnblogs.com/hulizhong/p/11413450.html>

抽象工廠模式關(guān)注的更多是多系列的或相互依賴的產(chǎn)品變化，提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，無(wú)需指定它們的類。

第四章　建造者模式（Builder） <https://www.cnblogs.com/hulizhong/p/11419220.html>

該模式解決的主要是”一個(gè)復(fù)雜對(duì)象”的創(chuàng)建工作的問(wèn)題，各個(gè)子對(duì)象組合一個(gè)復(fù)雜對(duì)象。組合的算法穩(wěn)定，子對(duì)象易變化的情況

第五章　原型模式（Prototype） <https://www.cnblogs.com/hulizhong/p/11434123.html>

通過(guò)原型實(shí)例來(lái)創(chuàng)建對(duì)象，然后通過(guò)拷貝原型來(lái)創(chuàng)建新對(duì)象

第二部分的結(jié)構(gòu)型模式共分為：

第六章　適配器模式（Adapter） <https://www.cnblogs.com/hulizhong/p/11436206.html>

該模式主要關(guān)注的是接口轉(zhuǎn)換的問(wèn)題，將匹配的接口通過(guò)適配對(duì)接工作

第七章　橋接模式（Bridge） <https://www.cnblogs.com/hulizhong/p/11448067.html>

該模式關(guān)注的是分離接口與其具體實(shí)現(xiàn)，使其變化獨(dú)立

第八章　裝飾模式（Decorator） <https://www.cnblogs.com/hulizhong/p/11454474.html>

該模式關(guān)注的是動(dòng)態(tài)的給對(duì)象增加一些額外的職責(zé)，穩(wěn)定接口不變。此模式比生成子類繼承更加的靈活

第九章　組合模式（Composite） <https://www.cnblogs.com/hulizhong/p/11459943.html>

將對(duì)象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)，它使得客戶對(duì)單個(gè)對(duì)象和復(fù)合對(duì)象的使用具有一致性。

第十章　外觀模式（Facade） <https://www.cnblogs.com/hulizhong/p/11466500.html>

該模式關(guān)注的是簡(jiǎn)化接口，簡(jiǎn)化組件系統(tǒng)與外部程序的依賴關(guān)系。

第十一章　享元模式（Flyweight） <https://www.cnblogs.com/hulizhong/p/11498136.html>

該模式注重保留接口，在內(nèi)部使用共享技術(shù)對(duì)對(duì)象存儲(chǔ)進(jìn)行優(yōu)化

第十二章　代理模式（Proxy） <https://www.cnblogs.com/hulizhong/p/11506759.html>

對(duì)其他對(duì)象提供一種對(duì)象來(lái)控制對(duì)這個(gè)對(duì)象的訪問(wèn)。

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

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

該模式關(guān)注對(duì)算法結(jié)構(gòu)的封裝，定義穩(wěn)定的算法結(jié)構(gòu)，但是支持允許算法子步驟的變化。

第十四章　命令模式（Command）

將一個(gè)
請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可用不同的請(qǐng)求對(duì)客戶（客戶程序，也是行為的請(qǐng)求者）進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可撤銷的操作。命令模式的實(shí)現(xiàn)可以提供命令的撤銷和恢復(fù)功能。

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

提供一種方法順序訪問(wèn)一個(gè)聚合對(duì)象中的各個(gè)元素，而又不暴露該對(duì)象的內(nèi)部表示。

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

定義對(duì)象間的一種一對(duì)多的依賴關(guān)系，以便當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知并自動(dòng)更新。

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

用一個(gè)中介對(duì)象來(lái)封裝一系列的對(duì)象交互。中介者使各對(duì)象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。

第十八章　狀態(tài)模式（State）

允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變它的行為。從而使對(duì)象看起來(lái)似乎修改了其行為。

第十九章　策略模式（Strategy）

定義一系列算法，把它們一個(gè)個(gè)封裝起來(lái)，并且使它們可互相替換。該模式使得算法可獨(dú)立于使用它的客戶而變化。

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

避免請(qǐng)求發(fā)送者與接收者耦合在一起，讓多個(gè)對(duì)象都有可能接受請(qǐng)求，將這些對(duì)象連接成一條鏈，并且沿著這條鏈傳遞請(qǐng)求，知道有對(duì)象處理它為止。

第二十一章　訪問(wèn)者模式（Visitor）

表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各個(gè)元素的操作。它可以在不改變各元素的類的前提下定義作用于這些元素的新的操作。

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

在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣以后就可將該對(duì)象恢復(fù)到保存的狀態(tài)。

第二十三章　解釋器模式（Interpreter）

給定一個(gè)語(yǔ)言，定義它的文法的一種表示，并定義一種解釋器，這個(gè)解釋器使用該表示來(lái)解釋語(yǔ)言中的句子。

?

　　設(shè)計(jì)模式（Design
pattern）代表了最佳的實(shí)踐，通常被有經(jīng)驗(yàn)的面向?qū)ο蟮能浖_發(fā)人員所采用。設(shè)計(jì)模式是軟件開發(fā)人員在軟件開發(fā)過(guò)程中面臨的一般問(wèn)題的解決方案。這些解決方案是眾多軟件開發(fā)人員經(jīng)過(guò)相當(dāng)長(zhǎng)的一段時(shí)間的試驗(yàn)和錯(cuò)誤總結(jié)出來(lái)的。

?　　設(shè)計(jì)模式是一套被反復(fù)使用的、多數(shù)人知曉的、經(jīng)過(guò)分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。

　　示例代碼下載——GitHub <https://github.com/hulizong/-Design_Patterns>

闖關(guān)必備條件

　　話說(shuō)之前有講到面向?qū)ο笕筇匦浴庋b、繼承、多態(tài)。也有講到面向?qū)ο笤O(shè)計(jì)SOLID五大原則
<https://www.cnblogs.com/hulizhong/p/10785646.html>
。今天我們也將開啟設(shè)計(jì)模式的闖關(guān)之路。其中到底有沒有聯(lián)系呢？到底有沒有關(guān)系呢？


　　事實(shí)上面向?qū)ο笕筇匦栽谝欢ǔ潭壬象w現(xiàn)了面向?qū)ο笤O(shè)計(jì)的五大原則。那么與設(shè)計(jì)模式又有什么關(guān)系呢。其實(shí)面向?qū)ο笤O(shè)計(jì)的五大原則也可稱為設(shè)計(jì)模式五大原則。學(xué)習(xí)設(shè)計(jì)模式之前我們都得先了解其原則，學(xué)習(xí)其基礎(chǔ)。在此基礎(chǔ)之上學(xué)習(xí)設(shè)計(jì)模式才是最好的。

　　這里再次簡(jiǎn)單介紹設(shè)計(jì)模式的五大原則（SOLID）：

一、單一責(zé)任原則（SRP）

單一責(zé)任原則指出當(dāng)需要修改某個(gè)類的時(shí)候原因有且只有一個(gè)。也就是說(shuō)一個(gè)類應(yīng)該只負(fù)責(zé)一件事情。

二、開放封閉原則（OCP）

開放封閉原則指的是程序模塊應(yīng)該遵循關(guān)閉修改，開放擴(kuò)展。

三、里氏替換原則（LSP）

子類型必須可替代其基類型?–一個(gè)對(duì)象出現(xiàn)的地方都可以由其子類代替并且不會(huì)出錯(cuò)，即是符合里氏替換原則的。

四、接口分離原則（ISP）

接口分離原則—client不應(yīng)該被強(qiáng)迫依賴它不使用的方法，表明方法是分開或者隔離的。

五、依賴倒置原則（DIP）

依賴倒置原則-也是最后一個(gè)原則了。其原則指出—一個(gè)高級(jí)模塊不應(yīng)依賴于低級(jí)模塊，兩個(gè)都應(yīng)該取決于抽象。抽象不應(yīng)該依賴具體細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。

?

總結(jié)開啟闖關(guān)之路


　　打好基礎(chǔ)，學(xué)習(xí)了解其設(shè)計(jì)的原則，學(xué)習(xí)設(shè)計(jì)模式必須在其原則的基礎(chǔ)上學(xué)習(xí)。學(xué)習(xí)設(shè)計(jì)模式的路并不平穩(wěn)，在起初之期，比較多的概念規(guī)則都不是很清楚、基礎(chǔ)不扎實(shí)。會(huì)給學(xué)習(xí)之路帶來(lái)諸多麻煩。學(xué)習(xí)理解之后我們也需要更多的思考。選擇合適的設(shè)計(jì)模式使用，寧可不用、切勿亂用。用的好那么皆大歡喜普天同樂。可是用不好的話也有可能下一個(gè)祭天的就是你了。設(shè)計(jì)模式需要許多的模式實(shí)踐。接下來(lái)的時(shí)間之中我們即將開啟C#設(shè)計(jì)模式的闖關(guān)之路了。

　　生命不息、戰(zhàn)斗不止!

歡迎大家掃描下方二維碼，和我一起踏上設(shè)計(jì)模式的闖關(guān)之路吧!

　　

?

• ? 上一篇：記一次神奇的sql查詢經(jīng)歷，group by慢查詢優(yōu)化
• ? 下一篇： AliOS Things手勢(shì)識(shí)別應(yīng)用演示