设计模式小结
開(kāi)始的毛病:變量命名不規(guī)范,if-else判斷有的代碼做無(wú)用功,代碼健壯性太差,沒(méi)有做try-cath異常處理
工廠模式(創(chuàng)建型模式):
創(chuàng)建對(duì)象接口,讓其子類自己決定實(shí)例化哪一個(gè)工廠類,工廠模式使其創(chuàng)建延伸到子類進(jìn)行
 主要解決接口選擇問(wèn)題,明確計(jì)劃不同條件下執(zhí)行創(chuàng)建不同實(shí)例
 通過(guò)子類實(shí)現(xiàn)工廠實(shí)例,創(chuàng)建過(guò)程在其子類執(zhí)行
 優(yōu)點(diǎn):提高擴(kuò)展性,屏蔽產(chǎn)品具體實(shí)現(xiàn),調(diào)用者只關(guān)心產(chǎn)品接口; 缺點(diǎn):增加一個(gè)產(chǎn)品,會(huì)導(dǎo)致系統(tǒng)中類個(gè)數(shù)增加,造成系統(tǒng)復(fù)雜度
 使用場(chǎng)景:
 1.日志記錄:用戶選擇將日志記錄到磁盤/系統(tǒng)事件/遠(yuǎn)程服務(wù)器
 2.數(shù)據(jù)庫(kù)訪問(wèn):系統(tǒng)采用不同的數(shù)據(jù)庫(kù)
 3.設(shè)計(jì)連接服務(wù)器的框架, 比如針對(duì)pop3, imap, http設(shè)計(jì)接口
 注:工廠模式作為類的創(chuàng)建模式, 復(fù)雜的對(duì)象使用工廠模式, 簡(jiǎn)單對(duì)象使用new, 而非工廠模式
 簡(jiǎn)單工廠:一個(gè)工廠類,一個(gè)產(chǎn)品抽象類
 工廠方法:多個(gè)工廠類,一個(gè)產(chǎn)品抽象類
 抽象工廠:多個(gè)工廠類,多個(gè)產(chǎn)品抽象類
 采用松耦合,多態(tài)的方式,使得我想要哪一個(gè)功能,就生成相應(yīng)對(duì)象, 問(wèn)題的考慮方向只需放在要實(shí)例化哪個(gè)類,要增加哪一項(xiàng)功能
 也可以使用枚舉的方式, 實(shí)現(xiàn)工廠模式: 將每個(gè)工廠實(shí)例作為枚舉對(duì)象,通過(guò)枚舉工廠進(jìn)行調(diào)用
抽象工廠模式(創(chuàng)建型模式,其他工廠的工廠):
接口只負(fù)責(zé)創(chuàng)建一個(gè)相關(guān)的對(duì)象的工廠,不需要顯式指定類,工廠模式就能按照工廠模式提供對(duì)象(多態(tài))
 用于解決接口選擇問(wèn)題
 優(yōu)點(diǎn):當(dāng)產(chǎn)品族中,多個(gè)對(duì)象被設(shè)計(jì)成一起工作,能保證客戶端只使用一個(gè)產(chǎn)品族中對(duì)象
 缺點(diǎn):產(chǎn)品族中擴(kuò)展產(chǎn)品,需要在抽象類中添加代碼, 還需要在具體實(shí)現(xiàn)里面添加代碼
 懂得一點(diǎn),使用設(shè)計(jì)模式, 先搞定UML
 建立多個(gè)工廠, 然后建立一個(gè)總的工廠,通過(guò)總的工廠調(diào)用下屬,主要還是多態(tài)的性質(zhì)運(yùn)用, 程序中還有很多瑕疵
 主要還是接口的選擇, 以及狀態(tài)的變化
單例模式(創(chuàng)建型模式):
涉及到的單一的類,該類只負(fù)責(zé)自己對(duì)象的創(chuàng)建,并且只有單個(gè)對(duì)象被創(chuàng)建,提供唯一的對(duì)象訪問(wèn)方式,可直接訪問(wèn)
 注: 只能有一個(gè)實(shí)例作為全局的訪問(wèn)點(diǎn), 構(gòu)造函數(shù)私有,單例類只能自己創(chuàng)建自己唯一的實(shí)例, 必須給所有其他對(duì)象提供這一實(shí)例;
!!!使用synchronized防止多線程同時(shí)創(chuàng)建多個(gè)實(shí)例
主要用于:控制資源,全局使用的類創(chuàng)建/銷毀
 優(yōu)點(diǎn):只有一個(gè)實(shí)例,減少資源開(kāi)銷,避免對(duì)資源的多重占用(寫文件操作)
 缺點(diǎn):沒(méi)有接口,不能被繼承,只關(guān)心內(nèi)部邏輯,不關(guān)心外部
 使用場(chǎng)景–產(chǎn)品的唯一序列號(hào); web計(jì)數(shù)器,使用單例將其緩存,不用每次在數(shù)據(jù)庫(kù)中刷新; 創(chuàng)建對(duì)象消耗資源, 比如IO,數(shù)據(jù)庫(kù)連接
 懶漢模式/餓漢模式—在/不在類內(nèi)方法構(gòu)造實(shí)例
建造者模式(創(chuàng)建型模式,使用多個(gè)簡(jiǎn)單對(duì)象構(gòu)建復(fù)雜對(duì)象):
使用: 基本組件不變,其組合常常在變化, 將變的部分和不變的部分分開(kāi)
 建造者:創(chuàng)建和提供實(shí)例, 導(dǎo)演: 管理建造出來(lái)的實(shí)例的依賴關(guān)系
 優(yōu)點(diǎn):建造者獨(dú)立,易擴(kuò)展; 便于控制細(xì)節(jié)風(fēng)險(xiǎn)
 缺點(diǎn): 產(chǎn)品必須有公共點(diǎn),范圍有限制; 生成對(duì)象之間有依賴關(guān)系
 注: 建造者模式與工廠模式的區(qū)別—建造者更關(guān)注零件的裝配順序, 將一個(gè)復(fù)雜的構(gòu)建過(guò)程與其表示相分離, 并不是由建造者負(fù)責(zé)一切,而是由監(jiān)工負(fù)責(zé)控制(定義)一個(gè)復(fù)雜的構(gòu)建過(guò)程,由各個(gè)不同的建造者分別實(shí)現(xiàn)構(gòu)建過(guò)程所用到的構(gòu)建步驟
原型模式(創(chuàng)建型模式,創(chuàng)建重復(fù)對(duì)象且保證性能):
該模式創(chuàng)建一個(gè)原型接口,此接口用于創(chuàng)建對(duì)象的克隆. 例:將一些高代價(jià)的對(duì)象進(jìn)行緩存,在下一次請(qǐng)求創(chuàng)建的時(shí)候返回他的克隆, 減少資源開(kāi)銷
 優(yōu)點(diǎn): 性能提高,逃避構(gòu)造函數(shù)的約束
 缺點(diǎn):配備克隆操作需要對(duì)類的功能全盤考慮,對(duì)已有的類不一定很容易,特別是當(dāng)一個(gè)類飲用不支持串行化的間接對(duì)象,或者引用含有循環(huán)結(jié)構(gòu); 必須實(shí)現(xiàn)Cloneable接口
 什么時(shí)候使用–一個(gè)系統(tǒng)應(yīng)該獨(dú)立立于它的產(chǎn)品創(chuàng)建,構(gòu)成,表示; 實(shí)例化的類是在運(yùn)行時(shí)指定,如動(dòng)態(tài)裝載; 為了避免創(chuàng)建一個(gè)和產(chǎn)品類層次平行的工廠類層次時(shí); 當(dāng)一個(gè)類的實(shí)例只能有幾個(gè)不同狀態(tài)組合中的一種時(shí),
 使用場(chǎng)景–
 1.資源優(yōu)化, 類加載需要消耗很多資源, 性能和安全要求高的場(chǎng)景
 2.通過(guò)new產(chǎn)生一個(gè)對(duì)象需要非常繁瑣的數(shù)據(jù)準(zhǔn)備或訪問(wèn)權(quán)限,則可以使用原型模型
 3.一個(gè)對(duì)象,多個(gè)修改者
 4.大多數(shù)眼型模式伴隨工廠模式出現(xiàn),通過(guò)clone方法創(chuàng)建一個(gè)對(duì)象,然后由工廠方法提供給調(diào)用者
 注:原型模式通過(guò)拷貝一個(gè)現(xiàn)有對(duì)象生成新對(duì)象, 淺拷貝實(shí)現(xiàn)Clonable接口, 重寫clone方法, 深拷貝通過(guò)實(shí)現(xiàn)Serializable讀取二進(jìn)制流
 //
 原型角色:定義用于復(fù)制現(xiàn)有的實(shí)例來(lái)生成新的實(shí)例的方法(實(shí)現(xiàn)Cloneable接口的類)
 具體原型角色:實(shí)現(xiàn)用于復(fù)制現(xiàn)有實(shí)例來(lái)生成新實(shí)例的方法(具有clone()方法的類)
 使用者角色:維護(hù)一個(gè)注冊(cè)表, 提供獲取clone的類
適配器模式(結(jié)構(gòu)型模式):
是作為兩個(gè)不兼容的接口之間的橋梁,結(jié)合兩個(gè)獨(dú)立的接口; 這種模式涉及到一個(gè)單一的類, 該類負(fù)責(zé)加入獨(dú)立的或不兼容的接口的功能; 例如讀卡器連接內(nèi)存卡與筆記本
 實(shí)現(xiàn)方式: 一般通過(guò)適配器繼承或者以來(lái)已有對(duì)象, 實(shí)現(xiàn)想要的目標(biāo)接口
 優(yōu)點(diǎn): 可以讓兩個(gè)沒(méi)有關(guān)系的接口/類一起運(yùn)行, 提高類的復(fù)用性, 增加類的靈活性
 缺點(diǎn):
 過(guò)多使用適配器造成系統(tǒng)凌亂, 例如:表面上使用A接口,適配器卻將A改為B接口,造成接口使用的混亂, 因此如果不是有必要的, 可以不使用適配器, 而是直接對(duì)系統(tǒng)重構(gòu)
 由于java單繼承, 當(dāng)適配類的時(shí)候, 只能適配一個(gè)類(為抽象類);
 注: 適配器主要是用與解決正在服役的項(xiàng)目的問(wèn)題, 不是在類詳細(xì)設(shè)計(jì)的時(shí)候添加
橋接模式(結(jié)構(gòu)型模式):
抽象類依賴實(shí)現(xiàn)類,用于把抽象化與實(shí)現(xiàn)化解耦,使二者可以獨(dú)立變化, 提供抽象化和實(shí)現(xiàn)化直接的橋接結(jié)構(gòu); 使得實(shí)體類的功能能獨(dú)立于接口實(shí)現(xiàn)類
 主要解決類繼承造成的爆炸問(wèn)題,應(yīng)對(duì)類的多種變化, 便與擴(kuò)展; 實(shí)現(xiàn)系統(tǒng)多個(gè)角度分類,每一個(gè)角度都可能會(huì)變化
 優(yōu)點(diǎn):抽象與實(shí)現(xiàn)的分離, 優(yōu)秀的擴(kuò)展功能, 實(shí)現(xiàn)細(xì)節(jié)對(duì)客戶透明
 缺點(diǎn): 增加系統(tǒng)設(shè)計(jì)理解難度,由于聚合關(guān)系建立在抽象層,要求針對(duì)抽象進(jìn)行設(shè)計(jì)與編程
 使用場(chǎng)景:
類的功能層次結(jié)構(gòu):父類具有基本功能,子類增加新的功能類的功能層次結(jié)構(gòu):父類具有基本功能,子類增加新的功能
 類的實(shí)現(xiàn)層次結(jié)構(gòu):父類通過(guò)聲明抽象方法定義接口,子類通過(guò)實(shí)現(xiàn)具體的方法來(lái)實(shí)現(xiàn)接口
 橋接模式的角色:
 抽象化角色:實(shí)現(xiàn)者角色提供的接口來(lái)定義基本功能接口,持有實(shí)現(xiàn)者角色,并在功能中委托給他,起到搭建橋梁的作用, 抽象化角色非抽象類,而指抽象了實(shí)現(xiàn)
 改善后的抽象化角色:作為抽象化角色的子類,增加新功能,增加新的接口,與其構(gòu)成類的功能層次結(jié)構(gòu)
 實(shí)現(xiàn)者角色:提供用于抽象化角色的接口,它是一個(gè)抽象類/接口
 具體實(shí)現(xiàn)者角色:作為實(shí)現(xiàn)者角色的子類,通過(guò)實(shí)現(xiàn)具體方法來(lái)實(shí)現(xiàn)接口,與其構(gòu)成類的實(shí)現(xiàn)層次結(jié)構(gòu)
過(guò)濾器/標(biāo)準(zhǔn)模式(結(jié)構(gòu)型模式):
通過(guò)不同的標(biāo)準(zhǔn)來(lái)過(guò)濾一組對(duì)象,通過(guò)邏輯運(yùn)算符以解耦的方式把他們連接起來(lái)
 在java8中,最典型的應(yīng)用就是分組操作,根據(jù)指定的指標(biāo)進(jìn)行分組篩選(如Collectors.groupingBy(Persons::getGender)分組條件為getGender)
組合/整體模式(結(jié)構(gòu)型模式):
就是在一個(gè)對(duì)象中包含其他對(duì)象,這些被包含的對(duì)象可能是終點(diǎn)對(duì)象(不再包含別的對(duì)象),也有可能是非終點(diǎn)對(duì)象(其內(nèi)部還包含其他對(duì)象,或叫組對(duì)象),
 我們將對(duì)象稱為節(jié)點(diǎn),即一個(gè)根節(jié)點(diǎn)包含許多子節(jié)點(diǎn),這些子節(jié)點(diǎn)有的不再包含子節(jié)點(diǎn),而有的仍然包含子節(jié)點(diǎn),以此類推。
 通過(guò)組合的方式(在對(duì)象內(nèi)部引用對(duì)象)來(lái)進(jìn)行布局,我認(rèn)為這種組合是區(qū)別于繼承的,而另一層含義是指樹(shù)形結(jié)構(gòu)子節(jié)點(diǎn)的抽象(將葉子節(jié)點(diǎn)與數(shù)枝節(jié)點(diǎn)抽象為子節(jié)點(diǎn)),區(qū)別于普通的分別定義葉子節(jié)點(diǎn)與數(shù)枝節(jié)點(diǎn)的方式。
 主要解決:在樹(shù)型結(jié)構(gòu)的問(wèn)題中,模糊了簡(jiǎn)單元素和復(fù)雜元素的概念, 客戶程序處理復(fù)雜元素如同簡(jiǎn)單元素,使客戶程序與復(fù)雜元素的內(nèi)部結(jié)構(gòu)解耦;表示對(duì)象的部分-整體層次結(jié)構(gòu), 用戶忽略組合對(duì)象與單個(gè)對(duì)象的不同,用戶統(tǒng)一使用組合結(jié)構(gòu)中的所有對(duì)象
 優(yōu)點(diǎn):高層模塊調(diào)用簡(jiǎn)單,節(jié)點(diǎn)自由增加
 缺點(diǎn):由于葉子和樹(shù)枝聲明為實(shí)現(xiàn)類,而非接口, 違反依賴倒置原則
 注: 通常樹(shù)枝內(nèi)部組合接口, 含有List,里面具有Component
裝飾器模式(結(jié)構(gòu)型模式):
允許向一個(gè)現(xiàn)有的對(duì)象添加新的功能,同時(shí)不改變其結(jié)構(gòu)(作為現(xiàn)有類的一個(gè)包裝);
 動(dòng)態(tài)為對(duì)象添加一些額外的職責(zé),就增加功能來(lái)說(shuō),裝飾模式相比生成子類更加靈活;
 一般情況,為擴(kuò)展一個(gè)類經(jīng)常使用繼承,相反,子類會(huì)變得很膨脹, 應(yīng)該將具體功能劃分,同時(shí)繼承裝飾者模式
 優(yōu)點(diǎn):裝飾類和被裝飾類可以獨(dú)立發(fā)展,不會(huì)相互耦合,裝飾模式就是繼承的一個(gè)替代模式,可以動(dòng)態(tài)擴(kuò)展一個(gè)實(shí)現(xiàn)類的功能
 缺點(diǎn):多層裝飾比較復(fù)雜
外觀模式(結(jié)構(gòu)型模式):
向客戶端提供一個(gè)客戶端可以訪問(wèn)的系統(tǒng)接口, 類似于中介模式,隱藏系統(tǒng)的復(fù)雜性;只涉及到一個(gè)單一的類;
 為子系統(tǒng)中一組接口提供一個(gè)一致的界面,外觀模式定義一個(gè)高層接口,使得子系統(tǒng)更加容易使用;
 此模式用于降低訪問(wèn)復(fù)雜系統(tǒng)的內(nèi)部子系統(tǒng)的復(fù)雜度,簡(jiǎn)化客戶端與之的接口
 注:在客戶端和復(fù)雜系統(tǒng)之間再加一層,這一層將調(diào)用順序,依賴關(guān)系處理好
 優(yōu)點(diǎn):減少系統(tǒng)相互依賴, 提高靈活性, 提高安全性
 缺點(diǎn):不符合開(kāi)閉原則,改寫代碼很麻煩,繼承重寫不適合
 使用場(chǎng)景:為復(fù)雜系統(tǒng)的模塊或子系統(tǒng)提供外界訪問(wèn)的模塊;子系統(tǒng)相對(duì)獨(dú)立;
享元模式(結(jié)構(gòu)型設(shè)計(jì)模式):
用于減少創(chuàng)建對(duì)象的數(shù)量,以減少內(nèi)存占用和提高性能;嘗試重用現(xiàn)有的同類對(duì)象,未找到匹配對(duì)象,則創(chuàng)建新對(duì)象;運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象, 類似于單例模式
 主要解決: 有大量對(duì)象時(shí),可能造成內(nèi)存溢出,把共同部分抽象出來(lái),如果有相同的業(yè)務(wù)請(qǐng)求,直接返回在內(nèi)存中已有的對(duì)象,避免重新創(chuàng)建; 一般使用HashMap存儲(chǔ)這些對(duì)象
 優(yōu)點(diǎn):大大減少對(duì)象的創(chuàng)建,降低系統(tǒng)的內(nèi)存
 缺點(diǎn):提高系統(tǒng)的復(fù)雜度,需要分離出外部狀態(tài),內(nèi)部狀態(tài);外部狀態(tài)具有固有化的性質(zhì),不應(yīng)該隨內(nèi)部狀態(tài)的變化而變化
 注:注意劃分外部狀體和內(nèi)部狀態(tài),否則會(huì)引起線程安全問(wèn)題; 這些類必須有一個(gè)工廠對(duì)象加以控制
 該模式優(yōu)點(diǎn)相似單例模式,都是為了避免創(chuàng)建過(guò)多相似對(duì)象浪費(fèi)空間內(nèi)存資源
代理模式(結(jié)構(gòu)型模式):
一個(gè)類代表另一類的功能,為其他對(duì)象提
 供一種代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn)(即代理權(quán)),使用在想訪問(wèn)一個(gè)類時(shí)做一些控制
 一般添加中間層解決代理問(wèn)題,比如:復(fù)制粘貼的快捷方式
 注:
 1.與適配器模式的區(qū)別: 適配器主要是考慮改變對(duì)象的接口,而代理模式不能改變所代理類的接口
 2.與裝飾器模式的區(qū)別: 裝飾器模式是為了增強(qiáng)功能, 代理模式是為了加以控制
 JDK自帶動(dòng)態(tài)代理—java.lang.reflect.Proxy生成動(dòng)態(tài)代理類和對(duì)象; java.lang.reflect.InvocationHandler可以通過(guò)invoke方法實(shí)現(xiàn)對(duì)真實(shí)角色的代理訪問(wèn)
責(zé)任鏈模式(行為模式):
為請(qǐng)求創(chuàng)建一個(gè)接受這對(duì)象的鏈,對(duì)請(qǐng)求的發(fā)送者和接受者進(jìn)行解耦,通常每個(gè)接受者都包含另一個(gè)接受者的引用,如果一個(gè)對(duì)象不能處理該請(qǐng)求,他會(huì)把相同的請(qǐng)求傳遞給下一個(gè)接受者,直到找到符合處理當(dāng)前任務(wù)的對(duì)象
 避免請(qǐng)求者與接受者耦合,讓多個(gè)對(duì)象都有可能接受請(qǐng)求,將對(duì)象連接成一條鏈,沿著這一條鏈傳遞請(qǐng)求,直到有對(duì)象處理它為止
 注:Handler里面聚合他自己,在HanleRequest里面判斷是否合適,如果沒(méi)有達(dá)到條件則向下傳遞,向誰(shuí)傳遞之前set進(jìn)去; JavaWeb中遇到很多應(yīng)用
 優(yōu)點(diǎn):減低耦合度,將請(qǐng)求者和接受者解耦,簡(jiǎn)化對(duì)象,使對(duì)象不需要知道鏈的結(jié)構(gòu), 增強(qiáng)給對(duì)象指派職責(zé)的靈活性,通過(guò)改變鏈內(nèi)的成員或者調(diào)動(dòng)他們的次序,允許動(dòng)態(tài)的增加或刪除責(zé)任,增加新的請(qǐng)求方便
 缺點(diǎn):不能保證請(qǐng)求一定被接收, 系統(tǒng)性能會(huì)受到一定影響,在進(jìn)行代碼調(diào)試時(shí)不方便,會(huì)造成循環(huán)調(diào)用, 不容易觀察運(yùn)行時(shí)特征
 使用場(chǎng)景–多個(gè)對(duì)象處理同一個(gè)請(qǐng)求,具體處理該請(qǐng)求由運(yùn)行時(shí)刻確定; 在不確定指定接受者的情況下, 向多個(gè)對(duì)象中提交一個(gè)請(qǐng)求; 動(dòng)態(tài)指定一組對(duì)象處理請(qǐng)求
命令模式(行為模式):
數(shù)據(jù)驅(qū)動(dòng)型設(shè)計(jì)模式,請(qǐng)求以命令的形式包裹在對(duì)象中,并傳給對(duì)象,調(diào)用對(duì)象尋找可以處理該命令的合適對(duì)象,并把該命令傳給相應(yīng)的對(duì)象,此對(duì)象執(zhí)行命令
 主要解決行為請(qǐng)求者與實(shí)現(xiàn)者之間的松耦合,一般情況行為請(qǐng)求者與實(shí)現(xiàn)者是緊耦合關(guān)系, 在針對(duì)記錄的撤銷重做,事務(wù)處理就必須保證松耦合
 關(guān)鍵代碼: 定義三個(gè)角色: 1.received真正的命令執(zhí)行對(duì)象, 2.Command 3.invoker使用命令對(duì)象的入口
 優(yōu)點(diǎn): 降低系統(tǒng)耦合度, 新的命令可以添加到系統(tǒng)中去
 缺點(diǎn):導(dǎo)致系統(tǒng)有過(guò)多的具體命令類
 使用場(chǎng)景:例:GUI中的按鈕, 模擬CMD, 腳本編程
解釋器模式(行為模式):
實(shí)現(xiàn)一個(gè)表達(dá)式接口,解釋一個(gè)特定的上下文,多用于SQL解釋,符號(hào)處理引擎,主要是還是固定文法的解釋
 通常構(gòu)建語(yǔ)法樹(shù),定義終結(jié)符,非終結(jié)符, 構(gòu)建環(huán)境多采用HashMap
 該模式使用場(chǎng)景少,對(duì)于復(fù)雜文法難以維護(hù),引起類膨脹,且解釋器通常使用遞歸調(diào)用方法,Java中多采用experssion4J代替
迭代器模式(行為模式):
主要用于順序訪問(wèn)迭代器中元素,典型的Java中的Iterator
 注:迭代器分離了集合對(duì)象的遍歷行為,做到不暴露集合內(nèi)部結(jié)構(gòu),且讓外部代碼做到透明地訪問(wèn)集合內(nèi)部的元素
中介模式(行為模式):
降低多個(gè)對(duì)象與類之間的通信復(fù)雜, 此模式提供一個(gè)中介類, 該類通常處理不同類之間的通信, 并支持松耦合, 使代碼便于維護(hù)
 使用中介對(duì)象封裝一系列對(duì)象之間的交互方式, 中介者使個(gè)對(duì)象不需要顯式的互相引用, 主要解決對(duì)象與對(duì)象之間的大量耦合關(guān)系
 使用場(chǎng)景: 系統(tǒng)中對(duì)象之間存在較為復(fù)雜的引用關(guān)系, 導(dǎo)致他們之間的依賴關(guān)系復(fù)雜而難以復(fù)用該對(duì)象; 通過(guò)一個(gè)中間類封裝多個(gè)類中的行為, 而又不想生成太多子類
 注: 不應(yīng)當(dāng)在職責(zé)混亂的時(shí)候使用
備忘錄模式(行為模式):
在不破壞封裝性的前提下,捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài),保存一個(gè)對(duì)象的某個(gè)狀態(tài), 在合適的情況下恢復(fù)此對(duì)象; 例如Ctr+Z
 注:整個(gè)過(guò)程一般增加一個(gè)備忘錄類, 為節(jié)約內(nèi)存,通常使用原型模式+備忘錄模式
觀察者模式(行為模式):
當(dāng)對(duì)象存在一對(duì)多的關(guān)系的時(shí)候,觀察者將一個(gè)對(duì)象的修改情況自動(dòng)通知其他的依賴他的對(duì)象;廣播通知;觸發(fā)機(jī)制鏈
 一般在抽象類中使用ArrayList存放觀察者
 優(yōu)點(diǎn):觀察者與被觀察者抽象耦合
 缺點(diǎn):當(dāng)一個(gè)被觀察對(duì)象存在多個(gè)觀察者,通知所有觀察者將會(huì)花費(fèi)較多的時(shí)間, 若觀察者與被觀察者之間存在循環(huán)關(guān)系,可能會(huì)導(dǎo)致死循環(huán)通知;觀察者模式通知觀察者觀察目標(biāo)發(fā)生了變化,并沒(méi)有告訴觀察者目標(biāo)對(duì)象是怎樣發(fā)生變化的
 注:java中存在對(duì)觀察者支持的類, 避免循環(huán)引用; 當(dāng)一個(gè)觀察者出現(xiàn)錯(cuò)誤的時(shí)候?qū)?huì)導(dǎo)致系統(tǒng)錯(cuò)誤,一般采用異步的方式
狀態(tài)模式(行為模式):
允許對(duì)象在內(nèi)部狀態(tài)發(fā)生改變的時(shí)改變他的行為, 對(duì)象看起來(lái)修改了他的類, 主要解決對(duì)象的行為依賴于他的狀態(tài),并根據(jù)他的狀態(tài)改變而改變他的相關(guān)行為, 類似于廣播通知
 通常將具體的狀態(tài)抽象出來(lái)
 優(yōu)點(diǎn):封裝轉(zhuǎn)換原則;枚舉所有的狀態(tài);可讓多個(gè)環(huán)境對(duì)象共享一個(gè)狀態(tài)對(duì)象,從而減少系統(tǒng)中對(duì)象的個(gè)數(shù)
 缺點(diǎn):使用不當(dāng)將會(huì)導(dǎo)致系統(tǒng)結(jié)構(gòu)混亂, 不太支持開(kāi)閉原則, 切換狀態(tài)將會(huì)修改負(fù)責(zé)狀態(tài)轉(zhuǎn)換的代碼
 注:在行為狀態(tài)受約束的時(shí)候使用狀態(tài)模式,且狀態(tài)不超過(guò)5個(gè)
空對(duì)象模式:
使用空對(duì)象取代null, 取代的過(guò)程中并不是對(duì)象不存在,而是面對(duì)反應(yīng)的時(shí)候不作出任何動(dòng)作
模板方法設(shè)計(jì)模式(行為模式):
定義操作中算法的骨架,將通用的算法抽象出來(lái), 抽象類定義算法的方式/模板, 子類按需要重寫
 優(yōu)點(diǎn): 封裝不變的部分,擴(kuò)展變的部分, 行為由父類控制, 子類實(shí)現(xiàn)
 缺點(diǎn):每種不同的實(shí)現(xiàn)都需要子類去實(shí)現(xiàn), 導(dǎo)致類的個(gè)數(shù)增加
 注:為防止惡意操作, 將模板方法加上final關(guān)鍵字
 爺爺(接口)->父親(抽象類)->兒子(最終實(shí)現(xiàn)類); 兒子重寫父類方法, 父類重寫爺爺方法, 進(jìn)行方法查找只能去爺爺輩查找,多態(tài)的原因去父類中查找, 但是子類重寫父類方法, 最終去子類中查找
訪問(wèn)者模式(行為模式):
將數(shù)據(jù)結(jié)構(gòu)與數(shù)據(jù)操作分離,解決穩(wěn)定的數(shù)據(jù)結(jié)構(gòu)與易變的操作之間的耦合,避免對(duì)象的操作污染對(duì)象的類, 訪問(wèn)者將訪問(wèn)過(guò)程的操作封裝到類中
 在訪問(wèn)的類里面加一個(gè)對(duì)外提供接待訪問(wèn)者的接口
 優(yōu)點(diǎn): 符合單一職責(zé), 良好擴(kuò)展性,靈活性
 缺點(diǎn):具體元素對(duì)訪問(wèn)者公布細(xì)節(jié)
MVC模式(模式-視圖-控制器):
用于應(yīng)用程序的分層開(kāi)發(fā)
 model:代表一個(gè)存取數(shù)據(jù)的對(duì)象; view:數(shù)據(jù)的可視化 controller:控制數(shù)據(jù)流向模型對(duì)象,更新視圖,將視圖與模型分離開(kāi)
 業(yè)務(wù)代表模式: 對(duì)表示層和業(yè)務(wù)層解耦, 減少通信或?qū)Ρ硎緦哟a中的業(yè)務(wù)層代碼的遠(yuǎn)程查詢功能
 客戶端 client: jsp, Servlet, UIJava,選擇業(yè)務(wù)代表
 業(yè)務(wù)代表 BusinessDelegate: 提供對(duì)業(yè)務(wù)服務(wù)方法的訪問(wèn),選擇服務(wù)
 查詢服務(wù): 獲取相關(guān)業(yè)務(wù)實(shí)現(xiàn), 提供對(duì)象對(duì)業(yè)務(wù)代表對(duì)象的訪問(wèn)
 業(yè)務(wù)服務(wù): 業(yè)務(wù)接口,實(shí)現(xiàn)業(yè)務(wù)服務(wù)的實(shí)體類, 提供實(shí)際業(yè)務(wù)實(shí)現(xiàn)邏輯
 //將業(yè)務(wù)訪問(wèn)的服務(wù)與用戶所需要的服務(wù)通過(guò)業(yè)務(wù)代表選擇對(duì)應(yīng)的服務(wù)
組合體模式:
用在EJB持久化機(jī)制中; 一個(gè)組合實(shí)體是一個(gè)EJB實(shí)體bean, 代表對(duì)象的圖解; 當(dāng)更新一個(gè)組合實(shí)體時(shí), 內(nèi)部依賴對(duì)象beans會(huì)自動(dòng)更新
 組合實(shí)體(Composite Entity):主要實(shí)體bean, 可以是粗粒的, 或者包含一個(gè)粗粒對(duì)象, 用于持續(xù)生命周期
 粗粒度對(duì)象(Coarse-Grained Object):此對(duì)象包含依賴對(duì)象, 具有自己的生命期, 也能管理依賴對(duì)象的生命期
 依賴對(duì)象(Dependent Object): 是一個(gè)持續(xù)生命期依賴于粗粒度對(duì)象的對(duì)象
 策略(Strategies): 如何實(shí)現(xiàn)組合實(shí)體
 整個(gè)過(guò)程中層層解耦, 由小到大由底層到上層, 最終的底層實(shí)現(xiàn)由依賴對(duì)象實(shí)現(xiàn)有點(diǎn)像工廠模式/策略模式(負(fù)責(zé)處理組合體)
數(shù)據(jù)訪問(wèn)對(duì)象模式:
就是將JDBC從高級(jí)業(yè)務(wù)中抽取出來(lái), 不去干擾業(yè)務(wù)操作
 數(shù)據(jù)對(duì)象訪問(wèn)接口(Data Access Object Interface): 定義模型對(duì)象執(zhí)行的標(biāo)準(zhǔn)操作
 數(shù)據(jù)訪問(wèn)對(duì)象實(shí)體類(Data Access Object concrete class): 實(shí)現(xiàn)上述接口
 模型對(duì)象/數(shù)值對(duì)象(Model Object/Value Object): get/set方法檢索數(shù)據(jù)
前端控制器模式:
提供一個(gè)集中的請(qǐng)求處理機(jī)制, 將所有請(qǐng)求交給單一的處理程序(認(rèn)證,授權(quán),記錄日志,跟蹤請(qǐng)求)
 前端控制器(Front Controller):基于Web應(yīng)用程序, 基于桌面應(yīng)用程序
 調(diào)度器(Dispatcher):使用一個(gè)調(diào)度對(duì)象來(lái)調(diào)度請(qǐng)求到相應(yīng)的具體處理程序
 視圖(view)
 與組合模式差不多
攔截器模式:
對(duì)程序的請(qǐng)求或響應(yīng)做出預(yù)處理/后處理, 與過(guò)濾模式,責(zé)任鏈模式雷同
 過(guò)濾器(Filter):過(guò)濾器在請(qǐng)求之前/之后,執(zhí)行某些任務(wù)
 過(guò)濾器鏈(Filter Chain):具有多個(gè)過(guò)濾器,順序執(zhí)行
 Target: 目標(biāo)對(duì)象,交由過(guò)濾器處理
 過(guò)濾管理器(Filter Manger):管理過(guò)濾器/過(guò)濾鏈
 Client:向target發(fā)送請(qǐng)求對(duì)象
服務(wù)期定位模式:
利用緩存技術(shù), 類似于單例模式/原型模式, 避免重復(fù)new 服務(wù)對(duì)象, 造成資源浪費(fèi)
 服務(wù)(Service):實(shí)際處理請(qǐng)求服務(wù)
 Context: 帶有對(duì)要查找對(duì)象的引用
 緩存(Cache):緩存儲(chǔ)存服務(wù)的引用,以便重復(fù)使用
 Client: ServiceLocator調(diào)用服務(wù)對(duì)象
傳輸對(duì)象模式:
用于從客戶端向服務(wù)端傳輸帶有多個(gè)屬性的數(shù)據(jù)(帶有g(shù)et/set方法的POJO類 或者 序列化對(duì)象,類)
 業(yè)務(wù)對(duì)象(Business Object):為傳輸對(duì)象填充的數(shù)據(jù)
 傳輸對(duì)象(Transfer Object):簡(jiǎn)單POJO,只有設(shè)置/獲取屬性的方法
 客戶端(Client):接收傳送對(duì)象
業(yè)務(wù)的封裝:
讓業(yè)務(wù)邏輯和界面邏輯分開(kāi),降低耦合度,使之達(dá)到可擴(kuò)展,可維護(hù)
 例: 將測(cè)試代碼, 功能實(shí)現(xiàn)代碼分開(kāi)
 緊耦合,松耦合
 緊耦合:當(dāng)一個(gè)類中含有多個(gè)功能,例如Collections,當(dāng)我修改sort函數(shù), 或者添加功能有可能將其他功能改變,或者對(duì)其他功能造成影響,耦合度過(guò)高
 松耦合:
 將類中各個(gè)功能抽象出單獨(dú)的類, 然后每個(gè)類又去實(shí)現(xiàn)最初的Collections接口,或者繼承Collections,將各個(gè)功能模塊分開(kāi),使得功能之間互不影響,就此保證良好的可擴(kuò)充性
 在松耦合的前提下,需要考慮哪些功能需要單獨(dú)抽象為類,哪些不需要, 不能做沒(méi)有意義的抽象,說(shuō)明----面向?qū)ο蟮木幊?不是類越多越好, 類的劃分只是為了封裝, 分類的基礎(chǔ)是抽象, 具有相同和功能的抽象集合才是類
策略模式(行為模式):
一個(gè)類的行為或算法在運(yùn)行過(guò)程中修改,在相同條件下避免if-else帶來(lái)的復(fù)雜性,以及難以維護(hù),實(shí)現(xiàn)同一個(gè)接口讓算法之間可以做到相互替換
 優(yōu)點(diǎn):算法自由切換, 擴(kuò)展性好, 避免多重if-else判斷
 缺點(diǎn):策略類增多, 所有策略類需要對(duì)外暴露
 以相同的方式調(diào)用所有的算法,減少各種算法類與使用算法類之間的耦合;還是封裝"規(guī)則"
 基本的策略模式: 具體的策略選擇由客戶端對(duì)象選擇嗎并沒(méi)有解除客戶端選擇判斷的壓力,使用工廠模式與策略模式結(jié)合,將判斷過(guò)程轉(zhuǎn)移到工廠模式中
單一原則:
一個(gè)類中,應(yīng)該僅有一個(gè)引起它變化的原因 一個(gè)類承擔(dān)的職責(zé)過(guò)多,造成職責(zé)耦合,當(dāng)一個(gè)職責(zé)變化將會(huì)導(dǎo)致其他功能受到影響, 解決方式:將界面與代碼邏輯分開(kāi)開(kāi)放封閉原則:
對(duì)于擴(kuò)展是開(kāi)放的,對(duì)于更改是封閉的,面對(duì)需求,對(duì)程序的改動(dòng)只用于增加新的代碼,而不是改變現(xiàn)有的代碼 例:對(duì)共同存在的功能抽象為類, 增加功能的時(shí)候只需要添加實(shí)現(xiàn)類依賴倒轉(zhuǎn)原則:
高層模型不能依賴低層模型, 兩個(gè)應(yīng)該依賴接口; 例如:高層依賴低層, 當(dāng)復(fù)用高層的時(shí)候, 就需要改變低層, 造成大量代碼改動(dòng) 抽象不應(yīng)該依賴細(xì)節(jié),細(xì)節(jié)應(yīng)該依賴抽象里氏代換原則:
子類型必須能夠替換他們的父類型, 例:鳥(niǎo)類,企鵝類,企鵝類不能繼承鳥(niǎo)類(企鵝不會(huì)飛),若繼承鳥(niǎo)類,造成飛的屬性不能被復(fù)用 注:此原則保證繼承復(fù)用成為可能,只有當(dāng)子類可以替換父類,軟件的功能單位不受影響,父類才能被真正重用, 子類也可在父類的基礎(chǔ)上擴(kuò)展新的功能 總述:針對(duì)抽象編程, 依賴關(guān)系都是依賴于抽象類或接口總結(jié)
 
                            
                        - 上一篇: 在统计学中参数的含义是指_《统计学》名词
- 下一篇: java 异步调用方法_乐字节Java编
