类设计原则及设计模式(一篇就够)
類設計原則及設計模式
- 類設計的六大原則
- 設計模式定義
- 設計模式的分類
- 創建型模式
- 1. 簡單工廠和工廠方法模式
- 定義和分類
- 2. 抽象工廠模式
- 3. 單例模式
- 定義
- 優缺點
- 餓漢式單例與懶漢式單例類比較
- 代碼實現
- 4. 建造者模式
- 5. 原型模式
- 結構型模式
- 適配器模式
- 代理模式
- 核心角色
- 分類
- 代理模式的應用場景
- 代碼實現
- 橋接模式
- 橋接模式核心要點
- 橋接模式總結
- 橋接模式實際開發中應用場景
- 代碼實現
- 組合模式
- 使用組合模式的場景
- 組合模式的核心
- 開發中的應用場景
- 代碼實現
- 裝飾模式
- 實現細節
- 職責
- 裝飾器模式和橋接模式的區別
- 代碼實現
- 外觀模式
- 外觀模式核心
- 開發中常見的場景
- 代碼實現
- 享元模式
- 場景
- 核心
- 享元模式實現
- 享元模式開發中應用的場景
- 代碼實現
- 行為型模式
- 策略模式
- 場景
- 本質
- 開發中常見的場景
- 代碼實現
- 模版方法模式
- 核心
- 什么時候用到模版方法模式
- 開發中常見的場景
- 代碼實現
- 觀察者模式
- 核心
- 通知觀察者的方式
- 開發中常見的場景
- 代碼實現
- 迭代子模式
- 場景
- 結構
- 開發中常見的場景
- 代碼實現
- 責任鏈模式
- 開發中常見的場景
- 代碼實現
- 命令模式
- 結構
- 開發中常見的場景
- 代碼實現
- 備忘錄模式
- 核心
- 結構
- 開發中常見的應用場景
- 代碼實現
- 狀態模式
- 場景
- 結構
- 開發中常見的場景
- 代碼實現
- 訪問者模式
- 模式動機:
- 開發中的場景(應用范圍非常少,了解即可)
- 中介者模式
- 核心
- 中介者模式的本質
- 開發中常見的場景
- 代碼實現
- 解釋器模式
- 介紹
- 開發中常見的場景
- 并發設計模式
- Furture模式
- 生產者消費者模式
- 參考文獻
- 參考
類設計的六大原則
在阿里巴巴的設計規范中有提到類的設計原則,內容就是以下幾點
開閉原則就是說對擴展開放,對修改關閉。在程序需要進行拓展的時候,不能去修改原有的代碼,實現一個熱插拔的效果。所以一句話概括就是:為了使程序的擴展性好,易于維護和升級。想要達到這樣的效果,我們需要使用接口和抽象類,后面的具體設計中我們會提到這點。它是說我們在實現一個新功能時,首先應該想到的是擴展原來的功能,而不是修改之前的功能。
這個設計思想非常重要,也是一名優秀工程師所必備的設計思想。至于為什么要這樣做?其實非常簡單,我們團隊在開發后端接口時遵循的也是這個理念。
隨著軟件越做越大,對應的客戶端版本也越來越多,而這些客戶端都是安裝在用戶的手機上。因此我們不能保證所有用戶手中的 App(客戶端)都一直是最新版本的,并且也不能每次都強制用戶進行升級或者是協助用戶去升級,那么我們在開發新功能時,就強制要求團隊人員不允許直接修改原來的老接口,而是要在原有的接口上進行擴展升級。
因為直接修改老接口帶來的隱患是老版本的 App 將不能使用,這顯然不符合我們的要求。那么此時在老接口上進行擴展無疑是最好的解決方案,因為這樣我們既可以滿足新業務也不用擔心新加的代碼會影響到老版本的使用。
里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說,任何基類可以出現的地方,子類一定可以出現。 LSP是繼承復用的基石,只有當衍生類可以替換掉基類,軟件單位的功能不受到影響時,基類才能真正被復用,而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現,所以里氏代換原則是對實現抽象化的具體步驟的規范。
這個是開閉原則的基礎,具體內容:針對接口編程,依賴于抽象而不依賴于具體。
這個原則的意思是:使用多個隔離的接口,比使用單個接口要好。還是一個降低類之間的耦合度的意思,從這兒我們看出,其實設計模式就是一個軟件的設計思想,從大型軟件架構出發,為了升級和維護方便。所以上文中多次出現:降低依賴,降低耦合。
為什么叫最少知道原則,就是說:一個實體應當盡量少的與其他實體之間發生相互作用,使得系統功能模塊相對獨立。
原則是盡量使用合成/聚合的方式,而不是使用繼承。
設計模式定義
設計模式(Design pattern)是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問,設計模式于己于他人于系統都是多贏的,設計模式使代碼編制真正工程化,設計模式是軟件工程的基石,如同大廈的一塊塊磚石一樣。項目中合理的運用設計模式可以完美的解決很多問題,每種模式在現在中都有相應的原理來與之對應,每一個模式描述了一個在我們周圍不斷重復發生的問題,以及該問題的核心解決方案,這也是它能被廣泛應用的原因。本章系Java之美[從菜鳥到高手演變]系列之設計模式,我們會以理論與實踐相結合的方式來進行本章的學習,希望廣大程序愛好者,學好設計模式,做一個優秀的軟件工程師!
23種模式java實現源碼下載地址 http://pan.baidu.com/share/link?shareid=372668&uk=4076915866#dir/path=%2F%E5%AD%A6%E4%B9%A0%E6%96%87%E4%BB%B6
設計模式的分類
總體來說設計模式分為三大類:
其實還有兩類:并發型模式和線程池模式。用一個圖片來整體描述一下:
創建型模式
創建型模式是指提供了一種對象創建的功能,并把對象創建的過程進行封裝隱藏,讓使用者只關注具體的使用而并非對象的創建過程。它包含的設計模式有單例模式、工廠模式、抽象工廠模式、建造者模式及原型模式。
1. 簡單工廠和工廠方法模式
定義和分類
工廠方法模式實現了創建者和調用者的分離。
詳細分類:
工廠方法模式包含的角色:
Product:抽象產品
ConcreteProduct:具體產品
Factory:抽象工廠
ConcreteFactory:具體工廠
說明:在工廠方法模式中,核心的工廠類不再負責所有產品的創建,而是把這個過程交給子類去做。從而更好地符合“開閉原則”。
應用舉例:在實際開發中,一般將具體工廠類的實例化過程進行改進,不直接使用new 關鍵字來創建對象,而是將具體類的類名寫入配置文件中,再通過java的反射機制,讀取XML格式的配置文件,根據存儲在XML文件中的類名字符串聲稱對象。
延伸:java反射(java reflection)
是指在程序運行時獲取已知名稱的類或已有對象的相關信息的一種機制,包括類的方法、屬性、超類等信息。還包括實例的創建和實例類型的判斷等等。可通過Class類的forName()方法返回與帶有給定字符串名的類或者接口相關聯的Class對象,再通過newInstance()方法創建此對象所表示的類的一個新實例。即:通過一個類名字符串得到類的實例。
優點:完全符合“開閉原則"。
缺點:需要編寫新的具體產品類,而且還要提供與之對應的具體工廠類,系統中類的個數將成對增加。增加了系統的抽象性和理解難度。
使用情況:
(1)一個類不知道它所需要的對象的類。
(2)一個類通過其子類來指定創建哪個對象。
(3)將創建的對象的任務委托給多個工廠子類中某一個。
2. 抽象工廠模式
模式動機:
(1)多個位于不同產品等級結構中屬于不同類型的具體產品時需要使用抽象工廠模式。
(2)它是工廠模式中最為抽象和最具一般性的一種形態。
(3)工廠方法模式針對的是一個產品等級結構,而抽象工廠模式則需要面對多個產品等級結構。
抽象工廠模式包含的角色:
AbstractFactory:抽象工廠
ConcreteFactory:具體工廠
AbstractProduct:抽象產品
Product:具體產品
優點:
(1)抽象工廠模式隔離了具體類的生成,只需改變具體工廠的實例,就可以在某種程度上改變整個軟件系統的行為。
(2)可以實現高內聚低耦合的設計目的。
(3)增加新的具體工廠和產品族很方便,無須修改已有系統,符合“開閉原則”。
缺點:
(1)難以擴展抽象工廠來生產新種類的產品。
(2)開閉原則的傾斜性(增加新的工廠和產品族容易,增加新的產品等級結構麻煩)
使用環境:
(1)有多于一個的產品族。屬于同一個產品族的產品將在一起使用。
(2)所有的產品以同樣的接口出現。
3. 單例模式
定義
定義一個全局變量可以確保對象隨時都可以被訪問,但不能防止我們實例化多個對象。一個更好的解決辦法是讓類自身負責保存它的唯一實。
單例模式:確保某一個類只有一個實例,而且自行實例化并向整個系統提供這個實例。
單例模式要點:
(1)某個類只能有一個實例。
(2)它必須自行創建這個實例。
(3)它必須自行向整個系統提供這個實例。
模式分析:
(1)單例類的構造函數為私有。
(2)提供一個自身的靜態私有成員變量。
(3)提供一個公有的靜態工廠方法。
優缺點
優點:
(1)提供了對唯一實例的受控訪問。
(2)可以節約系統資源。
(3)允許可變數目的實例。
缺點:
(1)由于單例模式中沒有抽象層,因此單例類的擴展有很大的困難。
(2)單例類的職責過重,在一定程度上違背了“單一職責原則”。
單例模式的優點很明顯,可以有效地節約內存,并提高對象的訪問速度,同時避免重復創建和銷毀對象所帶來的性能消耗,尤其是對頻繁創建和銷毀對象的業務場景來說優勢更明顯。然而單例模式一般不會實現接口,因此它的擴展性不是很好,并且單例模式違背了單一職責原則,因為單例類在一個方法中既創建了類又提供類對象的復合操作,這樣就違背了單一職責原則,這也是單例模式的缺點所在。
餓漢式單例與懶漢式單例類比較
餓漢式單例類在自己被加載時就將自己實例化。
(1)從資源利用,比懶漢式差。
(2)從速度和反應時間來講,則比懶漢式稍微好些。
(3)懶漢式單例類在實例化時,必須處理好多個線程同時首次引用此類時的訪問限制問題。
通過單例模式的學習告訴我們:
1、單例模式理解起來簡單,但是具體實現起來還是有一定的難度。
2、synchronized關鍵字鎖定的是對象,在用的時候,一定要在恰當的地方使用(注意需要使用鎖的對象和過程,可能有的時候并不是整個對象及整個過程都需要鎖)。
到這兒,單例模式基本已經講完了,結尾處,筆者突然想到另一個問題,就是采用類的靜態方法,實現單例模式的效果,也是可行的,此處二者有什么不同?
首先,靜態類不能實現接口。(從類的角度說是可以的,但是那樣就破壞了靜態了。因為接口中不允許有static修飾的方法,所以即使實現了也是非靜態的)
其次,單例可以被延遲初始化,靜態類一般在第一次加載是初始化。之所以延遲加載,是因為有些類比較龐大,所以延遲加載有助于提升性能。
再次,單例類可以被繼承,他的方法可以被覆寫。但是靜態類內部方法都是static,無法被覆寫。
最后一點,單例類比較靈活,畢竟從實現上只是一個普通的Java類,只要滿足單例的基本需求,你可以在里面隨心所欲的實現一些其它功能,但是靜態類不行。從上面這些概括中,基本可以看出二者的區別,但是,從另一方面講,我們上面最后實現的那個單例模式,內部就是用一個靜態類來實現的,所以,二者有很大的關聯,只是我們考慮問題的層面不同罷了。兩種思想的結合,才能造就出完美的解決方案,就像HashMap采用數組+鏈表來實現一樣,其實生活中很多事情都是這樣,單用不同的方法來處理問題,總是有優點也有缺點,最完美的方法是,結合各個方法的優點,才能最好的解決問題!
代碼實現
package com.swad.designpattern.singleton;/*** Created by gonghaiyu on 13/02/2017.* 測試餓漢式單例模式*/ public class SingletonDemo1 {//加載類時,線程是安全的private static SingletonDemo1 instance = new SingletonDemo1();//類初始化時立即加載private SingletonDemo1(){}//方法沒有同步,效率高public static SingletonDemo1 getInstance(){return instance;} } package com.swad.designpattern.singleton;/*** Created by gonghaiyu on 13/02/2017.* 測試懶漢式單例模式*/ public class SingletonDemo2 {private static SingletonDemo2 instance;private SingletonDemo2(){}//方法同步調用效率低!synchronized 可以移動到函數內部,實現雙重鎖單例模式public static synchronized SingletonDemo2 getInstance(){if(instance==null){instance = new SingletonDemo2();}return instance;} } package com.swad.designpattern.singleton;/*** Created by gonghaiyu on 13/02/2017.* 測試靜態內部類實現單例模式* 這種方式:線程安全,調用效率高,并且實現類延遲加載!*/ public class SingletonDemo4 {private static class SingletonClassInstance{private static final SingletonDemo4 instance = new SingletonDemo4();}private SingletonDemo4(){}public static SingletonDemo4 getInstance(){return SingletonClassInstance.instance;} } package com.swad.designpattern.singleton;/*** Created by gonghaiyu on 13/02/2017.* 測試懶漢式單例模式(如何防止反射和凡序列化漏洞)*/ public class SingletonDemo6 {private static SingletonDemo6 instance;private SingletonDemo6(){if(instance!=null){throw new RuntimeException();}}//方法同步調用效率低!synchronized 可以移動到函數內部,實現雙重鎖單例模式public static synchronized SingletonDemo6 getInstance(){if(instance==null){instance = new SingletonDemo6();}return instance;} } package com.swad.designpattern.singleton;import java.lang.reflect.Constructor;/*** Created by gonghaiyu on 13/02/2017.*/ public class Client2 {public static void main(String[] args) throws Exception{SingletonDemo1 s1 = SingletonDemo1.getInstance();SingletonDemo1 s2 = SingletonDemo1.getInstance();System.out.println(s1);System.out.println(s2);Class<SingletonDemo6> clazz = (Class<SingletonDemo6>) Class.forName("com.swad.singleton.SingletonDemo6");Constructor<SingletonDemo6> c = clazz.getDeclaredConstructor(null);c.setAccessible(true);SingletonDemo6 s3 =c.newInstance();SingletonDemo6 s4 =c.newInstance();System.out.println(s3);System.out.println(s4);} }4. 建造者模式
模式動機:復雜對象相當于一輛有待建設的汽車,而對象的屬性相當于汽車的部件。建造者返還給客戶端的是一個已經建造完畢的完整產品對象,而用戶無須關心該對象所包含的屬性已經它們的組裝方式。
建造者模式的角色:
Builder:抽象建造者
ConcreteBuilder:具體建造者
Director:指揮者
Product:產品角色
優點:
(1)客戶端不必知道產品內部組成的細節,將產品本身與產品的創建過程解耦,使得相同的創建過程可以創建不同的產品對象。
(2)新增的具體建造者無須修改原有類庫的代碼,指揮者類針對抽象建造者類編程,符合開閉原則。
缺點:
(1)建造者模式所創建的產品一般具有較多的共同點,其組成部分相似,如果產品之間的差異性很大,則不適合使用建造者模式,因此其使用范圍受到一定的限制。
建設者模式與抽象工廠模式的比較:
與抽象工廠模式相比,建造者模式返回一個組裝好的完整產品,而抽象工廠模式返回一系列相關的產品,這些產品位于不同的產品等級結構,構成了一個產品族。
在抽象工廠模式中,客戶端實例化工廠類,然后調用工廠方法獲取所需產品對象,而在建造者模式中,客戶端可以不直接調用建造者的相關方法,而是通過指揮者類來指導如何生成對象,包括對象的組裝過程和建造步驟,它側重于一步步構造一個復雜對象,返回一個完整的對象。
工廠類模式提供的是創建單個類的模式,而建造者模式則是將各種產品集中起來進行管理,用來創建復合對象,所謂復合對象就是指某個類具有不同的屬性,其實建造者模式就是前面抽象工廠模式和最后的Test結合起來得到的。我們看一下代碼:
還和前面一樣,一個Sender接口,兩個實現類MailSender和SmsSender。最后,建造者類如下:
測試類:
public class Test {public static void main(String[] args) {Builder builder = new Builder();builder.produceMailSender(10);} }從這點看出,建造者模式將很多功能集成到一個類里,這個類可以創造出比較復雜的東西。所以與工程模式的區別就是:工廠模式關注的是創建單個產品,而建造者模式則關注創建符合對象,多個部分。因此,是選擇工廠模式還是建造者模式,依實際情況而定。
5. 原型模式
(1)提供的Ctrl+C與Ctrl+V操作就是原型模式的應用,復制得到的對象與原型對象是兩個類型但是內存地址不同的對象,通過原型模式可以大大提高對象的創建效率。
(2)在Struts2中為了保證線程的安全性,Action對象的創建使用了原型模式。訪問一個已經存在的Action對象時將通過克隆的方式創建出一個新的對象,從而保證其中定義的變量無須進行加鎖實現同步,每一個Action中都有自己的成員變量,避免Struts1因使用單例模式而導致的并發和同步問題。
(3)Spring中,也采用原型模式來創建新的bean實例。
原型模式雖然是創建型的模式,但是與工程模式沒有關系,從名字即可看出,該模式的思想就是將一個對象作為原型,對其進行復制、克隆,產生一個和原對象類似的新對象。本小結會通過對象的復制,進行講解。在Java中,復制對象是通過clone()實現的,先創建一個原型類:
很簡單,一個原型類,只需要實現Cloneable接口,覆寫clone方法,此處clone方法可以改成任意的名稱,因為Cloneable接口是個空接口,你可以任意定義實現類的方法名,如cloneA或者cloneB,因為此處的重點是super.clone()這句話,super.clone()調用的是Object的clone()方法,而在Object類中,clone()是native的,具體怎么實現,我會在另一篇文章中,關于解讀Java中本地方法的調用,此處不再深究。在這兒,我將結合對象的淺復制和深復制來說一下,首先需要了解對象深、淺復制的概念:
淺復制:將一個對象復制后,基本數據類型的變量都會重新創建,而引用類型,指向的還是原對象所指向的。
深復制:將一個對象復制后,不論是基本數據類型還有引用類型,都是重新創建的。簡單來說,就是深復制進行了完全徹底的復制,而淺復制不徹底。
此處,寫一個深淺復制的例子:
要實現深復制,需要采用流的形式讀入當前對象的二進制輸入,再寫出二進制數據對應的對象。
但需要注意的是,以上代碼為淺克隆的實現方式,如果要實現深克隆(對所有屬性無論是基本類型還是引用類型的克隆)可以通過以下手段實現:
結構型模式
結構型模式關注的是對象的結構,它是使用組合的方式將類結合起來,從而可以用它來實現新的功能。
7種結構型模式:適配器模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。其中對象的適配器模式是各種模式的起源,我們看下面的圖:
適配器模式
適配器模式
將一份類的接口轉換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不兼容而不能在一起工作。
模式中的角色
目標接口(Target):客戶所期待的接口。目標可以是具體的或抽象的類,也可是接口。
需要適配的類(Adaptee):需要適配的類或適配者類。
適配器(Adapter):通過包裝一個需要適配的對象,把原接口轉換為目標接口。
分類
主要分為三類:類的適配器模式、對象的適配器模式、接口的適配器模式。
類的適配器模式:當希望將一個類轉換成滿足另一個新接口的類時,可以使用類的適配器模式,創建一個新類,繼承原有的類,實現新的接口即可。
對象的適配器模式:當希望將一個對象轉換成滿足另一個新接口的對象時,可以創建一個Wrapper類,持有原類的一個實例,在Wrapper類的方法中,調用實例的方法就行。
接口的適配器模式:當不希望實現一個接口中所有的方法時,可以創建一個抽象類Wrapper,實現所有方法,我們寫別的類的時候,繼承抽象類即可。
工作場景
3.1 經常用來做舊系統改造和升級
3.2 如果我們的系統開發之后再也不需要維護,那么很多模式都是沒有必要的,但是不幸的是,事實卻是維護一個系統的代價往往是開發一個系統的數倍。
我們學習中見過的場景
1.java.io.InputStreamReader(InputStream)
2.java.io.OutputStreamWriter(OutputStream)
3.JDBC給出了一個客戶端通用的抽象接口,每一個具體數據引擎的JDBC驅動軟件都是一個介于JDBC接口和數據庫引擎接口之間的適配器軟件。
4.在Spring AOP框架中,對BeforeAdvice,AfterAdvice,ThrowsAdvice三種通知類借助于適配器來實現。
代碼實現
代理模式
核心角色
1.抽象角色 定義代理角色和真是角色的公共對外方法 2.真實角色 實現抽象角色、定義真實角色所要實現的業務邏輯,供代理角色調用。 3.代理角色 實現抽象角色,是真是角色的代理,通過真實角色的業務邏輯方法來實現抽象方法,并可以附加自己的操作。將統一的流程控制放到代理角色中處理!分類
靜態代理:(代碼寫死的代理類)
動態代理:(動態生成代理類,代碼自動生成代理類)
1.JDK自帶的動態代理
2.javaassist字節碼操作庫實現
3.CGLIB
4.ASM(底層使用指令,可維護性較差)
動態代理:
JDK自帶的動態代理
1.java.lang.reflect.Proxy
作用:動態生成代理類和對象
2.java.lang.reflect.InvocationHandler(處理器接口)
2.1可以通過invoke方法實現對真實角色的代理訪問。
2.2每次通過Proxy生成代理類對象時都要指定對應的處理器對象
代理模式的應用場景
如果已有的方法在使用的時候需要對原有的方法進行改進,此時有兩種辦法:
1、修改原有的方法來適應。這樣違反了“對擴展開放,對修改關閉”的原則。
2、就是采用一個代理類調用原有的方法,且對產生的結果進行控制。這種方法就是代理模式。
使用代理模式,可以將功能劃分的更加清晰,有助于后期維護!
代碼實現
橋接模式
橋接模式:就像一座橋,將兩個變化維度連接起來,各個維度都可以獨立的變化。故稱:橋接模式。問題由商品分類問題引入。
橋接模式核心要點
處理多層繼承結構,處理多維度變化的場景,將各個維度設計成獨立的繼承結構,使各個維度可以獨立的擴展在抽象層建立關聯。
橋接模式總結
橋接模式可以取代多層繼承的方案。多層繼承違背了單一職責原則,復用性較差,類的個數也非常多。橋接模式可以極大的減少子類的個數,從而降低管理和維護成本。橋接模式極大的提高了系統的可擴展性,在兩個變化維度中任意擴展一個維度,都不需要修改原有的系統,符合開閉原則。橋接模式實際開發中應用場景
-JDBC驅動程序
- AWT中的Peer架構
-銀行日志管理:
格式分類:操作日志、交易日志、異常日志
距離分類:本地記錄日志、異地記錄日志
-人力資源系統中的獎金計算模塊:
獎金分類:個人獎金、團體獎金、激勵獎金
部門分類:人事部門、銷售部門、研發部門
-OA系統中的消息處理:
業務類型:普通消息、加急消息、特急消息
發送消息方式:系統內消息、手機短信、郵件
代碼實現
package com.swad.designpattern.proxy.bridge;public class Computer {protected Brand brand;public Computer(Brand b){this.brand = b;}public void sale(){brand.sale();} } class Desktop extends Computer{public Desktop(Brand b){super(b);}public void sale(){super.sale();System.out.println("銷售臺式機");} } class Laptop extends Computer{public Laptop(Brand b){super(b);}public void sale(){super.sale();System.out.println("銷售筆記本");} }package com.swad.designpattern.proxy.bridge;public interface Brand {void sale(); } class Lenovo implements Brand{@Overridepublic void sale() {System.out.println("銷售聯想電腦");} } class Dell implements Brand{@Overridepublic void sale() {System.out.println("銷售Dell電腦");} } package com.swad.designpattern.proxy.bridge;public class Client {public static void main(String[] args) {//銷售聯想筆記本電腦Computer c = new Laptop(new Lenovo());c.sale();} }組合模式
使用組合模式的場景
把部分和整體的關系用樹形結構來表示,從而使客戶端可以使用統一的方式處理部分對象和整體對象。
組合模式的核心
抽象構件(Component)角色:定義了葉子和容器構件的共同點葉子(Leaf)構件角色:無子節點容器(Composite)構件角色:有容器特征,可以包含子節點。
開發中的應用場景
-操作系統的資源管理器
-GUI中的容器層次圖
-XML文件解析
-OA系統中,組織結構的處理
-Junit單元測試框架
-將多個對象組合在一起進行操作,常用于表示樹形結構中,例如二叉樹,數等。
代碼實現
package com.swad.designpattern.composite;import java.util.ArrayList; import java.util.List;//抽象構件 public interface AbstractFile {void killVirus();//殺毒 } class ImageFile implements AbstractFile{private String name;public ImageFile(String name){super();this.name = name;}@Overridepublic void killVirus() {System.out.println("--圖像文件殺毒--"+name+",進行查殺!");} } class TextFile implements AbstractFile{private String name;public TextFile(String name){super();this.name = name;}@Overridepublic void killVirus() {System.out.println("--文本文件殺毒--"+name+",進行查殺!");} }class Folder implements AbstractFile{private String name;//定義容器,用來存放不同容器構件下的子節點private List<AbstractFile> list = new ArrayList<AbstractFile>();@Overridepublic void killVirus() {System.out.println("---文件夾:"+name+",進行查殺!");for(AbstractFile file:list){file.killVirus();}}public Folder(String name) {super();this.name = name;}public void add(AbstractFile file){list.add(file);}public void remove(AbstractFile file){list.remove(file);}public AbstractFile getChild(int index){return list.get(index);} }package com.swad.designpattern.composite; public class Client {public static void main(String[] args) {AbstractFile f2,f3,f4,f5,f6;Folder f1 = new Folder("我的收藏");f2 = new ImageFile("老高的大頭像.jpg");f3 = new TextFile("Hello.txt");f1.add(f2);f1.add(f3); // f2.killVirus();f1.killVirus();} }裝飾模式
實現細節
-Component抽象構件角色
真實對象和裝飾對象有相同的接口。這樣,客戶端對象就能夠以與真實對象相同的方式同裝飾對象交互。
-ConcreteComponent具體構件角色(真實對象):
.io流中的FileInputStream、FileOutputStream
-Decorator裝飾角色:
.持有一個抽象構件的引用。裝飾對象接受所有客戶端的請求,并把這些請求轉發給真實的對象。這樣,就能在真實對象調用前后增加新的功能。
-ConcreteDecorator具體裝飾角色:
.負責給構件對象增加新的責任。
職責
-動態的為一個對象增加新的功能。
-裝飾模式是一種用于代替繼承的技術,無須通過繼承增加子類就能擴展對象的新功能。動態的為一個對象增加功能,而且還能動態撤銷。(繼承不能做到這一點,繼承的功能是靜態的,不能動態增刪。)
使用對象的關聯關系代替繼承關系,更加靈活,同時避免類型體系的快速膨脹。
開發中使用的場景:
-IO中輸入流和輸出流的設計
-Swing包中圖形界面構件功能
-Servlet API中提供了一個request對象的Decorator設計模式的默認實現類HttpServletRequestWrapper,HttpServletRequestWrapper類,增強了request對象的功能。
-Struts2中,request,response,session對象的處理。
裝飾器模式和橋接模式的區別
兩個模式都是為了解決過多子類對象問題。但他們的誘因不一樣。橋接模式是對象自身現有機制沿著多個維度變化,是既有部分不穩定。裝飾模式是為了增加新的功能。
代碼實現
package com.swad.designpattern.decorator; public interface ICar {void move(); } //真實對象 class Car implements ICar{@Overridepublic void move() {System.out.println("陸地上跑");} } class SuperCar implements ICar{private ICar car;public SuperCar(ICar car) {super();this.car = car;}@Overridepublic void move() {car.move();} } class FlyCar extends SuperCar{public FlyCar(ICar car) {super(car);}public void fly(){System.out.println("天上飛");}@Overridepublic void move(){super.move();fly();} }class WaterCar extends SuperCar{public WaterCar(ICar car) {super(car);}public void swin(){System.out.println("水上游");}@Overridepublic void move(){super.move();swin();} }package com.swad.designpattern.decorator; public class Client {public static void main(String[] args) {Car car = new Car();car.move();System.out.println("增加新的功能,飛行。。。");FlyCar flycar = new FlyCar(car);flycar.move();System.out.println("增加兩個新的功能,飛行,水里游。。。");WaterCar watercar = new WaterCar(new FlyCar(car));watercar.move();} }外觀模式
外觀模式核心
為子系統提供統一的入口,封裝子系統的復雜性,便于客戶端調用。
開發中常見的場景
頻率很高,哪里都會遇到。各種技術和框架中,都有外觀模式的使用。如:
JDBC封裝后的,commons提供的DBUtils類,Hibernate提供的工具類、Spring JDBC 工具類等。
代碼實現
如果我們沒有Computer類,那么,CPU、Memory、Disk他們之間將會相互持有實例,產生關系,這樣會造成嚴重的依賴,修改一個類,可能會帶來其他類的修改,這不是我們想要看到的,有了Computer類,他們之間的關系被放在了Computer類里,這樣就起到了解耦的作用,這,就是外觀模式!
享元模式
場景
內存屬于稀缺資源,不要隨便浪費。如果有很多個完全相同或相似對象,我們可以通過享元模式,節省內存。通常與工廠模式一起使用。
核心
-享元模式以共享的方式高效地支持大量細粒度對象的重用。
-享元對象能做到共享的關鍵是區分了內部狀態和外部狀態。
? 內部狀態:可以共享,不會隨環境變化而改變。
? 外部狀態:不可以共享,會隨環境變化而改變。
享元模式實現
-FlyweightFactory享元工廠類? 創建并管理享元對象,享元池一般設計成鍵值對
-FlyWeigth抽象享元類
? 通常是一個接口或抽象類,聲明公共方法,這些方法可以向外界提供對象的內部狀態,設置外部狀態。
-ConcreteFlyWeight具體享元類
? 為內部狀態提供成員變量進行存儲
-UnsharedConcreteFlyWeight非共享享元類
? 不能被共享的子類可以設計為非共享享元類
享元模式開發中應用的場景
-享元模式由于其共享的特性,可以在任何“池”中操作,比如:線程池、數據庫連接池。-String類的設計也是享元模式代碼實現
package com.swad.designpattern.facade; /*** 外部狀態UnShared* @author gonghaiyu**/ public class Coordinate {private int x,y;public Coordinate(int x, int y) {super();this.x = x;this.y = y;}public int getX() {return x;}public void setX(int x) {this.x = x;}public int getY() {return y;}public void setY(int y) {this.y = y;} } package com.swad.designpattern.facade;public interface ChessFlyWeight {void setColor(String c);String getColor();void display(Coordinate c); }class ConcreteChess implements ChessFlyWeight{private String color;public ConcreteChess(String color) {super();this.color = color;}@Overridepublic void setColor(String c) {this.color = c;}@Overridepublic String getColor() {return color;}@Overridepublic void display(Coordinate c) {System.out.println("棋子顏色:"+color);System.out.println("棋子位置:"+c.getX()+"----"+c.getY());} } package com.swad.designpattern.facade;import java.util.HashMap; import java.util.Map;/*** 享元工廠類* @author gonghaiyu**/ public class ChessFlyWeightFactory {//享元池private static Map<String,ChessFlyWeight> map = new HashMap<String,ChessFlyWeight>();public static ChessFlyWeight getChess(String color){if(map.get(color)!=null){return map.get(color);}else{ChessFlyWeight cfw = new ConcreteChess(color);map.put(color, cfw);return cfw;}} } package com.swad.designpattern.facade;public class Client {public static void main(String[] args) {ChessFlyWeight chess1 = ChessFlyWeightFactory.getChess("黑色");ChessFlyWeight chess2 = ChessFlyWeightFactory.getChess("黑色");System.out.println(chess1);System.out.println(chess2);System.out.println("增加外部狀態的處理========");chess1.display(new Coordinate(10,10));chess2.display(new Coordinate(20,20));} }行為型模式
行為型模式關注的是對象的行為,它是把對象之間的關系進行梳理劃分和歸類。
行為型模式共11種:策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
先來張圖,看看這11中模式的關系:
第一類:通過父類與子類的關系進行實現。第二類:兩個類之間。第三類:類的狀態。第四類:通過中間類。
策略模式
場景
-某個市場人員接到單后的報價策略(CRM系統中常見問題)。報價策略很復雜,可以簡單作如下的分類:
? 普通客戶小批量報價
? 普通客戶大批量報價
? 老客戶小批量報價
? 老客戶大批量報價
-具體選用哪個報價策略,這需要根據實際情況來確定。這時候,我們采用策略模式即可。
本質
-分離算法,選擇實現開發中常見的場景
-JAVASE中GUI編程中,布局管理-spring框架中,resource接口,資源訪問策略-javax.servlet.http.HttpServlet#service()代碼實現
package com.swad.designpattern.strategy;public interface Strategy {public double getPrice(double standardPrice); } package com.swad.designpattern.strategy; /*** 負責和具體的策略類交互* 這樣的話,具體的算法和直接的客戶端調用分離了,* 使得算法可以獨立于客戶端獨立的變化* @author gonghaiyu**/ public class Context {private Strategy strategy;//當前采用的算法對象 //可以通過構造器來注入 public Context(Strategy strategy) {super();this.strategy = strategy; } //可以通過set方法注入 public void setStrategy(Strategy strategy) {this.strategy = strategy; } //打印價格 public void printPrice(double s){System.out.println("您該報價:"+strategy.getPrice(s)); } } package com.swad.designpattern.strategy;public class NewCustomerManyStrategy implements Strategy{@Overridepublic double getPrice(double standardPrice) {System.out.println("打九折");return standardPrice*0.9;} } package com.swad.designpattern.strategy;public class NewCustomerStrategy implements Strategy{@Overridepublic double getPrice(double standardPrice) {System.out.println("不打折");return standardPrice;} } package com.swad.designpattern.strategy;public class OldCustomerManyStrategy implements Strategy{@Overridepublic double getPrice(double standardPrice) {System.out.println("打八折");return standardPrice*0.8;} } package com.swad.designpattern.strategy;public class OldCustomerStrategy implements Strategy{@Overridepublic double getPrice(double standardPrice) {System.out.println("打八五折");return standardPrice*0.85;} } package com.swad.designpattern.strategy;public class Client {public static void main(String[] args) {Strategy s1 = new OldCustomerManyStrategy();Context ctx = new Context(s1);ctx.printPrice(1000);} } package com.swad.designpattern.strategy; /*** 實現起來比較容易,符合一般開發人員的思路* 假如,類型比較多,算法比較復雜時,整個條件語句的代碼就變得很長,難于維護* 如果有新增類型,就需要頻繁的修改此處的代碼!* 不符合開閉原則!* @author gonghaiyu**/ public class TestStrategy {public double getPrice(String type, double price){if (type.equals("普通客戶小批量")){System.out.println("不打折");return price;}else if(type.equals("普通客戶大批量")){System.out.println("打九折");return price * 0.9;}else if(type.equals("老客戶小批量")){System.out.println("打八五折");return price * 0.85;}else if(type.equals("老客戶大批量")){System.out.println("打八折");return price * 0.8;}return price;} }模版方法模式
核心
-處理某個流程的代碼已經都具備,但是其中某個節點的代碼暫時不能確定。因此,我們采用工廠方法模式,將這個節點的代碼實現轉移給子類完成。即:處理步驟父類中定義好,具體實現延遲到子類中定義。
什么時候用到模版方法模式
-實現一個算法時,整體步驟很固定,但是,某些部分易變。易變部分可以抽象出來,供子類實現。
開發中常見的場景
-非常頻繁。各個框架、類庫中都有他的影子。比如常見的有:
? 數據庫訪問的封裝
? JUNIT單元測試
? Servlet關于doGet/doPost方法使用
? Hibernate模版程序
? Spring中JDBCTemplate、HibernateTemplate等。
代碼實現
package com.swad.designpattern.templateMethod;public abstract class BankTemplateMethod {//具體方法public void takeNumber(){System.out.println("取號排隊");}public abstract void transact();//辦理具體的業務,鉤子方法public void evaluate(){System.out.println("反饋評分");}public final void process(){//模版方法this.takeNumber();this.transact();this.evaluate();} } package com.swad.designpattern.templateMethod;public class Client {public static void main(String[] args) {BankTemplateMethod btm = new DrawMoney();btm.process();//采用內部類BankTemplateMethod btm2 = new BankTemplateMethod() {@Overridepublic void transact() {System.out.println("我要存錢!");}};btm2.process();} }class DrawMoney extends BankTemplateMethod {@Overridepublic void transact() {System.out.println("我要取款!");} }觀察者模式
廣播機制的核心,我們把多個訂閱者、客戶稱為觀察者,需要同步給多個訂閱者的數據封裝到對象中,稱之為目標。類似于郵件訂閱和RSS訂閱,當我們瀏覽一些博客或wiki時,經常會看到RSS圖標,就這的意思是,當你訂閱了該文章,如果后續有更新,會及時通知你。
核心
-觀察者模式主要用于1:N的通知。當一個對象(目標對象Subject或Objserver)-消息發布的狀態變化時,他需要及時告知一系列對象(觀察者對象,Observer),令他們做出響應。通知觀察者的方式
推 -每次都會把通知以廣播方式發送給所有的觀察者,所有觀察者只能被動接收。 拉 -觀察者只要直到有情況即可。至于什么時候獲取內容,獲取什么內容,都可以自主決定。開發中常見的場景
-聊天室程序的,服務器轉發給所有客戶端 -網絡游戲(多人聯機對戰)場景中,服務器將客戶端的狀態進行分發 -郵件訂閱 -servlet中,監聽器的實現 -Android中,廣播機制 -JDK的AWT中事件處理模型,基于觀察者模式的委派事件模型(Delegation Event Model)? 事件源----目標對象
? 事件監聽器----觀察者
-京東商城中,群發某商品打折信息
代碼實現
package com.swad.designpattern.observer;import java.util.ArrayList; import java.util.List; //訂閱的主題類 public class Subject {protected List<Observer> list = new ArrayList<Observer>();public void register(Observer obs){list.add(obs);}public void removeObserver(Observer obs){list.remove(obs);}public void notifyAllObservers(){for(Observer obs:list){obs.update(this);}} } package com.swad.designpattern.observer; /*** 具體主題類* @author gonghaiyu**/ public class ConcreteSubject extends Subject{private int state;public int getState() {return state;}public void setState(int state) {this.state = state;//主題對象(目標對象)發生變化,請通知所有的觀察者this.notifyAllObservers();} } package com.swad.designpattern.observer;public interface Observer {void update(Subject sub); } package com.swad.designpattern.observer;public class ObserverA implements Observer{private int myState;//myState需要跟目標對象的state值保持一致@Overridepublic void update(Subject sub) {myState = ((ConcreteSubject)sub).getState();}public int getMyState() {return myState;}public void setMyState(int myState) {this.myState = myState;} } package com.swad.designpattern.observer;public class Client {public static void main(String[] args) {//目標對象ConcreteSubject subject = new ConcreteSubject();//創建多個觀察者ObserverA obs1 = new ObserverA();ObserverA obs2 = new ObserverA();ObserverA obs3 = new ObserverA();//將這三個觀察者添加到subject對象的觀察者隊伍中subject.register(obs1);subject.register(obs2);subject.register(obs3);//改變subject的狀態subject.setState(3000);System.out.println("###########");//查看觀察者的狀態是不是發生了變化System.out.println(obs1.getMyState());System.out.println(obs2.getMyState());System.out.println(obs3.getMyState());} }迭代子模式
場景
-提供一種可以遍歷聚合對象的方式。又稱為:游標cursor模式
-聚合對象:存儲數據
-迭代器:遍歷數據
結構
-聚合對象:存儲數據
-迭代器:遍歷數據
開發中常見的場景
-jdk內置的迭代器(List、Set)
-正向/逆向遍歷的迭代器
代碼實現
package com.swad.designpattern.iterator; /*** 茲定于游標接口* @author gonghaiyu**/ public interface MyIterator {void first();//將游標指向第一個void next();//將游標指向下一個boolean hasNext();//判斷是否存在下一個元素boolean isFirst();boolean isLast();Object getCurrentObj();//獲取當前游標指向的對象 } package com.swad.designpattern.iterator;import java.util.ArrayList; import java.util.List;/*** 自定義的聚合類* @author gonghaiyu**/ public class ConcreteMyAggregate {private List<Object> list = new ArrayList<Object>();public void addObject(Object obj){this.list.add(obj);}public void removeObject(Object obj){this.list.remove(obj);}public List<Object>getList(){return list;}public void setList(List<Object>list){this.list = list;}public MyIterator createIterator(){return new ConcreteIterator();}//使用內部類定義迭代器,可以直接使用外部類的屬性private class ConcreteIterator implements MyIterator{private int cursor;//定義游標用于記錄遍歷的位置@Overridepublic void first() {cursor = 0;}@Overridepublic void next() {if(cursor<list.size())cursor++;}@Overridepublic boolean hasNext() {if(cursor<list.size()){return true;}return false;}@Overridepublic boolean isFirst() {return cursor==0?true:false;}@Overridepublic boolean isLast() {return cursor==(list.size()-1)?true:false;}@Overridepublic Object getCurrentObj() {return list.get(cursor);}} } package com.swad.designpattern.iterator;public class Client {public static void main(String[] args) {ConcreteMyAggregate cma = new ConcreteMyAggregate();cma.addObject("aa");cma.addObject("bb");cma.addObject("cc");MyIterator iter = cma.createIterator();while(iter.hasNext()){System.out.println(iter.getCurrentObj());iter.next();}} }責任鏈模式
定義:將能夠處理同一類請求的對象連成一條鏈,所提交的請求沿著鏈傳遞,鏈上的對象逐個判斷是否有能力處理該請求,如果能則處理,如果不能則傳遞給鏈上的下一個對象。
場景:
-打牌時,輪流出牌
-接力賽跑
-大學中,獎學金審批
-公司中,公文審批
開發中常見的場景
-java中,異常機制就是一種責任鏈模式,一個try可以對應多個catch,當第一個catch不匹配類型,則自動跳到第二個catch。
-javascript語言中,事件的 和捕獲機制。Java語言中,事件的處理采用觀察者模式。
-servlet開發中,過濾器的鏈試處理
-struts2中,攔截器的調用也是典型的責任鏈模式
代碼實現
package com.swad.designpattern.chainOfResp; /*** 封裝請假的基本信息* @author gonghaiyu**/ public class LeaveRequest {private String empName;private int leaveDays;private String reason;public LeaveRequest(String empName, int leaveDays, String reason) {super();this.empName = empName;this.leaveDays = leaveDays;this.reason = reason;}public String getEmpName() {return empName;}public void setEmpName(String empName) {this.empName = empName;}public int getLeaveDays() {return leaveDays;}public void setLeaveDays(int leaveDays) {this.leaveDays = leaveDays;}public String getReason() {return reason;}public void setReason(String reason) {this.reason = reason;} } package com.swad.designpattern.chainOfResp;public abstract class Leader {protected String name;protected Leader nextLeader;//責任鏈上的后繼對象public Leader(String name) {super();this.name = name;}//設定責任鏈上的后綴對象public void setNextLeader(Leader nextLeader) {this.nextLeader = nextLeader;}/*** 抽象方法,讓子類處理請求的核心的業務方法* @param request*/public abstract void handleRequest(LeaveRequest request); } package com.swad.designpattern.chainOfResp; /*** 小于3天* 先主任審批* @author gonghaiyu**/ public class Director extends Leader{public Director(String name) {super(name);}@Overridepublic void handleRequest(LeaveRequest request) {if(request.getLeaveDays()<3){System.out.println("員工:"+request.getEmpName()+"請假,天數:"+request.getLeaveDays()+",理由:"+request.getReason());System.out.println("主任:"+this.name+",審批通過!");}else{if(this.nextLeader!=null){this.nextLeader.handleRequest(request);}}} } package com.swad.designpattern.chainOfResp; /*** 大于等于3天,小于10天* 經理審批* @author gonghaiyu**/ public class Manager extends Leader{public Manager(String name) {super(name);}@Overridepublic void handleRequest(LeaveRequest request) {if(request.getLeaveDays()<30){System.out.println("員工:"+request.getEmpName()+"請假,天數:"+request.getLeaveDays()+",理由:"+request.getReason());System.out.println("經理:"+this.name+",審批通過!");}else{if(this.nextLeader!=null){this.nextLeader.handleRequest(request);}}} } package com.swad.designpattern.chainOfResp; /*** 大于10天* 總經理審批* @author gonghaiyu**/ public class GeneralManager extends Leader{public GeneralManager(String name) {super(name);}@Overridepublic void handleRequest(LeaveRequest request) {if(request.getLeaveDays()<10){System.out.println("員工:"+request.getEmpName()+"請假,天數:"+request.getLeaveDays()+",理由:"+request.getReason());System.out.println("總經理:"+this.name+",審批通過!");}else{System.out.println("莫非"+request.getEmpName()+"想辭職,居然請假"+request.getLeaveDays()+"天");}} } package com.swad.designpattern.chainOfResp;public class Client {public static void main(String[] args) {Leader a = new Director("張三");Leader b = new Director("李四");Leader c = new GeneralManager("王五");//組織責任鏈的關系a.setNextLeader(b);b.setNextLeader(c);//開始請假操作LeaveRequest reql = new LeaveRequest("TOM", 9, "回家相親");a.handleRequest(reql);} }命令模式
舉個例子,司令員下令讓士兵去干件事情,從整個事情的角度來考慮,司令員的作用是,發出口令,口令經過傳遞,傳到了士兵耳朵里,士兵去執行。這個過程好在,三者相互解耦,任何一方都不用去依賴其他人,只需要做好自己的事兒就行,司令員要的是結果,不會去關注到底士兵是怎么實現的。
結構
-Command抽象命令
-ConcreteCommand具體命令類
-Invoker調用者/請求者
? 請求的發送者,它通過命令對象來執行請求。一個調用者并不需要在設計時確定其接收者,因此它只與抽象命令類之間存在關聯。在程序運行時,將調用命令對象的execute(),間接調用接收者的相關操作。
-Receiver接收者
? 接收者執行與請求相關的操作,具體實現對請求的業務處理。
? 未抽象前,實際執行操作內容的對象。
-Client客戶類
? 在客戶類中需要創建調用者對象、具體命令類對象,在創建具體命令對象時指定對象的接收者。發送者和接收者之間沒有直接關系,都通過命令對象間接調用。
開發中常見的場景
-struts2中,action的整個調用過程中就有命令模式
-數據庫事務機制的底層實現,JdbcTemplate 使用的就是命令模式。
-命令的撤銷和恢復(與備忘錄模式一起使用)
代碼實現
package com.swad.designpattern.command;public interface Command {void execute(); } class ConcreteCommand implements Command{private Receiver receiver;//命令真正的執行者@Overridepublic void execute() {//命令真正執行前或后,執行相關的處理receiver.action();}public ConcreteCommand(Receiver receiver) {super();this.receiver = receiver;} } package com.swad.designpattern.command;public class Receiver {public void action(){System.out.println("Receiver.action()");} } package com.swad.designpattern.command; //調用者-發起者 public class Invoke {//可以通過容器(List)很多命令進行批處理private Command command;public Invoke(Command command) {super();this.command = command;}//業務方法,用于調用命令類的方法public void call(){command.execute();} } package com.swad.designpattern.command;public class Client {public static void main(String[] args) {Command c = new ConcreteCommand(new Receiver());Invoke i = new Invoke(c);i.call();//上面類似于:new Receiver().action();} }備忘錄模式
核心
-就是保存某個對象內部狀態的拷貝,這樣以后就可以將該對象恢復到原先的狀態
結構
-源發起類Originator
-備忘錄類Memento
-負責人類CareTake
負責保存好的備忘錄對象;可以通過增加容器(list,stack),設置多個“備忘點”;將多個備忘錄對象,序列化和持久化。
開發中常見的應用場景
-棋類游戲中的,悔棋
-普通軟件中的,撤銷操作
-數據庫軟件中的事務管理回滾操作
-photoshop 軟件中的歷史記錄
代碼實現
package com.swad.designpattern.memento; /*** 源發起類* @author gonghaiyu**/ public class Emp {private String ename;private int age;private double salary;//進行備忘操作,并返回備忘錄對象public EmpMemento memento(){return new EmpMemento(this);}//進行數據恢復,恢復成指定備忘錄對象的值public void recovery(EmpMemento mmt){this.ename = mmt.getEname();this.age = mmt.getAge();this.salary = mmt.getSalary();}public Emp(String ename, int age, double salary) {super();this.ename = ename;this.age = age;this.salary = salary;}public String getEname() {return ename;}public void setEname(String ename) {this.ename = ename;}public int getAge() {return age;}public void setAge(int age) {this.age = age;}public double getSalary() {return salary;}public void setSalary(double salary) {this.salary = salary;}} package com.swad.designpattern.memento; /*** 備忘錄類* @author gonghaiyu**/ public class EmpMemento {private String ename;private int age;private double salary;public EmpMemento(Emp e){this.ename = e.getEname();this.age = e.getAge();this.salary = e.getSalary();}public String getEname() {return ename;}public void setEname(String ename) {this.ename = ename;}public int getAge() {return age;}public void setAge(int age) {this.age = age;}public double getSalary() {return salary;}public void setSalary(double salary) {this.salary = salary;}} package com.swad.designpattern.memento; /*** 負責人類* 管理備忘錄對象* @author gonghaiyu**/ public class CareTaker {private EmpMemento memento;public EmpMemento getMemento() {return memento;}public void setMemento(EmpMemento memento) {this.memento = memento;} } package com.swad.designpattern.memento;public class Client {public static void main(String[] args) {CareTaker taker = new CareTaker();Emp emp = new Emp("高某某",18,900);System.out.println("第一次打印對象:"+emp.getEname()+"---"+emp.getAge()+"---"+emp.getSalary());taker.setMemento(emp.memento());//備忘一次emp.setAge(38);emp.setEname("搞起");emp.setSalary(9000);System.out.println("第二次打印對象:"+emp.getEname()+"---"+emp.getAge()+"---"+emp.getSalary());emp.recovery(taker.getMemento());System.out.println("第三次打印對象:"+emp.getEname()+"---"+emp.getAge()+"---"+emp.getSalary());} }狀態模式
場景
電梯的運行
維修、正常、自動關閉、自動開門、向上運行、向下運行、消防狀態
紅綠燈
紅燈、綠燈、黃燈
酒店系統中,房間的狀態變化
已預定、已入住、空閑
核心:
-用于解決系統中復雜對象的狀態轉換及不同狀態下行為的封裝。
核心思想就是:當對象的狀態改變時,同時改變其行為,很好理解!就拿QQ來說,有幾種狀態,在線、隱身、忙碌等,每個狀態對應不同的操作,而且你的好友也能看到你的狀態,所以,狀態模式就兩點:1、可以通過改變狀態來獲得不同的行為。2、你的好友能同時看到你的變化。
結構
-Context環境類
環境類中維護一個State對象,他是定義了當前的狀態。
-State抽象狀態類
-ConcreteState具體狀態類
每一個類封裝了一個狀態對象的行為
開發中常見的場景
-銀行系統中賬號狀態的管理
-OA系統中公文狀態的管理
-酒店系統中,房間狀態的管理
-線程對象各狀態之間的切換
代碼實現
package com.swad.designpattern.state;/*** 空閑狀態* Created by gonghaiyu on 05/03/2017.*/ public interface State {void handle(); } package com.swad.designpattern.state;/*** Created by gonghaiyu on 05/03/2017.*/ public class FreeState implements State {@Overridepublic void handle() {System.out.println("房間空閑沒有人住");} } package com.swad.designpattern.state;/*** 已入住狀態* Created by gonghaiyu on 05/03/2017.*/ public class BookedState implements State{@Overridepublic void handle() {System.out.println("房間已預定!別人不能定!");} } package com.swad.designpattern.state;/*** Created by gonghaiyu on 05/03/2017.*/ public class CheckedInState implements State{@Overridepublic void handle() {System.out.println("房間已入住!請勿打擾!");} } package com.swad.designpattern.state;/*** Created by gonghaiyu on 05/03/2017.*/ public class Context {//如果是銀行系統,這個Context類就是賬號,根據金額不同,切換不同的狀態private State state;public void setState(State s){System.out.println("修改狀態!");state = s;state.handle();} } package com.swad.designpattern.state;/*** Created by gonghaiyu on 05/03/2017.*/ public class Client {public static void main(String[] args){Context ctx = new Context();ctx.setState(new FreeState());} }訪問者模式
模式動機:
-對于存儲在一個集合中的對象,他們可能具有不同的類型(即使有一個公共的接口),
對于該集合的對象,可以接受一類稱為訪問者的對象來訪問。不同的訪問者其訪問
方式也有所不同。
定義:
-表示一個作用于某對象結構中的各元素的操作,它使我們可以在不改變該元素
的類的前提下定義作用于這些元素的新操作。
簡單來說,訪問者模式就是一種分離對象數據結構與行為的方法,通過這種分離,可達到為一個被訪問者動態添加新的操作而無需做其它的修改的效果。
開發中的場景(應用范圍非常少,了解即可)
-xml文檔解析器設計
-編譯器的設計
-復雜集合對象的處理
中介者模式
核心
-如果一個系統中對象之間的聯系呈現為網狀結構,對象之間存在大量
多對多關系,將導致關系及其復雜,這些對象稱為"同事對象"
-我們可以引入一個中介者對象,使各個同事對象只跟中介者對象打教導道,
將復雜的網絡結構化解為如下的星形結構。
中介者模式的本質
-解耦多個同事對象之間的交互關系。每個對象都持有中介者對象的引用,
只跟中介者對象打交道。我們通過中介者對象統一管理這些交互關系
開發中常見的場景
-MVC模式(其中的C,控制器就是一個中介對象。M和V都和他打交道。)
-窗口游戲程序,窗口軟件開發中窗口對象也是一個中介者對象
-圖形界面開發GUI中,多個組建之間的交互,可以通過引入一個中介者對象來
解決,可以是整體的窗口對象或者DOM對象
-Java.lang.reflect.Method#invoke()
代碼實現
package com.swad.designpattern.mediator;/*** Created by gonghaiyu on 05/03/2017.*/ public interface Mediator {void register(String dname,Department d);void command(String dname); } package com.swad.designpattern.mediator;import java.util.HashMap; import java.util.Map;/*** Created by gonghaiyu on 05/03/2017.*/ public class President implements Mediator {private Map<String,Department> map = new HashMap<String,Department>();@Overridepublic void register(String dname, Department d) {map.put(dname,d);}@Overridepublic void command(String dname) {map.get(dname).selfAction();} } package com.swad.designpattern.mediator;/*** 同事類的接口* Created by gonghaiyu on 05/03/2017.*/ public interface Department {void selfAction();//做本部門的事情void outAction();//向總經理發出申請 } package com.swad.designpattern.mediator;/*** Created by gonghaiyu on 05/03/2017.*/ public class Development implements Department{private Mediator m;//持有中介者(總經理)的引用public Development(Mediator m) {super();this.m = m;m.register("development",this);}@Overridepublic void selfAction() {System.out.println("匯報工作!沒錢了,需要資金支持!");}@Overridepublic void outAction() {System.out.println("專心科研,開發項目!");} } package com.swad.designpattern.mediator;/*** Created by gonghaiyu on 05/03/2017.*/ public class Finacial implements Department{private Mediator m;//持有中介者(總經理)的引用public Finacial(Mediator m) {super();this.m = m;m.register("finacial",this);}@Overridepublic void selfAction() {System.out.println("數錢!");}@Overridepublic void outAction() {System.out.println("匯報工作!沒錢了,錢太多了!怎么花?");} } package com.swad.designpattern.mediator;/*** Created by gonghaiyu on 05/03/2017.*/ public class Market implements Department{private Mediator m;//持有中介者(總經理)的引用public Market(Mediator m) {super();this.m = m;m.register("finacial",this);}@Overridepublic void selfAction() {System.out.println("跑去接項目!");}@Overridepublic void outAction() {System.out.println("匯報工作!項目的進度,需要資金支持!");m.command("finacial");} } package com.swad.designpattern.mediator;/*** Created by gonghaiyu on 05/03/2017.*/ public class Client {public static void main(String [] args){Mediator m = new President();Market market = new Market(m);Development devp = new Development(m);Finacial f = new Finacial(m);market.selfAction();market.outAction();} }解釋器模式
介紹
-是一種不常用的設計模式
-用于描述如何構成一個簡單的語言解釋器,主要用于使用面向對象語言開發的
編譯器和解釋器設計。
-當我們需要開發一種新的語言時,可以考慮使用解釋器模式
-盡量不要使用使用解釋器模式,在項目中,可以使用Jruby,Groovy,java的
js引擎來替代解釋器的作用,彌補java語言的不足。
開發中常見的場景
-EL表達式的處理
-正則表達式解釋器
-SQL語法的解釋器
-數學表達式解析器
并發設計模式
Furture模式
JDK對Future模式的支持
生產者消費者模式
生產者消費者模式是一個經典的多線程設計模式。它為多線程間的協作提供了良好的解決方案。在生產者消費者模式中,通常由兩類線程,即若干個生產者線程和若干個消費者線程。生產者線程負責提交用戶請求,消費者線程則負責具體處理生產者提交的任務。生產者和消費者之間則通過共享內存緩沖區進行通信。
參考文獻
http://www.cnblogs.com/maowang1991/archive/2013/04/15/3023236.html
參考
鏈接:https://pan.baidu.com/s/1n0oaz8g1ZPCn2_qQEp3Rag
提取碼:3w6k
總結
以上是生活随笔為你收集整理的类设计原则及设计模式(一篇就够)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 西安恒智小寨java_长安反编译工具 j
- 下一篇: 季羡林基金会与孔明在线联手弘扬国学文化