5.4 橋接模式

5.4.1 概述

現(xiàn)在有一個需求，需要創(chuàng)建不同的圖形，并且每個圖形都有可能會有不同的顏色。我們可以利用繼承的方式來設計類的關系：

我們可以發(fā)現(xiàn)有很多的類，假如我們再增加一個形狀或再增加一種顏色，就需要創(chuàng)建更多的類。

試想，在一個有多種可能會變化的維度 系統(tǒng)中，用繼承方式會造成類爆炸，擴展起來不靈活。每次在一個維度上新增一個具體實現(xiàn)都要增加多個子類。為了更加靈活的設計系統(tǒng)，我們此時可以考慮使用橋接模式。

定義：

將抽象與實現(xiàn)分離，使它們可以獨立變化。它是用組合關系代替繼承關系來實現(xiàn)，從而降低了抽象和實現(xiàn)這兩個可變維度的耦合度。

5.4.2 結構

橋接（Bridge）模式包含以下主要角色：

• 抽象化（Abstraction）角色 ：定義抽象類，并包含一個 對實現(xiàn)化對象 的引用。
• 擴展抽象化（Refined Abstraction）角色 ：是抽象化角色的子類，實現(xiàn)父類中的業(yè)務方法，并通過組合關系調(diào)用實現(xiàn)化角色中的業(yè)務方法。
• 實現(xiàn)化（Implementor）角色 ：定義實現(xiàn)化角色的接口，供擴展抽象化角色調(diào)用。
• 具體實現(xiàn)化（Concrete Implementor）角色 ：給出實現(xiàn)化角色接口的具體實現(xiàn)。

5.4.3 案例

【例】視頻播放器

需要開發(fā)一個跨平臺視頻播放器，可以在不同操作系統(tǒng)平臺（如Windows、Mac、Linux等）上播放多種格式的視頻文件，常見的視頻格式包括RMVB、AVI、WMV等。該播放器包含了兩個維度，適合使用橋接模式。

類圖如下：

代碼如下：

//視頻文件
public interface VideoFile {void decode(String fileName);
}//avi文件
public class AVIFile implements VideoFile {public void decode(String fileName) {System.out.println("avi視頻文件："+ fileName);}
}//rmvb文件
public class REVBBFile implements VideoFile {public void decode(String fileName) {System.out.println("rmvb文件：" + fileName);}
}//操作系統(tǒng)版本
public abstract class OperatingSystemVersion {protected VideoFile videoFile;public OperatingSystemVersion(VideoFile videoFile) {this.videoFile = videoFile;}public abstract void play(String fileName);
}//Windows版本
public class Windows extends OperatingSystem {public Windows(VideoFile videoFile) {super(videoFile);}public void play(String fileName) {videoFile.decode(fileName);}
}//mac版本
public class Mac extends OperatingSystemVersion {public Mac(VideoFile videoFile) {super(videoFile);}public void play(String fileName) {videoFile.decode(fileName);}
}//測試類
public class Client {public static void main(String[] args) {OperatingSystem os = new Windows(new AVIFile());os.play("戰(zhàn)狼3");}
}

好處：

• 橋接模式提高了系統(tǒng)的可擴充性，在兩個變化維度中任意擴展一個維度，都不需要修改原有系統(tǒng)。

如：如果現(xiàn)在還有一種視頻文件類型wmv，我們只需要再定義一個類實現(xiàn)VideoFile接口即可，其他類不需要發(fā)生變化。

• 實現(xiàn)細節(jié)對客戶透明

壞處：

適配器模式容易類爆炸 , 每個維度都要創(chuàng)建多個類

5.4.4 使用場景

• 當一個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴展時。
• 當一個系統(tǒng)不希望使用繼承或因為多層次繼承導致系統(tǒng)類的個數(shù)急劇增加時。（類爆炸）
• 當一個系統(tǒng)需要在構件的抽象化角色和具體化角色之間增加更多的靈活性時。避免在兩個層次之間建立靜態(tài)的繼承聯(lián)系，通過橋接模式可以使它們在抽象層建立一個關聯(lián)關系。

裝飾是小的包裹大的，橋接是大的包裹小的

5.5 外觀模式

5.5.1 概述

有些人可能炒過股票，但其實大部分人都不太懂，這種沒有足夠了解證券知識的情況下做股票是很容易虧錢的，剛開始炒股肯定都會想，如果有個懂行的幫幫手就好，其實基金就是個好幫手，支付寶里就有許多的基金，它將投資者分散的資金集中起來，交由專業(yè)的經(jīng)理人進行管理，投資于股票、債券、外匯等領域，而基金投資的收益歸持有者所有，管理機構收取一定比例的托管管理費用。

定義：

又名門面模式，是一種通過為多個復雜的子系統(tǒng)提供一個一致的接口，而使這些子系統(tǒng)更加容易被訪問的模式。該模式對外有一個統(tǒng)一接口（基金），外部應用程序不用關心內(nèi)部子系統(tǒng)的具體的細節(jié)（投資哪些），這樣會大大降低應用程序的復雜度，提高了程序的可維護性。

外觀（Facade）模式是“迪米特法則”的典型應用

5.5.2 結構

外觀（Facade）模式包含以下主要角色：

• 外觀（Facade）角色：為多個子系統(tǒng)對外提供一個共同的接口。
• 子系統(tǒng)（Sub System）角色：實現(xiàn)系統(tǒng)的部分功能，客戶可以通過外觀角色訪問它。

5.5.3 案例

【例】智能家電控制

小明的爺爺已經(jīng)60歲了，一個人在家生活：每次都需要打開燈、打開電視、打開空調(diào)；睡覺時關閉燈、關閉電視、關閉空調(diào)；操作起來都比較麻煩。所以小明給爺爺買了智能音箱，可以通過語音直接控制這些智能家電的開啟和關閉。類圖如下：

代碼如下：

//燈類
public class Light {public void on() {System.out.println("打開了燈....");}public void off() {System.out.println("關閉了燈....");}
}//電視類
public class TV {public void on() {System.out.println("打開了電視....");}public void off() {System.out.println("關閉了電視....");}
}//控制類
public class AirCondition {public void on() {System.out.println("打開了空調(diào)....");}public void off() {System.out.println("關閉了空調(diào)....");}
}//智能音箱 外觀類 和用戶交互
public class SmartAppliancesFacade {//聚合三個電器private Light light;private TV tv;private AirCondition airCondition;public SmartAppliancesFacade() {light = new Light();tv = new TV();airCondition = new AirCondition();}public void say(String message) {if(message.contains("打開")) {on();} else if(message.contains("關閉")) {off();} else {System.out.println("我還聽不懂你說的！！！");}}//起床后一鍵開電器private void on() {System.out.println("起床了");light.on();tv.on();airCondition.on();}//睡覺一鍵關電器private void off() {System.out.println("睡覺了");light.off();tv.off();airCondition.off();}
}//測試類
public class Client {public static void main(String[] args) {//創(chuàng)建外觀對象SmartAppliancesFacade facade = new SmartAppliancesFacade();//客戶端直接與外觀對象進行交互facade.say("打開家電");facade.say("關閉家電");}
}

好處：

• 降低了子系統(tǒng)與客戶端之間的耦合度，使得子系統(tǒng)的變化不會影響調(diào)用它的客戶類。
• 對客戶屏蔽了子系統(tǒng)組件，減少了客戶處理的對象數(shù)目，并使得子系統(tǒng)使用起來更加容易。

缺點：

• 不符合開閉原則，修改很麻煩

5.5.4 使用場景

• 對分層結構系統(tǒng)構建時，使用外觀模式定義子系統(tǒng)中每層的入口點可以簡化子系統(tǒng)之間的依賴關系。
• 當一個復雜系統(tǒng)的子系統(tǒng)很多時，外觀模式可以為系統(tǒng)設計一個簡單的接口供外界訪問。
• 當客戶端與多個子系統(tǒng)之間存在很大的聯(lián)系時，引入外觀模式可將它們分離，從而提高子系統(tǒng)的獨立性和可移植性。

5.5.5 源碼解析（tomcat）

使用tomcat作為web容器時，接收瀏覽器發(fā)送過來的請求，tomcat會將請求信息封裝成Servlet Request對象，如下圖①處對象。

但是大家想想ServletRequest是一個接口，它還有一個子接口HttpServletRequest，而我們知道該request對象肯定是一個HttpServletRequest對象和ServletRequest共同的子實現(xiàn)類對象，到底是哪個類的對象呢？可以通過輸出request對象，我們就會發(fā)現(xiàn)是一個名為RequestFacade的類的對象。

RequestFacade類就使用了外觀模式。先看結構圖：

為什么在此處使用外觀模式呢？

定義 RequestFacade 類，分別實現(xiàn) ServletRequest ，同時定義私有成員變量 Request ，并且方法的實現(xiàn)調(diào)用 Request 的實現(xiàn)。然后，將 RequestFacade上轉為 ServletRequest 傳給 servlet 的 service 方法，這樣即使在 servlet 中被下轉為 RequestFacade ，也不能訪問私有成員變量對象中的方法。既用了 Request ，又能防止其中方法被不合理的訪問。

---

5.6 組合模式 day04

5.6.1 概述

對于這個圖片肯定會非常熟悉，上圖我們可以看做是一個文件系統(tǒng)，對于這樣的結構我們稱之為樹形結構。在樹形結構中可以通過調(diào)用某個方法來遍歷整個樹，當我們找到某個葉子節(jié)點后，就可以對葉子節(jié)點進行相關的操作?？梢詫⑦@顆樹理解成一個大的容器，容器里面包含很多的成員對象，這些成員對象既可是容器對象也可以是葉子對象。但是由于容器對象和葉子對象在功能上面的區(qū)別，使得我們在使用的過程中必須要區(qū)分容器對象和葉子對象，但是這樣就會給客戶帶來不必要的麻煩，作為客戶而已，它始終希望能夠一致的對待容器對象和葉子對象。

定義：

又名部分整體模式，是用于把一組相似的對象當作一個單一的對象。組合模式依據(jù)樹形結構來組合對象，用來表示部分以及整體層次。這種類型的設計模式屬于結構型模式，它創(chuàng)建了對象組的樹形結構。

5.6.2 結構

組合模式主要包含三種角色：

• 抽象根節(jié)點（Component）：定義系統(tǒng)各層次對象的共有方法和屬性，可以預先定義一些默認行為和屬性。
• 樹枝節(jié)點（Composite）：定義樹枝節(jié)點的行為，存儲子節(jié)點，組合樹枝節(jié)點和葉子節(jié)點形成一個樹形結構。
• 葉子節(jié)點（Leaf）：葉子節(jié)點對象，其下再無分支，是系統(tǒng)層次遍歷的最小單位。

5.6.3 案例實現(xiàn)

【例】軟件菜單

如下圖，我們在訪問別的一些管理系統(tǒng)時，經(jīng)?？梢钥吹筋愃频牟藛?。

一個菜單可以包含菜單項（菜單項是指不再包含其他內(nèi)容的菜單條目），也可以包含帶有其他菜單項的菜單，因此使用組合模式描述菜單就很恰當，我們的需求是針對一個菜單，打印出其包含的所有菜單以及菜單項的名稱。

要實現(xiàn)該案例，我們先畫出類圖：

代碼實現(xiàn)：

不管是菜單還是菜單項，都應該繼承自統(tǒng)一的接口，這里姑且將這個統(tǒng)一的接口稱為菜單組件。

//菜單組件  不管是菜單還是菜單項，都應該繼承該類
public abstract class MenuComponent {protected String name;protected int level;//添加菜單public void add(MenuComponent menuComponent){throw new UnsupportedOperationException();}//移除菜單public void remove(MenuComponent menuComponent){throw new UnsupportedOperationException();}//獲取指定的子菜單public MenuComponent getChild(int i){throw new UnsupportedOperationException();}//獲取菜單名稱public String getName(){return name;}public void print(){throw new UnsupportedOperationException();}
}

這里的MenuComponent定義為抽象類，因為有一些共有的屬性和行為要在該類中實現(xiàn)，Menu和MenuItem類就可以只覆蓋自己感興趣的方法，而不用搭理不需要或者不感興趣的方法，舉例來說，Menu類可以包含子菜單，因此需要覆蓋add()、remove()、getChild()方法，但是MenuItem就不應該有這些方法。這里給出的默認實現(xiàn)是拋出異常，你也可以根據(jù)自己的需要改寫默認實現(xiàn)。

public class Menu extends MenuComponent {//菜單可以有 多個子菜單 或者 子菜單項private List<MenuComponent> menuComponentList;public Menu(String name,int level){this.level = level;this.name = name;menuComponentList = new ArrayList<MenuComponent>();}@Overridepublic void add(MenuComponent menuComponent) {menuComponentList.add(menuComponent);}@Overridepublic void remove(MenuComponent menuComponent) {menuComponentList.remove(menuComponent);}@Overridepublic MenuComponent getChild(int i) {return menuComponentList.get(i);}@Overridepublic void print() {for (int i = 1; i < level; i++) {System.out.print("--");}System.out.println(name);for (MenuComponent menuComponent : menuComponentList) {menuComponent.print();}}
}

Menu類已經(jīng)實現(xiàn)了除了getName方法的其他所有方法，因為Menu類具有添加菜單，移除菜單和獲取子菜單的功能。

public class MenuItem extends MenuComponent {public MenuItem(String name,int level) {this.name = name;this.level = level;}@Overridepublic void print() {for (int i = 1; i < level; i++) {System.out.print("--");}System.out.println(name);}
}

MenuItem是菜單項，不能再有子菜單，所以添加菜單，移除菜單和獲取子菜單的功能并不能實現(xiàn)。

5.6.4 組合模式的分類

在使用組合模式時，根據(jù)抽象構件類的定義形式，我們可將組合模式分為透明組合模式和安全組合模式兩種形式。

• 透明組合模式

透明組合模式中，抽象根節(jié)點角色中聲明了所有用于管理成員對象的方法，比如在示例中 MenuComponent 聲明了 add、remove 、getChild 方法，這樣做的好處是確保所有的構件類都有相同的接口。透明組合模式也是組合模式的標準形式。

透明組合模式的缺點是不夠安全，因為葉子對象和容器對象在本質(zhì)上是有區(qū)別的，葉子對象不可能有下一個層次的對象，即不可能包含成員對象，因此為其提供 add()、remove() 等方法是沒有意義的，這在編譯階段不會出錯，但在運行階段如果調(diào)用這些方法可能會出錯（如果沒有提供相應的錯誤處理代碼）

• 安全組合模式

在安全組合模式中，在抽象構件角色中沒有聲明任何用于管理成員對象的方法，而是在樹枝節(jié)點 Menu 類中聲明并實現(xiàn)這些方法。

安全組合模式的缺點是不夠透明，因為葉子構件和容器構件具有不同的方法，且容器構件中那些用于管理成員對象的方法沒有在抽象構件類中定義，因此客戶端不能完全針對抽象編程，必須有區(qū)別地對待葉子構件和容器構件。

5.6.5 優(yōu)點

• 組合模式可以清楚地定義分層次的復雜對象，表示對象的全部或部分層次，它讓客戶端忽略了層次的差異，方便對整個層次結構進行控制。
• 客戶端可以一致地使用一個組合結構或其中單個對象，不必關心處理的是單個對象還是整個組合結構，簡化了客戶端代碼。
• 在組合模式中增加新的樹枝節(jié)點和葉子節(jié)點都很方便，無須對現(xiàn)有類庫進行任何修改，符合“開閉原則”。
• 組合模式為樹形結構的面向?qū)ο髮崿F(xiàn)提供了一種靈活的解決方案，通過葉子節(jié)點和樹枝節(jié)點的遞歸組合，可以形成復雜的樹形結構，但對樹形結構的控制卻非常簡單。

5.6.6 使用場景

組合模式正是應樹形結構而生，所以組合模式的使用場景就是出現(xiàn)樹形結構的地方。比如：文件目錄顯示，多級目錄呈現(xiàn)等樹形結構數(shù)據(jù)的操作。

5.7 享元模式（無）

5.7.1 概述

定義：

運用共享技術來有效地支持大量細粒度對象的復用。它通過共享已經(jīng)存在的對象來大幅度減少需要創(chuàng)建的對象數(shù)量、避免大量相似對象的開銷，從而提高系統(tǒng)資源的利用率。

5.7.2 結構

享元（Flyweight ）模式中存在以下兩種狀態(tài)：

1. 內(nèi)部狀態(tài)，即不會隨著環(huán)境的改變而改變的可共享部分。
2. 外部狀態(tài)，指隨環(huán)境改變而改變的不可以共享的部分。享元模式的實現(xiàn)要領就是區(qū)分應用中的這兩種狀態(tài)，并將外部狀態(tài)外部化。

享元模式的主要有以下角色：

• 抽象享元角色（Flyweight）：通常是一個接口或抽象類，在抽象享元類中聲明了具體享元類公共的方法，這些方法可以向外界提供享元對象的內(nèi)部數(shù)據(jù)（內(nèi)部狀態(tài)），同時也可以通過這些方法來設置外部數(shù)據(jù)（外部狀態(tài)）。
• 具體享元（Concrete Flyweight）角色 ：它實現(xiàn)了抽象享元類，稱為享元對象；在具體享元類中為內(nèi)部狀態(tài)提供了存儲空間。通常我們可以結合單例模式來設計具體享元類，為每一個具體享元類提供唯一的享元對象。
• 非享元（Unsharable Flyweight)角色 ：并不是所有的抽象享元類的子類都需要被共享，不能被共享的子類可設計為非共享具體享元類；當需要一個非共享具體享元類的對象時可以直接通過實例化創(chuàng)建。
• 享元工廠（Flyweight Factory）角色 ：負責創(chuàng)建和管理享元角色。當客戶對象請求一個享元對象時，享元工廠檢査系統(tǒng)中是否存在符合要求的享元對象，如果存在則提供給客戶；如果不存在的話，則創(chuàng)建一個新的享元對象。

5.7.3 案例實現(xiàn)

【例】俄羅斯方塊

下面的圖片是眾所周知的俄羅斯方塊中的一個個方塊，如果在俄羅斯方塊這個游戲中，每個不同的方塊都是一個實例對象，這些對象就要占用很多的內(nèi)存空間，下面利用享元模式進行實現(xiàn)。

先來看類圖：

代碼如下：

俄羅斯方塊有不同的形狀，我們可以對這些形狀向上抽取出AbstractBox，用來定義共性的屬性和行為。

public abstract class AbstractBox {public abstract String getShape();public void display(String color) {System.out.println("方塊形狀：" + this.getShape() + " 顏色：" + color);}
}

接下來就是定義不同的形狀了，IBox類、LBox類、OBox類等。

public class IBox extends AbstractBox {@Overridepublic String getShape() {return "I";}
}public class LBox extends AbstractBox {@Overridepublic String getShape() {return "L";}
}public class OBox extends AbstractBox {@Overridepublic String getShape() {return "O";}
}

提供了一個工廠類（BoxFactory），用來管理享元對象（也就是AbstractBox子類對象），該工廠類對象只需要一個，所以可以使用單例模式。并給工廠類提供一個獲取形狀的方法。

public class BoxFactory {private static HashMap<String, AbstractBox> map;private BoxFactory() {map = new HashMap<String, AbstractBox>();AbstractBox iBox = new IBox();AbstractBox lBox = new LBox();AbstractBox oBox = new OBox();map.put("I", iBox);map.put("L", lBox);map.put("O", oBox);}public static final BoxFactory getInstance() {return SingletonHolder.INSTANCE;}private static class SingletonHolder {private static final BoxFactory INSTANCE = new BoxFactory();}public AbstractBox getBox(String key) {return map.get(key);}
}

5.7.5 優(yōu)缺點和使用場景

1，優(yōu)點

• 極大減少內(nèi)存中相似或相同對象數(shù)量，節(jié)約系統(tǒng)資源，提供系統(tǒng)性能
• 享元模式中的外部狀態(tài)相對獨立，且不影響內(nèi)部狀態(tài)

2，缺點：

為了使對象可以共享，需要將享元對象的部分狀態(tài)外部化，分離內(nèi)部狀態(tài)和外部狀態(tài)，使程序邏輯復雜

3，使用場景：

• 一個系統(tǒng)有大量相同或者相似的對象，造成內(nèi)存的大量耗費。
• 對象的大部分狀態(tài)都可以外部化，可以將這些外部狀態(tài)傳入對象中。
• 在使用享元模式時需要維護一個存儲享元對象的享元池，而這需要耗費一定的系統(tǒng)資源，因此，應當在需要多次重復使用享元對象時才值得使用享元模式。

5.7.6 JDK源碼解析

Integer類使用了享元模式。我們先看下面的例子：

public class Demo {public static void main(String[] args) {Integer i1 = 127;Integer i2 = 127;System.out.println("i1和i2對象是否是同一個對象？" + (i1 == i2));Integer i3 = 128;Integer i4 = 128;System.out.println("i3和i4對象是否是同一個對象？" + (i3 == i4));}
}

運行上面代碼，結果如下：

為什么第一個輸出語句輸出的是true，第二個輸出語句輸出的是false？通過反編譯軟件進行反編譯，代碼如下：

public class Demo {public static void main(String[] args) {Integer i1 = Integer.valueOf((int)127);Integer i2 Integer.valueOf((int)127);System.out.println((String)new StringBuilder().append((String)"i1\u548ci2\u5bf9\u8c61\u662f\u5426\u662f\u540c\u4e00\u4e2a\u5bf9\u8c61\uff1f").append((boolean)(i1 == i2)).toString());Integer i3 = Integer.valueOf((int)128);Integer i4 = Integer.valueOf((int)128);System.out.println((String)new StringBuilder().append((String)"i3\u548ci4\u5bf9\u8c61\u662f\u5426\u662f\u540c\u4e00\u4e2a\u5bf9\u8c61\uff1f").append((boolean)(i3 == i4)).toString());}
}

上面代碼可以看到，直接給Integer類型的變量賦值基本數(shù)據(jù)類型數(shù)據(jù)的操作底層使用的是 valueOf() ，所以只需要看該方法即可

public final class Integer extends Number implements Comparable<Integer> {public static Integer valueOf(int i) {if (i >= IntegerCache.low && i <= IntegerCache.high)return IntegerCache.cache[i + (-IntegerCache.low)];return new Integer(i);}private static class IntegerCache {static final int low = -128;static final int high;static final Integer cache[];static {int h = 127;String integerCacheHighPropValue =sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");if (integerCacheHighPropValue != null) {try {int i = parseInt(integerCacheHighPropValue);i = Math.max(i, 127);// Maximum array size is Integer.MAX_VALUEh = Math.min(i, Integer.MAX_VALUE - (-low) -1);} catch( NumberFormatException nfe) {}}high = h;cache = new Integer[(high - low) + 1];int j = low;for(int k = 0; k < cache.length; k++)cache[k] = new Integer(j++);// range [-128, 127] must be interned (JLS7 5.1.7)assert IntegerCache.high >= 127;}private IntegerCache() {}}
}

可以看到 Integer 默認先創(chuàng)建并緩存 -128 ~ 127 之間數(shù)的 Integer 對象，當調(diào)用 valueOf 時如果參數(shù)在 -128 ~ 127 之間則計算下標并從緩存中返回，否則創(chuàng)建一個新的 Integer 對象。

非常感謝您閱讀到這里，創(chuàng)作不易！如果這篇文章對您有幫助，希望能留下您的點贊👍 關注💖 收藏 💕評論💬感謝支持！！！

聽說 三連能夠給人 帶來好運！更有可能年入百w，進入大廠，上岸