设计模式之桥梁模式

前言:上一篇提到了关于并发编程的学习计划,计划赶不上变化,最近在熟悉新的业务,其实也学习到很多先进的供应链相关的东西,但是很多可能比较敏感不太方便放到博客上来,所以关于并发编程这块东西得过阵子才能更新,很久没更新设计模式相关的东西了,这次来谈谈我对桥梁模式的理解吧。


  • 模式描述:

桥梁模式是结构型设计模式,它解决的问题就是多维度多变化的类爆炸性问题,意思就是很多对象是多个维度去组合,我们不需要把这种组合的方式写成静态(继承的方式)的代码方式实现,而可以采用组合的方式去组合,当然还要结合抽象或则接口去交流,这样屏蔽具体的维度实现细节。总而言之,就是解决了多维度变化的问题。


  • UML图:
    这里写图片描述

  • 角色解释:

    Abstraction : 一个维度抽象角色,维护另一个维度的变化接口。
    Implementation : 一个维度的抽象接口。
    RefinedAbstaction1/2 : 一个具体的维度变化。
    RealImplementation1/2 : 另一个具体的维度变化。

  • 举个栗子:

汽车和颜色,可以看成是两个维度的变化,我们买汽车,如果不用桥梁模式:

/**
     * 汽车
     */
    interface Car {
        void run();
    }
    class SmallCar implements Car{
        public void run() {
            System.out.println("small car runnig");
        }
    }

    class BigCar implements Car{
        @Override
        public void run() {
            System.out.println("big car running");
        }
    }

    /**
     * 不同颜色的车
     */

    interface Color {
        String getColor();
    }
    class RedSmallCar extends SmallCar implements  Color {
        @Override
        public String getColor() {
            return "red";
        }

        @Override
        public void run() {
            System.out.println(getColor());
            super.run();
        }
    }

    class RedBigCar extends BigCar implements Color {
        @Override
        public String getColor() {
            return "red";
        }

        @Override
        public void run() {
            System.out.println(getColor());
            super.run();
        }
    }

    class YelloSmallCar extends SmallCar implements  Color {
        @Override
        public String getColor() {
            return "yellow";
        }

        @Override
        public void run() {
            System.out.println(getColor());
            super.run();
        }
    }

    class YelloBigCar extends BigCar implements Color {
        @Override
        public String getColor() {
            return "yellow";
        }

        @Override
        public void run() {
            System.out.println(getColor());
            super.run();
        }
    }

可以看到。我们要定义红色的小车,红色的大车,黄色小车,黄色大车,是2 * 2个类,如果要增加一个颜色呢,又要增加两个类,如果再增加一个品牌的维度呢,可想而知,整个类会爆炸性增长,非常难以维护。桥梁模式就是为了解决这种问题而产生,我们使用桥梁模式的解决方案如下:

/**
     * 汽车
     */
    abstract class Car {

        protected Color color;

        abstract void run();

        void Car(Color color) {
            this.color = color;
        }
    }

    class SmallCar extends Car {
        public void run() {
            System.out.println(color.getColor() + "small car runnig");
        }
    }

    class BigCar extends Car {
        @Override
        public void run() {
            System.out.println(color.getColor() + "big car running");
        }
    }

    /**
     * 不同颜色的车
     */

    interface Color {
        String getColor();
    }

    class Red implements Color {
        @Override
        public String getColor() {
            return "red";
        }
    }

    class Yellow implements Color {
        @Override
        public String getColor() {
            return "yellow";
        }
    }

这样只需要在使用的适合去装配这个对象即可,一些固定的搭配可通过创建者模式去组装,这样类的结构由n * n的几何增长,编程了n + n的增长,关键的就是采用了组合和抽象去屏蔽了维度细节,动态的组合对象,能够让每个维度单独的变化。


使用场景与优缺点:

适合多个维度变化的对象的维度解耦,缺点就是可能设计更加复杂,如果变化不剧烈继承未尝不是一个简单的方式,但是变化剧烈的话肯定桥梁模式更加符合面向对象设计原则。

猜你喜欢

转载自blog.csdn.net/micro_hz/article/details/78313445