【再探】设计模式—桥接模式、组合模式及享元模式

 结构型设计模式描述了对象与类之间的关系。适配器模式及装饰器模式主要用于接口适配及功能增强，而桥接模式模式则是为了减少类的数量，组合模式让部分与容器能被客户端统一对待处理，享元模式则是用于节约系统内存，提高系统性能。

1 桥接模式

需求：一个类存在多个纬度，且每个纬度都需要独立进行扩展。例如，Coffee类，它有尺寸及口味两个纬度，这两个纬度有不同的扩展，比如有大杯、小杯，加糖及不加糖。 而且后续这两个纬度可能还会有新的扩展。

1.1 桥接模式介绍

将抽象部分与其实现部分分离，使得它们可以独立地变化。

图 桥接模式 UML

public class BridgePattern {

    public static void main(String[] args) {
        TasteImplementor[] tasteArray = {new SugarTasteImplementor(),new SugarTasteImplementor()};
        for (int i = 0; i < tasteArray.length; i++) {
            for (int j = 0; j < 2; j++) {
                CoffeeAbstraction coffee = i == 0 ? new BigCoffee(tasteArray[i]) : new SmallCoffee(tasteArray[i]);
                coffee.order();
            }
        }

    }

    private static abstract class CoffeeAbstraction {

        protected TasteImplementor tasteImplementor;

        public CoffeeAbstraction(TasteImplementor tasteImplementor) {
            this.tasteImplementor = tasteImplementor;
        }

        abstract String size();

        void order() {
            System.out.println(size() + tasteImplementor.taste() + "咖啡");
        }
    }

    private static class BigCoffee extends CoffeeAbstraction{

        public BigCoffee(TasteImplementor tasteImplementor) {
            super(tasteImplementor);
        }

        @Override
        String size() {
            return "大杯";
        }
    }

    private static class SmallCoffee extends CoffeeAbstraction {

        public SmallCoffee(TasteImplementor tasteImplementor) {
            super(tasteImplementor);
        }

        @Override
        String size() {
            return "小杯";
        }
    }

    private interface TasteImplementor {
        String taste();
    }

    private static class SugarTasteImplementor implements TasteImplementor{

        @Override
        public String taste() {
            return "加糖";
        }
    }

    private static class NoSugarTasteImplementor implements TasteImplementor{

        @Override
        public String taste() {
            return "不加糖";
        }
    }

}

桥接模式	侧重纬度变化，实现部分的接口不一定要和抽象部分接口保持一致。
装饰模式	侧重动态添加或撤销功能，要求装饰类与被装饰类都实现同一接口。

表 桥接模式与装饰模式对比

1.2 优缺点

优点：

1. 各个纬度可以独立扩展，将类的数量由m * n 变成 m + n。
2. 符合单一职责原则、开闭原则、里氏替换原则、依赖倒转原则、合成复用原则。

缺点：

1. 增加系统的理解和设计难度，要求开发者一开始就针对抽象层进行设计与编程。及需要正确识别出系统中两个独立变化的纬度。

2 组合模式

需求：1）系统中具有整体和部分的层次结构，需要通过一种方式忽略整体和部分的差异，客户端可以一致的使用它们。2）一个系统中能分离出叶子和容器对象，而且它们的类型不固定，将来可能需要增加新的类型。

2.1 组合模式描述

组合多个对象形成树形结构，以表示具有“整体-部分”关系的层次结构。对单个对象（叶子对象）和组合对象（容器对象）的使用具有一致性。有称为“部分-整体(Part-Whole)模式”。

图 组合模式 UML

public class CompositePattern {

    public static void main(String[] args) {
        FileComponent file1 = new ImageFile("图片1");
        FileComponent file2 = new ImageFile("图片2");
        FileComponent folder1 = new Folder("文件夹1");
        FileComponent folder2 = new Folder("文件夹2");

        folder1.add(file1);
        folder2.add(file2);
        folder2.add(folder1);

        System.out.println(folder2.findByName("图片1"));
        System.out.println(folder1.findByName("图片2"));
        System.out.println(folder2.findByName("文件夹1"));
        System.out.println(folder1.findByName("文件夹1"));
    }

    private static abstract class FileComponent {

        protected String name;

        public FileComponent(String name) {
            this.name = name;
        }

        public abstract FileComponent findByName(String fileName);

        public abstract void add(FileComponent file);

        public abstract void remove(FileComponent file);

        public abstract FileComponent getChild(int i);

    }

    private static class ImageFile extends FileComponent {

        public ImageFile(String name) {
            super(name);
        }

        @Override
        public FileComponent findByName(String fileName) {
            return name.equals(fileName) ? this : null;
        }

        @Override
        public void add(FileComponent file) {
            throw new RuntimeException("不支持该操作");
        }

        @Override
        public void remove(FileComponent file) {
            throw new RuntimeException("不支持该操作");
        }

        @Override
        public FileComponent getChild(int i) {
            throw new RuntimeException("不支持该操作");
        }
    }

    private static class Folder extends FileComponent {

        private final List<FileComponent> children = new ArrayList<>();

        public Folder(String name) {
            super(name);
        }

        @Override
        public FileComponent findByName(String fileName) {
            if (name.equals(fileName)) return this;
            for (FileComponent file : children) {
                FileComponent item = file.findByName(fileName);
                if (item != null) return item;
            }
            return null;
        }

        @Override
        public void add(FileComponent file) {
            children.add(file);
        }

        @Override
        public void remove(FileComponent file) {
            children.remove(file);
        }

        @Override
        public FileComponent getChild(int i) {
            return i >= children.size() ? null : children.get(i);
        }
    }

}

2.1.1 透明组合模式

抽象构件Component中声明了所有用于管理成员对象的方法，包括add()、remove()以及getChild()等方法。

优点：叶子和容器对象所提供的方法是一致的，客户端可以相同地对待所有对象。

缺点：不够安全，叶子和容器对象在本质上有区别，add、remove及getChild方法对于叶子对象来说没有意义。如果调用叶子对象的这些方法，在编译阶段不会报错，但在运行阶段可能出错。

2.1.2 安全组合模式

在抽象构件Component中没有声明任何用于管理成员对象的方法（add、remove及getChild等）。而在容器类Composite中声明并实现了这些方法。

优点：安全，对于叶子对象，不可能会被调用这些方法。

缺点：不够透明，客户端不能完全针对抽象编程，必须有区别地对待叶子和容器对象。

2.2 优缺点

优点：

1. 可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次。让客户端忽略了层次的差异，方便对整个层次结构进行控制。
2. 增加新的容器构件和叶子构件很方便，符合开闭原则。

缺点：

1. 很难对容器中的构件类型进行限制，比如希望某容器只能有某些特定类型的构件，这需要通过在运行时进行类型检查来实现。

3 享元模式

需求：1）系统中有大量相同或相似的对象。2）对象中大部份状态时非共享的，可以外部化。

3.1 享元模式介绍

使用共享技术来支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都可共享，状态变化很小。

通常使用单例模式来创建这些共享对象。

图 享元模式 UML

public class FlyweightPattern {

    public static void main(String[] args) {
        SoldierFactory.simulate(20,10);
    }

    private static class SoldierFactory {

        public static void simulate(int blueNum,int redNum) {
            int tempBlueNum = blueNum,tempRedNum = redNum;
            while (tempBlueNum > 0 && tempRedNum > 0) {
                Soldier blue = BlueSoldier.getInstance();
                blue.setId(blueNum - tempBlueNum);
                Soldier red = RedSoldier.getInstance();
                red.setId(redNum - tempRedNum);
                boolean confront = blue.confront(red);
                if (confront) {
                    tempRedNum--;
                } else {
                    tempBlueNum--;
                }
            }
            System.out.println("最终结果：" + (tempBlueNum > 0 ? BlueSoldier.getInstance().getType() : RedSoldier.getInstance().getType()) + "胜利");
        }

    }

    private static abstract class Soldier {

        private final Random random = new Random();

        protected int id;

        abstract String getType();

        void setId(int id) {
            this.id = id;
        }

        boolean confront(Soldier opponent) {
            boolean result = random.nextInt() % 3 == 0;
            StringBuilder sb = new StringBuilder();
            sb.append(this);
            if (result) {
                sb.append("消灭").append(opponent);
            } else {
                sb.append("阵亡");
            }
            System.out.println(sb);
            return result;
        }

        @Override
        public String toString() {
            return getType() + id;
        }
    }

    private static class BlueSoldier extends Soldier {

        private BlueSoldier() {
        }

        public static Soldier getInstance() {
            return Holder.instance;
        }

        private static class Holder {
            private static final Soldier instance = new BlueSoldier();
        }

        @Override
        String getType() {
            return "蓝军";
        }
    }

    private static class RedSoldier extends Soldier {

        private RedSoldier() {
        }

        public static Soldier getInstance() {
            return Holder.instance;
        }

        private static class Holder {
            private static final Soldier instance = new RedSoldier();
        }

        @Override
        String getType() {
            return "红军";
        }
    }

}

单纯享元模式	所有的具体享元对象类都是可共享的，不存在不可共享的类。
复合享元模式	将一些单纯享元对象使用组合模式加以组合，形成复合享元对象。 这样可以确保这些享元对象具有相同的外部状态。

表 单纯享元模式与复合享元模式

3.2 优缺点

优点：

1. 极大减少了内存的使用，提高了系统性能。

缺点：

1. 需要分离内部和外部状态，使系统变得复杂。
2. 读取外部状态将使得运行时间变长。