1. 程式人生 > >設計模式:總結

設計模式:總結

外觀模式 interface 使用 image enter 代理 inversion 實現 發布訂閱

設計模式總結

一、設計模式分類

2.1、按類型分為:

創建型模式:工廠方法抽象工廠模式原型模式單例模式建造者模式

結構型模式:適配器組合模式裝飾器模式橋接模式外觀模式FlyWeight模式代理模式

行為型模式:叠代器模板方法策略模式仲裁者模式訪問者模式命令模式解釋器模式觀察者模式責任鏈模式狀態模式備忘錄模式

2.2、設計模式的幾種原則:

1、開閉原則(Open Close Principle)
2、裏氏代換原則(Liskov Substitution Principle)
3、依賴倒轉原則(Dependence Inversion Principle)
4、接口隔離原則(Interface Segregation Principle)
5、迪米特法則(最少知道原則)(Demeter Principle)
6、合成復用原則(Composite Reuse Principle)

2.3、設計模式關系

技術分享圖片

二、設計模式感想

呼,長出了一口氣,很久以前就對設計模式癡迷至深,奈何第一沒有好的資料,第二很多東西看了就忘,沒能好好的整理下來,如今想想也是個遺憾。前幾天突然萌生了寫一下設計模式這樣的想法,現有的文章和資料很多,能夠寫完這些設計模式,網上的資料,以及一些書籍對我的幫助都很大,可以說這23中設計模式,我是一邊學習一邊寫出來的,這些程序在書本的啟發之下都是我自己一點點寫出來的,沒有參考任何的資料,所以理解的還比較深。就我而言,到了現在差不多十天左右的時間,對於設計模式可謂是有了更深層次的認識。其實設計模式這個詞匯也是翻譯過來的最成功的一個詞匯之一。在我們的程序設計之中,就是應該有這樣的高屋建瓴的架構和模式才能使得我們的程序更加的具有復用性和擴展性。仔細思考這23種設計模式,可以說都是為了提高代碼的可讀性、可擴展性、可復用性、類的可替換性、組件化、可移植性

等等特性。通過接口、抽象類、繼承、實現、委托、抽象、面向抽象(接口)編程、多態、重載、重寫等方式使得代碼的這些特性得以彰顯,可以說只有深刻的理解了這些概念背後的哲學思想才能更好地理解設計模式。在設計模式之中也有很多的思想,比如可以使用委托的不要使用繼承、開閉原則,面向擴展開放,面向修改關閉,裏氏代換原則,父類一定能被子類代替並使用,反之則不然,面向抽象(接口)編程,功能層次和實現層次分離(橋接模式)、高內聚低耦合等思想,這些思想都是寶貴的,正是因為這樣的思想的存在才使得代碼的更新換代的時候能夠盡可能少的甚至不用修改以前的代碼,直接加入新的內容。提高軟件的開發周期,便於維護和升級,便於查找和糾錯,易於擴展和使用。

同樣的設計模式主要分為三大類,創建型的、行為型的、結構型的,我們可以簡單的這樣分類,只不過這樣的分類似乎並不準確,不能一語道出所有的本質,因為我前面就說過,設計模式是相互關聯的,有的設計模式內部其實是使用了別的設計模式作為支撐的,但是大體上這樣的一種劃分便於我們去記憶,僅此而已。

仔細的回顧一下我們前面學習的設計模式,看看我們能想到多少,從叠代器開始,我們將類中數據結構的遍歷和類的功能實現分離出來,本質上使用了工廠模式。其次我們學習了適配器模式,它將不同的接口進行適配,從而便於版本的兼容性以及其他功能,然後我們學習了模板方法,使用模板面向抽象編程,便於新的子類的實現和管理;之後是工廠方法,其實借用了模板方法來創建產品,是一種非常重要用處很廣的一種方法;然後我們學習了單例模式,有懶漢式、餓汗式等,生成關於某個類全局唯一的對象,註意多線程的影響;之後是原型模式,用來復制復雜的對象,使用了clone方法,然後是Builder模式,用一個新的類對已有的抽象接口進行整合和編程,從而構建出我們想要的東西;然後是抽象工廠模式,使用了工廠模式,組合模式等模式,面向抽象編程,將抽象零件組裝成抽象產品,便於具體工廠的創建,提高了代碼的組件化和復用性;然後是橋接模式,將類的功能層次和實現層次分割開來,便於對應的擴展和使用;然後是策略模式,可以整體的替換策略,使用也很廣泛;然後是組合模式,保證了同根同源(一致性、透明性),聽過委托添加自己構成遞歸,樹形結構,將具有樹形特點的對象組合起來;然後是裝飾器模式,和組合模式的結構類似,同樣是遞歸結構,從而可以不斷地裝飾,增加新的功能,很有用;接著是Visitor訪問者模式,通過在類外訪問類中的數據結構從而得到想要的結果,便於程序的可擴展性和組件化。接著是責任鏈模式,推卸責任,根據問題的大小來考慮自己是否要處理,本質是鏈表,便於職責分明;然後是外觀模式,通過整合各個類之間的調用關系,組建成了統一的接口(API),便於外部類的調用;接著是仲裁者模式,將很多類之間互相關聯的關系交給仲裁者去處理,省去了各個類之間的嵌套和調用,有利於高內聚和低耦合,思路清晰,便於擴展;然後是觀察者模式,或者叫做發布訂閱模式,通過互相委托從而能夠在被觀察的類發生改變的時候得到相應的改變的信息並且處理;然後是備忘錄模式,將對象在某一時刻的狀態保存下來,便於恢復,在遊戲中使用的很多;接著是狀態模式,將狀態當做類,從而職責分明,解除了很多繁瑣的if和else這些分支邏輯,便於擴展。然後是FlyWeight模式,輕量級對象,通過共用不變對象來實現,然後是Proxy代理模式,懶加載真正的服務器,加快訪問速度,代理是幫助服務器代理的;然後是命令模式,將命令當做類,通過保存一些列命令,從而能夠隨時執行這些命令,需要清楚命令的本質就是一些操作和數據。最後是解釋器模式,利用編譯原理的方法,來更高層次的封裝代碼,將自己開發的Java代碼當做編譯系統,從而不用修改Java代碼只修改更高語言層次的代碼就能實現不同的功能。這就是我們的設計模式。

設計模式:總結