設計模式中篇

9橋接模式
實現的系統可以多角度分類,每一個分類又有多種變化,就把變化分離出來讓它們獨立變化,減少耦合。
適用場景:當需要大量的繼承類處理的時候,造成有大量的繼承類,可以適用橋接模式。橋接模式用聚合和合成代替繼承。
例如手機有多個品牌,每個品牌有各自多個功能,這會涉及大量的繼承。
10模板模式
在模板模式(Template Pattern)中,一個抽象類公開定義了執行它的方法的方式/模板。它的子類可以按需要重寫方法實現,但調用將以抽象類中定義的方式進行。這種類型的設計模式屬於行爲型模式。
介紹
意圖:定義一個操作中的算法的骨架,而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
主要解決:一些方法通用,卻在每一個子類都重新寫了這一方法。
何時使用:有一些通用的方法。
如何解決:將這些通用算法抽象出來。
關鍵代碼:在抽象類實現,其他步驟在子類實現。
應用實例: 1、在造房子的時候,地基、走線、水管都一樣,只有在建築的後期纔有加壁櫥加柵欄等差異。 2、西遊記裏面菩薩定好的 81 難,這就是一個頂層的邏輯骨架。 3、spring 中對 Hibernate 的支持,將一些已經定好的方法封裝起來,比如開啓事務、獲取 Session、關閉 Session 等,程序員不重複寫那些已經規範好的代碼,直接丟一個實體就可以保存。
優點: 1、封裝不變部分,擴展可變部分。 2、提取公共代碼,便於維護。 3、行爲由父類控制,子類實現。
缺點:每一個不同的實現都需要一個子類來實現,導致類的個數增加,使得系統更加龐大。
使用場景: 1、有多個子類共有的方法,且邏輯相同。 2、重要的、複雜的方法,可以考慮作爲模板方法。
注意事項:爲防止惡意操作,一般模板方法都加上 final 關鍵詞。
11外觀模式
外觀模式(Facade Pattern)隱藏系統的複雜性,並向客戶端提供了一個客戶端可以訪問系統的接口。這種類型的設計模式屬於結構型模式,它向現有的系統添加一個接口,來隱藏系統的複雜性。
這種模式涉及到一個單一的類,該類提供了客戶端請求的簡化方法和對現有系統類方法的委託調用。
例如股民買多支股票,多個股票相當於多個類,股民相當於客戶端類,需要調用多個類,這個時候如果使用外觀模式,外觀類調用多個類,而客戶端類只需要調用外觀類。
12享元模式
享元模式(Flyweight Pattern)主要用於減少創建對象的數量,以減少內存佔用和提高性能。這種類型的設計模式屬於結構型模式,它提供了減少對象數量從而改善應用所需的對象結構的方式。
享元模式嘗試重用現有的同類對象,如果未找到匹配的對象,則創建新對象。我們將通過創建 5 個對象來畫出 20 個分佈於不同位置的圓來演示這種模式。由於只有 5 種可用的顏色,所以 color 屬性被用來檢查現有的 Circle 對象。
介紹
意圖:運用共享技術有效地支持大量細粒度的對象。
主要解決:在有大量對象時,有可能會造成內存溢出,我們把其中共同的部分抽象出來,如果有相同的業務請求,直接返回在內存中已有的對象,避免重新創建。
何時使用: 1、系統中有大量對象。 2、這些對象消耗大量內存。 3、這些對象的狀態大部分可以外部化。 4、這些對象可以按照內蘊狀態分爲很多組,當把外蘊對象從對象中剔除出來時,每一組對象都可以用一個對象來代替。 5、系統不依賴於這些對象身份,這些對象是不可分辨的。
如何解決:用唯一標識碼判斷,如果在內存中有,則返回這個唯一標識碼所標識的對象。
關鍵代碼:用 HashMap 存儲這些對象。
應用實例: 1、JAVA 中的 String,如果有則返回,如果沒有則創建一個字符串保存在字符串緩存池裏面。 2、數據庫的數據池。
優點:大大減少對象的創建,降低系統的內存,使效率提高。
缺點:提高了系統的複雜度,需要分離出外部狀態和內部狀態,而且外部狀態具有固有化的性質,不應該隨着內部狀態的變化而變化,否則會造成系統的混亂。
使用場景: 1、系統有大量相似對象。 2、需要緩衝池的場景。
注意事項: 1、注意劃分外部狀態和內部狀態,否則可能會引起線程安全問題。 2、這些類必須有一個工廠對象加以控制
13代理模式
在代理模式(Proxy Pattern)中,一個類代表另一個類的功能。這種類型的設計模式屬於結構型模式。
在代理模式中,我們創建具有現有對象的對象,以便向外界提供功能接口。
應用實例:spring aop 和spring事務。
14責任鏈模式
顧名思義,責任鏈模式(Chain of Responsibility Pattern)爲請求創建了一個接收者對象的鏈。這種模式給予請求的類型,對請求的發送者和接收者進行解耦。這種類型的設計模式屬於行爲型模式。
在這種模式中,通常每個接收者都包含對另一個接收者的引用。如果一個對象不能處理該請求,那麼它會把相同的請求傳給下一個接收者,依此類推。
舉例:請假審批 通常是 組長,經理,董事長,他們根據不同的請假天數,走到不同的職位審批。這樣請假者類就會有大量的if判斷,相同的方法是三個職位都是同意或者到下一級。這樣把這個方法抽象爲一個父類,子類去實現,並且每個子類的構造方法傳入下一個子類,這樣就是職責鏈模式。
15觀察者模式
當對象間存在一對多關係時,則使用觀察者模式(Observer Pattern)。比如,當一個對象被修改時,則會自動通知它的依賴對象。觀察者模式屬於行爲型模式。
介紹
意圖:定義對象間的一種一對多的依賴關係,當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並被自動更新。
主要解決:一個對象狀態改變給其他對象通知的問題,而且要考慮到易用和低耦合,保證高度的協作。
何時使用:一個對象(目標對象)的狀態發生改變,所有的依賴對象(觀察者對象)都將得到通知,進行廣播通知。
如何解決:使用面向對象技術,可以將這種依賴關係弱化。
關鍵代碼:在抽象類裏有一個 ArrayList 存放觀察者們。
應用實例: 1、拍賣的時候,拍賣師觀察最高標價,然後通知給其他競價者競價。
優點: 1、觀察者和被觀察者是抽象耦合的。 2、建立一套觸發機制。
缺點: 1、如果一個被觀察者對象有很多的直接和間接的觀察者的話,將所有的觀察者都通知到會花費很多時間。 2、如果在觀察者和觀察目標之間有循環依賴的話,觀察目標會觸發它們之間進行循環調用,可能導致系統崩潰。 3、觀察者模式沒有相應的機制讓觀察者知道所觀察的目標對象是怎麼發生變化的,而僅僅只是知道觀察目標發生了變化。
16狀態模式
在狀態模式(State Pattern)中,類的行爲是基於它的狀態改變的。這種類型的設計模式屬於行爲型模式。
在狀態模式中,我們創建表示各種狀態的對象和一個行爲隨着狀態對象改變而改變的 context 對象。

介紹
意圖:允許對象在內部狀態發生改變時改變它的行爲,對象看起來好像修改了它的類。
主要解決:對象的行爲依賴於它的狀態(屬性),並且可以根據它的狀態改變而改變它的相關行爲。
何時使用:代碼中包含大量與對象狀態有關的條件語句。
如何解決:將各種具體的狀態類抽象出來。
關鍵代碼:通常命令模式的接口中只有一個方法。而狀態模式的接口中有一個或者多個方法。而且,狀態模式的實現類的方法,一般返回值,或者是改變實例變量的值。也就是說,狀態模式一般和對象的狀態有關。實現類的方法有不同的功能,覆蓋接口中的方法。狀態模式和命令模式一樣,也可以用於消除 if…else 等條件選擇語句。
17命令模式
命令模式(Command Pattern)是一種數據驅動的設計模式,它屬於行爲型模式。請求以命令的形式包裹在對象中,並傳給調用對象。調用對象尋找可以處理該命令的合適的對象,並把該命令傳給相應的對象,該對象執行命令。
介紹
意圖:將一個請求封裝成一個對象,從而使您可以用不同的請求對客戶進行參數化。
主要解決:在軟件系統中,行爲請求者與行爲實現者通常是一種緊耦合的關係,但某些場合,比如需要對行爲進行記錄、撤銷或重做、事務等處理時,這種無法抵禦變化的緊耦合的設計就不太合適。
何時使用:在某些場合,比如要對行爲進行"記錄、撤銷/重做、事務"等處理,這種無法抵禦變化的緊耦合是不合適的。在這種情況下,如何將"行爲請求者"與"行爲實現者"解耦?將一組行爲抽象爲對象,可以實現二者之間的鬆耦合。
如何解決:通過調用者調用接受者執行命令,順序:調用者→接受者→命令。
關鍵代碼:定義三個角色:1、received 真正的命令執行對象 2、Command 3、invoker 使用命令對象的入口

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章