《设计模式》3.结构型模式

时间  2019-12-07
标签 设计模式 构型 模式 繁體版
原文   原文链接

点击进入个人博客

3.1 适配器模式

适配器模式把一个类的接口变换成客户端所期待的另外一种接口，使得本来因接口不匹配而没法在一块儿工做的两个类可以在一块儿工做。java

3.1.1 类的适配器结构

类的适配器

  • 目标（Target）角色：这就是所期待获得的接口，因为是类适配器模式，所以目标不能够是类。
  • 源（Adaptee）角色：现有须要适配的接口。
  • 适配器（Adapter）角色：适配器类是本模式的核心，必须是具体类。
interface Target {
    void operation1();
    void operation2();
}

class Adaptee {
    public void operation1() {}
}

class Adapter extends Adaptee implements Target {
    @Override
    public void operation2() {}
}
类的适配器
  • 类的适配器模式把被的类的API转换成目标类的API。
  • 是经过继承实现的。
类的适配器效果
  • 使用一个具体类把源适配到目标中。这样若是源以及源的子类都使用此类适配，就行不通了。
  • 因为适配器是源的子类，所以能够在适配器中重写源的一些方法。
  • 因为引进了一个适配器类，所以只有一个线路到达目标类，是问题获得简化。

3.1.2 对象的适配器结构

对象适配器

  • 目标（Target）角色：这就是所期待获得的接口，所以目标能够是具体或抽象的类。
  • 源（Adaptee）角色：现有须要适配的接口。
  • 适配器（Adapter）角色：适配器类是本模式的核心，必须是具体类。
interface Target {
    void operation1();
    void operation2();
}

class Adaptee {
    public void operation1() {}
}

class Adapter implements Target {
    private Adaptee adaptee;

    public Adapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }

    @Override
    public void operation1() {
        adaptee.operation1();
    }

    @Override
    public void operation2() {
        // do something
    }
}
对象的适配器
  • 对象的适配器是经过依赖实现的
  • 推荐使用该方法
对象的适配器效果
  • 一个适配器能够把多种不一样的源适配到同一个目标，即同一个适配器能够把源类和它的子类都适配到目标接口
  • 与类的适配器模式相比，要想置换源类的方法就不容易。
  • 增长新的方法方便的多

3.1.3 细节

使用场景
  1. 系统须要使用现有的类，而此类的接口不符合系统的须要
  2. 想要创建一个能够重复使用的类，用于与一些彼此间没有太大关联的一些类，包括一些可能在未来引进的类一块儿工做。
  3. 对对象的适配器儿模式而言，在设计里，须要改变多个已有的子类的接口，若是使用类的适配器模式，就须要针对每一个子类作一个适配器类，这不太实际。
优势
  1. 可让任何两个没有关联的类一块儿运行。
  2. 提升了类的复用。
  3. 增长了类的透明度。
  4. 灵活性好。
缺点
  1. 过多地使用适配器，会让系统很是零乱，不易总体进行把握。好比，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统若是太多出现这种状况，无异于一场灾难。所以若是不是颇有必要，能够不使用适配器，而是直接对系统进行重构。
  2. 因为 JAVA 至多继承一个类，因此至多只能适配一个适配者类，并且目标类必须是抽象类。
注意点
  1. 目标接口能够忽略，此时目标接口和源接口其实是相同的
  2. 适配器类能够是抽象类
  3. 能够有带参数的适配器模式

3.1.4 一个充电器案例

// 充电器只能接受USB接口
public class Charger {
    public static void main(String[] args) throws Exception{
        USB usb = new SuperAdapter(new TypeC());
        connect(usb);
        usb = new SuperAdapter(new Lightning());
        connect(usb);
    }

    public static void connect(USB usb) {
        usb.power();
        usb.data();
    }
}

// 充电器的接口都是USB的，假设有两个方法分别是电源和数据
interface USB {
    void power();
    void data();
}

// IOS的Lightning接口
class Lightning {
    void iosPower() {
        System.out.println("IOS Power");
    }
    void iosData() {
        System.out.println("IOS Data");
    }
}

// TYPE-C接口
class TypeC {
    void typeCPower() {
        System.out.println("TypeC Power");
    }
    void typeCData() {
        System.out.println("TypeC Data");
    }
}

// 超级适配器，能够适配多种手机机型
class SuperAdapter implements USB {
    private Object obj;

    public SuperAdapter(Object obj) {
        this.obj = obj;
    }

    @Override
    public void power() {
        if(obj.getClass() == Lightning.class) {
            ((Lightning)obj).iosPower();
        } else if(obj.getClass() == TypeC.class) {
            ((TypeC)obj).typeCPower();
        }
    }

    @Override
    public void data() {
        if(obj.getClass() == Lightning.class) {
            ((Lightning)obj).iosData();
        } else if(obj.getClass() == TypeC.class) {
            ((TypeC)obj).typeCData();
        }
    }
}

3.2 缺省适配模式

缺省适配模式为一个接口提供缺省实现，这样子类型能够从这个缺省实现进行扩展，而没必要从原有接口进行扩展。ios

3.2.1 缺省适配模式结构

缺省适配模式

简单的例子
  • 下面程序中，Monk接口定义了两个方法，因而它的子类必须实现这两个方法。
  • 但出现了一个LuZhiShen，他只能实现一部分方法，另外一部分方法没法实现
  • 因此须要一个抽象的适配类MonkAdapter实现此Monk接口，此抽象类给接口全部方法都提供一个空的方法，LuZhiShen只须要继承该适配类便可。
// 和尚
interface Monk {
    void practiceKungfu();
    void chantPrayer();
}

abstract class MonkAdapter implements Monk {
    @Override
    public void practiceKungfu() {}

    @Override
    public void chantPrayer() {}
}

class LuZhiShen extends MonkAdapter {
    @Override
    public void practiceKungfu() {
        System.out.println("拳打镇关西");
    }
}

3.2.2 细节

使用场景
  • 任什么时候候不许备实现一个接口中全部方法的时候
做用

缺省适配器模式可使所须要的类没必要实现不须要的接口。数据库

核心点
  • 缺省适配的类必须是抽象类，由于这个类不该当被实例化
  • 缺省适配的类提供的方法必须是具体的方法，而不是抽象的方法。

3.3 组合模式

组合模式，就是在一个对象中包含其余对象，这些被包含的对象多是终点对象（再也不包含别的对象），也有多是非终点对象（其内部还包含其余对象）。
咱们将对象称为节点，即一个根节点包含许多子节点，这些子节点有的再也不包含子节点，而有的仍然包含子节点，以此类推。很明显，这是树形结构，终结点叫叶子节点，非终节点叫树枝节点，第一个节点叫根节点。编程

3.3.1 安全式的合成模式结构

安全式的合成模式要求管理集合的方法只出如今树枝结点（Composite）中，而不出如今树叶结点中。
安全式的合成模式设计模式

  • 抽象构建（Component）角色：这是一个抽象角色，他给参加组合的对象定义出公共的接口及其默认行为，能够用来管理全部的子对象。
  • 树叶（Leaf）角色：树叶是没有子对象的对象，定义出参加组合的原始对象的行为。
  • 树枝（Composite）角色：表明参加组合的有下级子对象的对象。树枝构件类给出全部管理子对象的方法。

3.3.2 透明的合成模式结构

透明的合成模式
透明的合成模式要求全部的具体构建类，都符合一个固定的接口。安全

3.4 装饰器模式

装饰器模式（Decorator）容许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是做为现有的类的一个包装。ide

3.4.1 装饰器结构

装饰器模式

  • 抽象构件（Component）角色：给出一个抽象结构，以规范准备接受附加责任的对象。
  • 具体构件（Concrete Component）角色：定义一个要接受附加责任的类
  • 装饰（Decorator）角色：持有一个构件对象的实例，并定义一个与抽象构件接口一致的接口。
  • 具体装饰（Concrete Decorator）角色：负责给构件对象“贴上”附加的责任。

3.4.2 装饰器细节

使用场景
  1. 须要扩展一个类的功能
  2. 须要动态地给一个对象增长功能，这些功能能够再动态的插销
  3. 须要增长由一些基本功能的排列组合而产生很是大量的功能
优势
  1. 更加灵活：装饰模式和继承关系的目的都是要扩展对象的功能，可是装饰模式比继承更加灵活
  2. 多样性：经过使用不一样具体装饰类及其排列组合，能够创造出不一样的行为
  3. 动态扩展：装饰器能够动态扩展构件类
缺点
  1. 会产生比继承关系更多的对象
  2. 比继承更加容易出错
注意点
  1. 装饰类的接口必须与被装饰类的接口相容。
  2. 尽可能保持抽象构件（Component）简单。
  3. 能够没有抽象的（Component），此时装饰器（Decorator）通常是具体构件（Concrete Component）的一个子类。
  4. 装饰（Decorator）和具体装饰（Concrete Decorator）能够合并。
InputStream及其子类

InputStream

  • 抽象构件（Component）角色：InputStream
  • 具体构件（Concrete Component）角色：ByteArrayInputStream、PipedInputStream、StringBufferInputStream等原始流处理器。
  • 装饰（Decorator）角色：FilterInputStream
  • 具体装饰（Concrete Decorator）角色：DateInputStream、BufferedInputStream、LineNumberInputStream
OutputStream及其子类

也用到类装饰器模式this

3.4.3 例子

// Component：一个艺人
interface Artist {
    void show();
}

// Concrete Component：一个歌手
class Singer implements Artist {
    @Override
    public void show() {
        System.out.println("Let It Go");
    }
}

// 装饰后的歌手：不只会唱歌，还会讲笑话和跳舞
class SuperSinger implements Artist {
    private Artist role;
    
    public SuperSinger(Artist role) {
        this.role = role;
    }
    @Override
    public void show() {
        System.out.println("Tell Jokes！");
        role.show();
        System.out.println("Dance！");
    }
}

3.5 代理模式

代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象对引用。spa

3.5.1 代理模式结构

代理模式

  • 抽象主题（Subject）角色：声明了真实主题和代理主题的共同接口
  • 代理主题（Proxy）角色：代理主题角色内部含有对真实主题的引用，从而能够在任什么时候候操做真实主题对象；代理主题角色提供一个与真实主题角色相同的接口，以即可以在任什么时候候均可以替代真实主题控制对真实主题的引用，负责在须要的时候建立真实主题对象（和删除真实主题对象）；代理角色一般在将客户端调用传递给真实的主题以前或以后，都要执行某个操做，而不是单纯地将调用传递给真实主题对象。
  • 真实主题（RealSubject）角色：定义了代理角色所表明的真实对象。
public class Test {
    public static void main(String[] args) {
        Subject subject = new RealSubject();
        Subject proxy = new ProxySubject(subject);
        proxy.request(); // 此处经过代理类来执行
    }
}

interface Subject {
    void request();
}

class RealSubject implements Subject {
    @Override
    public void request() {
        System.out.println("RealSubject");
    }
}

class ProxySubject implements Subject {
    private Subject subject;

    public ProxySubject(Subject subject) {
        this.subject = subject;
    }

    @Override
    public void request() {
        System.out.println("ProxySubject");
    }
}

3.5.2 动态代理

自从JDK 1.3之后，Java在java.lang.reflect库中提供了一下三个类直接支持代理模式：Proxy、InvocationHander、Method。设计

动态代理步骤
  1. 建立一个真实对象
  2. 建立一个与真实对象有关的调用处理器对象InvocationHandler
  3. 建立代理，把调用处理器和要代理的类联系起来Proxy.newInstance()
  4. 在调用处理对象的invoke()方法中执行相应操做
public class Test {
    public static void main(String[] args) {
        // 建立要被代理的实例对象
        Subject subject = new RealSubject();
        // 建立一个与被代理实例对象有关的InvocationHandler
        InvocationHandler handler = new ProxySubject(subject);
        // 建立一个代理对象来代理subject，被代理的对象subject的每一个方法执行都会调用代理对象proxySubject的invoke方法
        Subject proxySubject = (Subject) Proxy.newProxyInstance(Subject.class.getClassLoader(), new Class[]{Subject.class}, handler);
        // 代理对象执行
        proxySubject.request();
    }
}

interface Subject {
    void request();
}

class RealSubject implements Subject {
    @Override
    public void request() {
        System.out.println("RealSubject");
    }
}

class ProxySubject implements InvocationHandler {
    private Subject subject;

    public ProxySubject(Subject subject) {
        this.subject = subject;
    }

    /**
     * @param proxy 要代理的
     * @param method
     * @param args
     * @return
     */
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("Before Proxy");
        Object obj = method.invoke(subject, args);
        System.out.println("After Proxy");
        return obj;
    }
}
  • 可使用范型来建立ProxySubject
  • 可使用匿名内部类减小代码数量请查看14.7节

3.5.3 细节

优势
  1. 代理类和真实类分离，职责清晰。
  2. 在不改变真是累代码的基础上扩展了功能。
缺点
  1. 因为在客户端和真实主题之间增长了代理对象，所以有些类型的代理模式可能会形成请求的处理速度变慢。
  2. 实现代理模式须要额外的工做，有些代理模式的实现很是复杂。
和适配器模式的关系

适配器模式的用意是改变所考虑对象的接口，而代理模式不能改变。

和装饰模式
  • 装饰模式应当为所装饰的对象提供加强功能
  • 代理模式对对象的使用施加控制，并不提供对象自己的加强功能
虚拟代理
  • 虚拟代理模式（Virtual PRoxy）会推迟真正所需对象实例化时间。在须要真正的对象工做以前，若是代理对象可以处理，那么暂时不须要真正对象来出手。
  • 当一个真实主题对象的加载须要耗费资源时，一个虚拟代理对象能够代替真实对象接受请求，并展现“正在加载”的信息，并在适当的时候加载真实主题对象。

3.6 享元模式

享元模式以共享的方式高效地支持大量的细粒度对象。

3.6.1 单纯享元模式

单纯享元模式中，全部的享元对象都是能够共享的。
单纯享元模式

  • 抽象享元（Flyweight）角色：是全部具体享元角色的超类，并为这些类规定公共接口。
  • 具体享元（Concrete Flyweight）角色：实现抽象享元的接口。若是由内蕴状态的话，必须负责为内蕴状态提供空间。
  • 享元工厂（Flyweight Factory）角色：负责建立和管理享元角色。若是系统中有了则返回该角色，没有则建立。
  • 客户端（Client）角色：维护一个全部享元对象的引用。存储全部享元对象的外蕴状态。

3.6.2 复合享元模式

复合享元模式

  • 抽象享元（Flyweight）角色 ：给出一个抽象接口，以规定出全部具体享元角色须要实现的方法。
  • 具体享元（ConcreteFlyweight）角色：实现抽象享元角色所规定出的接口。若是有内蕴状态的话，必须负责为内蕴状态提供存储空间。
  • 复合享元（ConcreteCompositeFlyweight）角色 ：复合享元角色所表明的对象是不能够共享的，可是一个复合享元对象能够分解成为多个自己是单纯享元对象的组合。复合享元角色又称做不可共享的享元对象（UnsharedConcreteFlyweight）。
  • 享元工厂(FlyweightFactory)角色 ：负责建立和管理享元角色。当一个客户端对象调用一个享元对象的时候，若是已经有了，享元工厂角色就应当提供这个已有的享元对象；若是系统中没有一个适当的享元对象的话，享元工厂角色就应当建立一个合适的享元对象。

3.6.3 细节

内蕴状态和外蕴状态

内蕴状态：是存储在享元对象内部的，不会随环境改变而改变的。一个享元能够具备内蕴状态并能够共享。
外蕴状态：随环境改变而改变、不能够共享的状态。享元对象的外蕴状态必须由客户端保存，并在享元对象被建立以后，在须要使用的时候再传入到享元对象内部。

不变模式

享元模式中的对象不必定非要是不变对象，但大多数享元对象的确是这么设计的。

享元工厂
  1. 使用单例模式：通常只须要一个享元工厂，能够设计成单例的。
  2. 备忘录模式：享元工厂负责维护一个表，经过这个表把不少相同的实例与它们的一个对象联系起来。
优势

减小对象的建立，下降内存消耗

缺点
  1. 提升了系统的复杂度，为了使对象能够共享，须要将一些状态外部化
  2. 须要将一些状态外部化，而读取外部状态是的运行时间稍微变长
使用场景
  1. 一个系统中有大量对象。
  2. 这些对象消耗大量内存。
  3. 这些对象的状态大部分能够外部化。
  4. 这些对象能够按照内蕴状态分为不少组，当把外蕴对象从对象中剔除出来时，每一组对象均可以用一个对象来代替。
  5. 系统不依赖于这些对象身份，换言之，这些对象是不可分辨的。
Java应用
  1. String对象，有则返回，没有则建立一个字符串并保存
  2. 数据库的链接池

3.6.4 案例

依旧是熟悉的KFC点餐为例：

  • 外蕴状态：点餐的顾客
  • 内蕴状态：顾客点的食物
  • 具体享元角色：维护内蕴状态（客人要点的食物）。
public class KFC {
    public static void main(String[] args) {
        OrderFactory orderFactory = OrderFactory.getInstance();
        Order order = orderFactory.getOrder(Food.MiniBurger);
        order.operation("李雷");
        order = orderFactory.getOrder(Food.MiniBurger);
        order.operation("韩梅梅");
    }
}

enum Food {
    MiniBurger,
    MexicanTwister,
    CornSalad,
    HotWing,
    PepsiCola
}

// Flyweight角色
interface Order {
    // 传入的是外蕴对象：顾客
    void operation(String customer);
}

// ConcreteFlyweight角色
class FoodOrder implements Order {
    // 内蕴状态
    private Food food;
    // 构造方法，传入享元对象的内部状态的数据
    public FoodOrder(Food food) {
        this.food = food;
    }

    @Override
    public void operation(String customer) {
        System.out.println("顾客[" + customer + "]点的是" + food.toString());
    }
}

// FlyweightFactory角色
class OrderFactory {
    private Map<Food, Order> orderPool = new HashMap<>();
    private static OrderFactory instance = new OrderFactory();

    private OrderFactory() {}

    public static OrderFactory getInstance() {
        return instance;
    }

    // 获取Food对应的享元对象
    public Order getOrder(Food food) {
        Order order = orderPool.get(food);
        if (null == order) {
            order = new FoodOrder(food);
            orderPool.put(food, order);
        }
        return order;
    }
}

3.7 门面模式

门面模式（Facade Pattern）要求一个子系统的外部与其内部通讯，必须经过一个统一的门面对象进行。

3.7.1 门面模式结构

门面模式没有一个通常化的类图描述，能够用下面的例子来讲明。
门面模式

  • 门面（Facade）角色：外部能够调用这个角色的方法。此角色知道子系统的功能和责任。
  • 子系统（Subsystem）角色：能够有多个子系统，子系统不须要知道门面的存在。

3.7.2 细节

门面数量

一般只须要一个门面类，并且只有一个实例，所以能够设计称单例模式。固然也可有多个类。

使用场景
  1. 为一个复杂的子系统提供一个简单的接口
  2. 使子系统和外部分离开来
  3. 构建一个层次化系统时，可使使用Facade模式定义系统中每一层，实现分层。
优势
  1. 减小系统之间的相互依赖。
  2. 提升了安全性。
缺点
  1. 不符合开闭原则
  2. 若是要改东西很麻烦，继承重写都不合适。
Java例子

MVC三层结构

3.7.3 KFC例子

假如没有服务员（门面），顾客（外部系统）要点一个套餐须要知道每一个套餐包含的食物（子系统）种类，这样就会很是麻烦，因此最好的方式是直接告诉服务员套餐名称就行了。

public class Customer {
    public static void main(String[] args) {
        Waiter waiter = new Waiter();
        List<Food> foodList = waiter.orderCombo("Combo1");
    }
}

abstract class Food {}
class MiniBurger extends Food {}
class MexicanTwister extends Food {}
class CornSalad extends Food {}
class HotWing extends Food {}
class PepsiCola extends Food {}

class Waiter {
    public List<Food> orderCombo(String comboName) {
        List<Food> foodList;
        switch (comboName) {
            case "Combo1" : 
                foodList = Arrays.asList(new MiniBurger(), new CornSalad(), new PepsiCola()); 
                break;
            case "Combo2":
                foodList = Arrays.asList(new MexicanTwister(), new HotWing(), new PepsiCola());
                break;
            default:
                foodList = new ArrayList<>();
        }
        return foodList;
    }
}

3.8 过滤器模式

过滤器模式使用不一样的条件过滤一组对象，并经过逻辑操做以解耦方式将其连接。这种类型的设计模式属于结构模式，由于该模式组合多个标准以得到单个标准。

3.8.1 细节

步骤
  1. 建立一个要过滤的普通类，要有得到其私有属性的get方法
  2. 建立一个接口，规定过滤方法
  3. 实现接口，能够依须要重写过滤方法，参数传递的通常是存储过滤类的容器类
  4. 复杂过滤类能够经过设置传递接口参数（复用其余基础过滤类）来实现多重过滤
Java8

Java8中的lambda表达式能够更简单的实现过滤器

List<Movie> movies = Stream.of(
                new Movie("大话西游","comedy"),
                new Movie("泰囧", "comedy"),
                new Movie("禁闭岛", "suspense"))
                .filter(var -> "comedy".equals(var.getType()))
                .collect(Collectors.toList());

3.8.2 电影的例子

  1. 建立被过滤的类Movie，根据它的type属性实现过滤
  2. 建立接口Criteria，规定过滤方法
  3. 建立喜剧电影过滤器ComedyMovieCriteria，根据comedy==movie.type来过滤出须要的喜剧电影
public class Test {
    public static void main(String[] args) {
        List<Movie> movies = new ArrayList(){{
            add(new Movie("大话西游","comedy"));
            add(new Movie("泰囧", "comedy"));
            add(new Movie("禁闭岛", "suspense"));
        }};
        System.out.println(new ComedyMovieCriteria().meetCriteria(movies));
    }
}

// 被筛选的对象
class Movie {
    private String name;
    // 电影类型
    private String type;

    public Movie(String name, String type) {
        this.name = name;
        this.type = type;
    }
    // getters & setters & toString
}

// 过滤器接口
interface Criteria {
    /**
     * @param movies 要被筛选的电影
     * @return 筛选后的结果
     */
    List<Movie> meetCriteria(List<Movie> movies);
}

// 过滤喜剧电影的过滤器，要求是movie.type==comedy
class ComedyMovieCriteria implements Criteria {
    @Override
    public List<Movie> meetCriteria(List<Movie> movies) {
        List<Movie> result = new ArrayList<>();
        for (Movie movie : movies) {
            if ("comedy".equals(movie.getType())) {
                result.add(movie);
            }
        }
        return result;
    }
}

3.9 桥接模式

桥接模式是将抽象化与实现化解耦，使二者能够独立地变化。桥接模式有助于理解面向对象的设计原则，包括开闭原则以及组合聚合复用原则。

3.9.1 桥接模式结构

桥接模式

这个系统含有两个等级结构
  • 由抽象化角色和修正抽象化角色组成的抽象化等级结构。
  • 由实现化角色和两个具体实现化角色所组成的实现化等级结构。
桥接模式所涉及的角色
  • 抽象化（Abstraction）角色：抽象化给出的定义，并保存一个对实现化对象的引用。
  • 修正抽象化（Refined Abstraction）角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
  • 实现化（Implementor）角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不必定和抽象化角色的接口定义相同，实际上，这两个接口能够很是不同。实现化角色应该只给出底层操做，而抽象化角色应该只给出基于底层操做的更高一层的操做。
  • 具体实现化（Concrete Implementor）角色：这个角色给出实现化角色接口的具体实现。

3.9.2 细节

抽象化、实现化、解耦

抽象化：存在于多个实体中的共同的概念性联系；经过忽略一些信息，把不一样的实体看成相同的实体来对待。
实现化：抽象化给出的具体实现就是实现化。一个类的实例就是这个类的实现化，一个子类就是它超类的实现化。
解耦：耦合就是两个实体的某种强关联，把它们的强关联去掉就是解耦。
强关联与弱关联：所谓强关联，就是在编译期已经肯定的，没法在运行期动态改变的关联；所谓弱关联，就是能够动态地肯定而且能够在运行期动态地改变的关联。继承是强关联，而聚合关系是弱关联。

核心理解

桥接模式中的脱耦，就是在抽象化和实现化之间使用组合关系而不是继承关系，从而使二者能够相对独立的变化。

优势
  1. 实现抽象化和实现化的分离。
  2. 提升了代码的扩展能力。
  3. 实现细节对客户透明。
缺点
  1. 桥接模式的引入会增长系统的理解与设计难度
  2. 因为聚合关联关系创建在抽象层，要求开发者针对抽象进行设计与编程。
使用场景
  1. 若是一个系统须要在构件的抽象化角色和具体化角色之间增长更多的灵活性，避免在两个层次之间创建静态的继承联系，经过桥接模式可使它们在抽象层创建一个关联关系。
  2. 抽象化角色和实现化角色能够以继承的方式独立扩展而互不影响，在程序运行时能够动态将一个抽象化子类的对象和一个实现化子类的对象进行组合，即系统须要对抽象化角色和实现化角色进行动态耦合。
  3. 一个类存在两个独立变化的维度，且这两个维度都须要进行扩展。
  4. 虽然在系统中使用继承是没有问题的，可是因为抽象化角色和具体化角色须要独立变化，设计要求须要独立管理这二者。
  5. 对于那些不但愿使用继承或由于多层次继承致使系统类的个数急剧增长的系统，桥接模式尤其适用
Java例子

大多数的驱动器（Driver）都是桥接模式的应用，使用驱动程序的应用系统就是抽象化角色，而驱动器自己扮演实现化角色。
JDBC驱动器

3.9.3 发送消息的案例

  • 下面案例中，SendMsg及其子类是按照发送消息的方式进行扩展的；而Send是按照发送消息的时间进行扩展的，二者互不影响。
  • Send持有类一个SendMsg对象，并可使用此对象的方法。
// Implementor角色
interface SendMsg {
    void sendMsg();
}

// Concrete Implementor角色
class EmailSendMsg implements SendMsg {
    @Override
    public void sendMsg() {
        System.out.println("Send Msg By Email");
    }
}

// Concrete Implementor角色
class WeChatSendMsg implements SendMsg {
    @Override
    public void sendMsg() {
        System.out.println("Send Msg By WeChat");
    }
}

// Abstraction 角色
abstract class Send {
    protected SendMsg sendMsg;

    public Send(SendMsg sendMsg) {
        this.sendMsg = sendMsg;
    }

    public abstract void send();
}

// Concrete Implementor角色
class ImmediatelySend extends Send {
    public ImmediatelySend(SendMsg sendMsg) {
        super(sendMsg);
    }

    @Override
    public void send() {
        sendMsg.sendMsg();
        System.out.println("Send Msg Immediately");
    }
}

// Concrete Implementor角色
class DelayedlySend extends Send {
    public DelayedlySend(SendMsg sendMsg) {
        super(sendMsg);
    }

    @Override
    public void send() {
        sendMsg.sendMsg();
        System.out.println("Send Msg DelayedlySend");
    }
}
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程