设计模式---桥接模式案例分析.

桥接模式属于结构型设计模式。

设计意图：将抽象部分与实现部分分离，使它们都可以独立的变化。

一看到设计意图，大家可能有些发懵，我们看到的继承和接口不都是抽象和实现分离的吗？尤其是接口和抽象类都是这样的实现啊！那怎么还有这么个桥接的分离呢？

举一个例子:
比如有男人,女人他们都要上网做事情,男人上网玩游戏,女人上网也玩游戏,如何实现呢?
我们先不用桥接模式来实现一下:

首先我们先不用桥接模式看看如何实现
首先准备:

//这是上网打游戏
	public class PlayGame {
	    void call(){
	        System.out.println("上网打游戏");
	    }
	}
    

男人上网打游戏.

public class ManPlay extends PlayGame{
    void call(){
        System.out.println("男人");
        super.call();
    }
}

女人上网打游戏.

public class WomanPlay extends PlayGame{
    void call(){
        System.out.println("女人");
        super.call();
    }
}

测试实现.

public static void main(String[] args) {

        ManPlay manPlay = new ManPlay();
        manPlay.call();

        WomanPlay womanPlay = new WomanPlay();
        womanPlay.call();
    }

男人 上网打游戏 女人 上网打游戏

现在需求变化了,需要让他们上网进行学习.

上网学习的类.

public class Learning {
    void call(){
        System.out.println("上网学习");
    }
}

男人上网学习.

public class Man extends Learning{
    void call(){
        System.out.println("男人");
        super.call();
    }
}

女人上网学习.

public class Woman extends Learning{
    void call(){
        System.out.println("女人");
        super.call();
    }
}

测试

public static void main(String[] args) {
        Man man = new Man();
        man.call();

        Woman woman = new Woman();
        woman.call();
    }

男人 上网学习 女人 上网学习

从上面可以看到如果不用桥接模式的情况,我们需要在变化的时候添加多个类,然后进行实现.代码的重用性和扩展性不好.

接下来我们使用桥接模式,对比一下看看:

首先准备接口,

public interface People {
    void PeopleType();
}

男人来实现这个接口:

public class Man implements People{
    @Override
    public void PeopleType() {
        System.out.println("男人");
    }
}

女人来实现这个接口:

public class Woman implements People{
    @Override
    public void PeopleType() {
        System.out.println("女人");
    }
}

桥接类:

public abstract class BridgePeople {

    private People people;

    public BridgePeople(People people) {
        this.people = people;
    }

    protected void OnNet(){
        people.PeopleType();
    }
}

打游戏的类继承桥接类.

public class PlayGame extends BridgePeople{

    public PlayGame(People people) {
        super(people);
    }

    public void OnNet(){
        super.OnNet();
        System.out.println("上网打游戏");
    }
}

测试

public static void main(String[] args) {
        BridgePeople playGame1 = new PlayGame(new Man());
        playGame1.OnNet();
        BridgePeople playGame = new PlayGame(new Woman());
        playGame.OnNet();
}

输出结果:

男人 上网打游戏 女人 上网打游戏

现在需求变化了,需要让他们上网进行学习.桥接模式的好处.

我们只需要添加一个类,让这个类继承桥接类,就可以直接使用了.

public class Learning extends BridgePeople{
    public Learning(People people) {
        super(people);
    }

    public void OnNet(){
        super.OnNet();
        System.out.println("上网学习");
    }
}

测试

public static void main(String[] args) {
    BridgePeople learning = new Learning(new Man());
    learning.OnNet();
    BridgePeople learning1 = new Learning(new Woman());
    learning1.OnNet();
}

输出结果:

男人 上网学习 女人 上网学习

思考如果不使用桥接模式需要添加一个老人,让这个老人上网玩游戏,上网学习应该如何做?
如果使用桥接模式,让一个老人上网玩游戏,上网学习应该如何做呢?

通过对比我们可以看出桥接模式是非常方便的,效果及实现要点：
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同路上的不同汽车。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。

适用性：
在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

总结：
Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。

供自己参考学习.