簡易理解設(shè)計模式之：橋接模式——穿衣服經(jīng)典案例2

介紹：

橋接模式屬于結(jié)構(gòu)型模式苗桂。它的定義為：將抽象部分與實現(xiàn)部分分離，使它們都可以獨立的變化夺艰。

類圖：

橋接模式UML類圖.png

Abstraction（抽象化角色）：抽象部分黄痪，保持對實現(xiàn)部分對象的引用，抽象部分中的方法需要調(diào)用實現(xiàn)部分的對象來實現(xiàn)见秽。
RefinedAbstraction（具體抽象化角色）：優(yōu)化后的抽象部分愉烙，一般是對抽象部分的方法進行完善和擴展
Implementor（實現(xiàn)化角色）：實現(xiàn)部分，提供基本操作
ConcreteImplementor（具體實現(xiàn)化角色）：實現(xiàn)部分的具體實現(xiàn)

用法：

?　一個類存在兩個獨立變化的維度解取，且這兩個維度都需要進行擴展
?　不希望使用繼承或因為多層次繼承導(dǎo)致系統(tǒng)類的個數(shù)急劇增加時步责，可以考慮使用此模式
?　任何多維度變化類之間的耦合都可以使用橋接模式來實現(xiàn)解耦

個人理解：
橋接模式的必要條件是存在兩個維度的獨立變化，將其中一個維度劃分成此模式的“抽象角色”禀苦，另外一個維度劃分成“實現(xiàn)角色”蔓肯。

例子：

眾所周知，人會根據(jù)不同的場合穿著不同的衣服振乏。就以男人為例蔗包，上班時會著裝正式（領(lǐng)帶、襯衫慧邮、外套调限、西褲邻储、皮鞋、手表等）旧噪，睡覺時會穿舒適（睡衣吨娜、睡褲等），運動時會穿運動服（T恤衫淘钟、運動褲宦赠、運動鞋等）。在這例子中米母，男人就是抽象化角色勾扭，各種服飾就是實現(xiàn)化角色。

需求：輸出男人在以上三種場合的著裝要求

1铁瞒、實現(xiàn)化角色

public abstract class Finery {
    public abstract void dress();
}

各種服飾子類：

public class Jacket extends Finery {
    @Override
    public void dress() {
        System.out.println("外套");
    }
}

public class Sleepcoat extends Finery {
    @Override
    public void dress() {
        System.out.println("睡衣");
    }
}

public class TShirt extends Finery {
    @Override
    public void dress() {
        System.out.println("T恤衫");
    }
}

2妙色、抽象化角色

public class Man {
    private Finery finery;

    public Man(Finery finery) {
        this.finery = finery;
    }

    public void dress() {
        if (finery != null) {
            finery.dress();
        }
    }
}

抽象化角色保持對實現(xiàn)部分對象的引用。因此持有了Finery對象的引用慧耍，在這里將Abstraction（抽象化角色）和RefinedAbstraction（具體抽象化角色）合二為一身辨。

3、測試與實現(xiàn)

public class Client {
    public static void main(String[] args) {
        //上班的男人
        Man man = new Man(new Jacket());
        man.dress();

        //睡覺的男人
        man = new Man(new Sleepcoat());
        man.dress();

        //運動的男人
        man = new Man(new TShirt());
        man.dress();

    }
}

外套
睡衣
T恤衫

通過此例子芍碧，分離了兩個維度的變化：男人和服飾煌珊。基本功能就完成了泌豆《ㄢ郑可以看得出這個模式非常簡單。

總結(jié)：

此模式告訴我們踪危，面對多維度的變化的問題蔬浙，我們盡量使用合成/聚合，盡量不要使用繼承贞远。

另外畴博，在裝飾模式——穿衣服經(jīng)典案例中提到第二點方案，原來這就是橋接模式啊兴革。當(dāng)時提到：用繼承的方法會令到子類的數(shù)量暴增并且可能存在大量重復(fù)代碼绎晃，造成代碼臃腫，最終就是難以維護。所以此模式不適合在某一個維度中獨立變化的子類非常多的情況下使用袁余。

感謝您的閱讀~

轉(zhuǎn)載請注明出處喔：http://www.reibang.com/p/07109eeb319c

推薦閱讀

基礎(chǔ)篇：
設(shè)計模式前篇之——UML類圖必會知識點
 設(shè)計模式前篇之——一起過一下面向?qū)ο蟮母拍?/a>
創(chuàng)建型模式：
簡易理解設(shè)計模式之：簡單工廠模式——來試試接入支付功能
 簡易理解設(shè)計模式之：工廠方法模式——數(shù)據(jù)存儲例子
 簡易理解設(shè)計模式之：抽象工廠模式——更換數(shù)據(jù)庫例子
 簡易理解設(shè)計模式之：建造者模式——學(xué)習(xí)使用“鏈?zhǔn)秸{(diào)用”
簡易理解設(shè)計模式之：原型模式——深擎勘、淺拷貝的概念
 簡易理解設(shè)計模式之：單例模式——單例模式的幾種常用寫法
結(jié)構(gòu)型模式：
簡易理解設(shè)計模式之：適配器模式——Android列表視圖控件設(shè)計方式