最近一直在想著學(xué)習(xí)設(shè)計(jì)模式，這里說(shuō)的是面向?qū)ο箢I(lǐng)域的模式，找了些資料看了看，昨天也剛買了那本經(jīng)典作品：設(shè)計(jì)模式－可復(fù)用面向?qū)ο筌浖幕A(chǔ)，只是看了下引言就收獲很多，在這里把自己所能理解到的一些點(diǎn)點(diǎn)滴記錄下來(lái)，算是自己的復(fù)習(xí)，也希望給大家一點(diǎn)幫助，希望能與大家多多交流學(xué)習(xí)，小弟感激不盡！以下這些是自己感覺挺有意義。今天只是做個(gè)簡(jiǎn)單開篇，ＧＯ！

　　可復(fù)用面向?qū)ο蟮能浖O(shè)計(jì)的基礎(chǔ)！！從題目中我們可以看到它是在講軟件設(shè)計(jì)，而且是在面向?qū)ο蟮念I(lǐng)域中所涉及到的軟件設(shè)計(jì)問(wèn)題，設(shè)計(jì)的目的之一就是為了軟件方法的可復(fù)用性，當(dāng)然這里所講的只是一個(gè)軟件設(shè)計(jì)的一個(gè)基礎(chǔ)，重在思考，重在軟件設(shè)計(jì)思想的培養(yǎng)。

　　談起設(shè)計(jì)模式，也許成為了一個(gè)古老的話題，整天思考著怎樣去解決一個(gè)軟件系統(tǒng)的實(shí)現(xiàn)問(wèn)題，想著去寫可復(fù)用、可擴(kuò)展的的模塊，如果沒有軟件的這些特殊性，特別是從時(shí)間角度來(lái)考慮軟件的變化性，就這一點(diǎn)就決定著軟件必須要面對(duì)和解決的一個(gè)不可逃避的問(wèn)題，如果沒有這些特殊性也許它（設(shè)計(jì)模式）不會(huì)被這么重視，而且應(yīng)用設(shè)計(jì)模式也是有一定的代價(jià)，比如會(huì)設(shè)計(jì)更多的類，類與類之間的關(guān)系還要去了解等，也許對(duì)于軟件開發(fā)的初學(xué)者（當(dāng)然我也是^-^）來(lái)說(shuō)學(xué)習(xí)這方面會(huì)有難度，因?yàn)榻?jīng)驗(yàn)少的原因，因?yàn)檐浖O(shè)計(jì)思想沒有更好的培養(yǎng)等這些主觀因素，當(dāng)然這也是需要學(xué)習(xí)的原因了，設(shè)計(jì)模式不單單是書中講的這２３種，還有很多其他的，不過(guò)我感覺掌握這些模式的要領(lǐng)也不容易了，哈哈。

　　自己的理解，設(shè)計(jì)模式它不僅僅是一種算法，更是一種可以解決重復(fù)問(wèn)題的思想論，它是可以應(yīng)用在一些特定場(chǎng)合來(lái)解決特定的軟件問(wèn)題的有效方法，相同的，也許處在別的環(huán)境中可能它并不是一個(gè)好的解決方法，或許它還會(huì)給軟件帶來(lái)累贅，所以不能亂用設(shè)計(jì)模式，要“對(duì)口”，所以在實(shí)現(xiàn)設(shè)計(jì)模式的原則中提出一條就是使用重構(gòu)來(lái)實(shí)現(xiàn)模式，當(dāng)然也有非常有經(jīng)驗(yàn)有遇見性的設(shè)計(jì)大師或者一些很明顯的應(yīng)用模式的問(wèn)題。

　　每一個(gè)模式都描述了在軟件開發(fā)中不斷重復(fù)發(fā)生的問(wèn)題，以及該問(wèn)題的解決方案的核心，在以后的開發(fā)中就可以有經(jīng)驗(yàn)的來(lái)復(fù)用這種模式。所以每個(gè)模式都有一個(gè)對(duì)整個(gè)過(guò)程有概括性的模式名稱，現(xiàn)在想一下這２３種設(shè)計(jì)模式，這些名稱還真是起得相當(dāng)?shù)暮?#xff01;！在每個(gè)模式中都有四個(gè)要素，分別是：模式名稱、問(wèn)題、解決方案、效果。還是那句，正確使用模式的話會(huì)給軟件系統(tǒng)帶來(lái)絕對(duì)好的擴(kuò)展性和靈活性，應(yīng)用不好的話效果可想而知。

　　要學(xué)習(xí)設(shè)計(jì)模式，在這里不得不提的重中之重就是面向?qū)ο蟮母拍?#xff0c;大家說(shuō)的抽象、封裝、繼承、多態(tài)，我想在腦袋中都刻成碑了！但重要的是要去理解這些概念，把這些概念＂立體化＂。

如果說(shuō)設(shè)計(jì)模式夠抽象，那一些設(shè)計(jì)原則更是體現(xiàn)在了模式的身上，也許大家都知道，在這里就簡(jiǎn)單的列一下：

　　１、針對(duì)接口編程而不是針對(duì)實(shí)現(xiàn)編程。我們說(shuō)繼承是可復(fù)用的擴(kuò)展的基本機(jī)制，繼承可以很好的實(shí)現(xiàn)實(shí)現(xiàn)代碼與客戶的有效分離，使得客戶程序不必了解具體實(shí)現(xiàn)，而實(shí)現(xiàn)只管它自己的事，在遇到可變性的問(wèn)題時(shí)我只去擴(kuò)展或進(jìn)行少許改變就可以應(yīng)對(duì)軟件需求的變化（當(dāng)然這是在設(shè)計(jì)模式應(yīng)用合理的情況下。），這也就把職責(zé)進(jìn)行了分離，在這些設(shè)計(jì)模式中大量用到了接口（我們說(shuō)承繼分為類繼承與接口繼承，都知道吧，呵呵）。

　　２、優(yōu)先使用對(duì)象組合，而不是類繼承。上面剛說(shuō)完接口多么的好，確實(shí)，繼承實(shí)現(xiàn)了接口、類之間的可復(fù)用性與擴(kuò)展性，但深刻考慮下，這種繼承其實(shí)暗暗的造成了接口與實(shí)現(xiàn)之間的耦合關(guān)系，我們也稱之為白箱復(fù)用，也就是說(shuō)繼承的類與類之間是相互了解的，所以在這里如果接口層要進(jìn)行需求更改的話這些所以的關(guān)系都要進(jìn)行一個(gè)復(fù)雜的改變，當(dāng)然這個(gè)可以去解決，這也是這個(gè)原則存在的意義，使用對(duì)象組合，我們說(shuō)這種關(guān)系是類與類之間的一種松耦合的實(shí)現(xiàn)方式，我們稱之為黑箱復(fù)用，可以實(shí)現(xiàn)好的擴(kuò)展性，在后面的結(jié)構(gòu)型模式中把這種思想體現(xiàn)的非常秒！

　　在這里需要肯定的一點(diǎn)是，繼承與組合二者缺一不可，我們沒有理由說(shuō)誰(shuí)好誰(shuí)壞，所有的應(yīng)用都是根據(jù)軟件的特點(diǎn)來(lái)決定的。

　　３、使用重構(gòu)的方式得到模式。這一條我是從李建中老師的講義上看到的，非常的有道理，可以說(shuō)所有的模式都是經(jīng)過(guò)不斷的演變重構(gòu)而成的，開發(fā)過(guò)程中不定會(huì)遇到什么樣的問(wèn)題，所以盲目的應(yīng)用模式其實(shí)是對(duì)模式的一種不正確的使用，反而不會(huì)對(duì)軟件的開發(fā)帶來(lái)好處。

　　以下列出了更具體的原則供大家參考：

　　１、單一職責(zé)原則。這一原則體現(xiàn)了一個(gè)類只存在一個(gè)使它變化的原因，把類設(shè)計(jì)的職責(zé)很復(fù)雜看著就頭暈！！！

　　２、開放封裝原則。這里提到的就是我們說(shuō)的類是不可修改的，是可擴(kuò)展的，雖然這樣說(shuō)，不過(guò)我是遇到就改。。哎。。。

　　３、Liskov替換原則。子類必須能夠替換它們的父類．

　　４、依賴倒置原則。具體的說(shuō)明：高層模塊不應(yīng)該領(lǐng)帶于低層模塊，二者都應(yīng)該領(lǐng)帶于抽象。抽象不應(yīng)該依賴于實(shí)現(xiàn)細(xì)節(jié)，實(shí)現(xiàn)細(xì)節(jié)應(yīng)該依賴于抽象。沒得說(shuō)，這條絕對(duì)重要！！

　　５、接口隔離原則。這條原則告訴我們不應(yīng)該把接口設(shè)計(jì)的非常復(fù)雜，只能去定義自己功能的抽象，子類不應(yīng)該實(shí)現(xiàn)它不用的抽象。

　　大體的就是這幾個(gè)，當(dāng)然還有別的一些原則了。如果說(shuō)設(shè)計(jì)模式是絕世武功的招術(shù)，那這些原則就是心法了，可謂無(wú)招勝有招呀！哈哈！！

　　突然想到書中介紹了一個(gè)在我們身邊非常經(jīng)典的組合模式的應(yīng)用，窗體這個(gè)容器的實(shí)現(xiàn)，把一對(duì)多的關(guān)系實(shí)現(xiàn)成一對(duì)一的關(guān)系去解決問(wèn)題，窗體容器即裝載容器控件，也可以裝載葉控件，而內(nèi)部的容器控件又可以嵌套更多的子、葉控件！

　　就這些了，有空再寫具體的，以上有不合理的地方還請(qǐng)大家多指教！Over.

轉(zhuǎn)載于:https://www.cnblogs.com/quluqi/archive/2010/01/29/1659495.html

總結(jié)

以上是生活随笔為你收集整理的初步认识设计模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。