读设计模式之禅--桥梁模式

• 定义：将抽象和实现解耦，使得两者可以独立地变化

桥梁模式是一个非常简单的模式，它只是使用了类间的聚合关系、继承、覆写等常用功能，但是它却提供了一个非常清晰、稳定的架构
桥梁模式是为了解决类继承的缺点而设计的。一个类想拥有另一个类的方法，可以不继承，只需要铺设一个桥梁（引用）架过去就OK了。

package design.bridge;

/**
 * @Author: hyh
 * @Date: 2021/8/30 14:21
 * 抽象一个共享单车
 **/
public interface ShareBicycle {

    void color();
}

// 摩拜单车
class Mobie implements ShareBicycle {

    @Override
    public void color() {
        System.out.println("蓝色的摩拜");
    }
}

// ofo 小黄车
class Ofo implements ShareBicycle {

    @Override
    public void color() {
        System.out.println("黄色的ofo");
    }
}

// 使用者  将共享单车以属性的方式组合到用户 这就是桥梁模式  用户可以扩展 学生 工人 教师类
// 单车也可以扩展 摩拜 ofo 美团单车 只需横向扩展即可 不用修改原来代码
abstract class User {

    private ShareBicycle shareBicycle;

    public User(ShareBicycle shareBicycle) {
        this.shareBicycle = shareBicycle;
    }

    public void use() {
        System.out.println("我骑的共享单车是");
        this.shareBicycle.color();
    }
}

// 学生
class Student extends User {

    public Student(ShareBicycle shareBicycle) {
        super(shareBicycle);
    }

    @Override
    public void use() {
        System.out.println("我是一名小学生");
        super.use();
    }
}

class Test {
    public static void main(String[] args) {

        // new 一辆小黄车
        Ofo ofo = new Ofo();
        // new 一个学生
        Student student = new Student(ofo);
        student.use();
    }
}
输出：
我是一名小学生
我骑的共享单车是
黄色的ofo

• 继承，公共的方法或属性抽取，父类封装共性，子类实现特性，这是继承的基本功能。缺点有没有？有！即强侵入，父类有一个方法，子类也必须有这个方法。这是不可选择的，会带来扩展性的问题。我举个简单的例子来说明：Father类有一个方法A，Son继承了这个方法，然后GrandSon也继承了这个方法，问题是突然有一天Son要重写父类的这个方法，他敢做吗？绝对不敢！GrandSon要用从Father继承过来的方法A，如果你修改了，那就要修改Son和GrandSon之间的关系，那这个风险就太大了！
• 桥梁模式就是这一问题的解决方法，桥梁模式描述了类间弱关联关系，还说上面的那个例子，Father类完全可以把可能会变化的方法放出去，Son子类要拥有这个方法很简单，桥梁搭过去，获得这个方法，GrandSon也一样，即使你Son子类不想使用这个方法也没关系，对GrandSon不产生影响，它不是从Son中继承来的方法！