桥梁模式的理解
最近在Java编程过程中，考虑到这么个问题：
根据面向对象的继承关系，子类继承父亲的方法。目前有这么个场景：类A是个抽象类，其中有n个方法，类B是类A的子类，类C是类B的子类。假若A中有一个方法operate()，那么B、C均未对operate()方法进行重写，直接继承了A的operate方法实现操作。随着项目的壮大，一定有很多的地方使用到B、C两个类。假若某一天，突然有个需求：需要B对operate（）函数进行重写。那么我们敢直接拿B进行开刀吗？答案稳定是否定的！试想下，要是对B进行开刀，那么C咋办？C继承的是B，如果B的方法改变，子类C也将随之进行更改，这样的结果将不符合需求。先用代码对上面的场景进行模拟下吧。
类Father：
/**
* @author lw
* 父亲类方法有a 、b 、c三种方法，其中c是抽象方法。
*/
public abstract class Father {
public void a(){
System.out.println("Father a函数！");
};
public void b(){};
public abstract void c();
}
类Son1：
/**
* @author lw
* 儿子继承父亲，重写父亲的抽象方法c
*/
public class Son1 extends Father {
@Override
public void c() {
System.out.println("Son1 C函数重写！");
}
}
类GrandSon1：
/**
* @author lw
* 孙子继承儿子的方法
*/
public class GrandSon1 extends Son1 {
}
那么我们应该怎么解决该问题了。前提是只需要更改B中的a方法，而不能修改C中的a方法。这时就可以使用桥梁模式了。具体思路就是把A中需要变换的方法给抽出来组装为一个类（接口），然后用D类对接口中的方法进行实现。因此B对a方法的修改，只需要调用D中的a方法实现。也就是说哪个方法需要实现，哪个类需要重写该方法，就把桥搭接过去。
类Father：
/**
* @author lw
* 父亲类方法有a 、b 、c三种方法，其中c是抽象方法。
*/
public abstract class Father {
public void a(Bridge r){
System.out.println("Father a函数！");
};
public void b(){};
public abstract void c();
}
类Son1：
/**
* @author lw
* 儿子继承父亲，重写父亲的抽象方法c
*/
public class Son1 extends Father {
@Override
public void c() {
System.out.println("Son1 C函数重写！");
}
@Override
public void a(Bridge b) {
if(b==null)
super.a(b);
else
b.a();
}
}
接口Bridge：
public interface Bridge {
public void a() ;
}
类BridgeImpl：
public class BridgeImpl implements Bridge{
@Override
public void a() {
System.out.println("桥梁模式搭建出来的a方法！");
}
}
实现类：
new GrandSon1().a(new BridgeImpl());
new GrandSon1().a(null);
因此这样实现之后，Son对a方法进行了重写，同时GrandSon1能够继承Father的a方法。本来通过继承，实现了强关联，是一种强耦合关系。桥梁模式的作用就是实现类间的低耦合。
那么什么叫桥梁模式了，桥梁模式到底做什么用了？我们用上面的例子进行模拟说明。设想Father，Son，GrandSon1是业务抽象角色，他们很好地通过继承实现了强关联。设想Bridge，BridgeImpl是业务实现角色，它是对Father中抽取出来的方法a的实现。也就说业务抽象角色的部分实现是由业务实现角色实现。通过抽象角色和实现角色的分离，从而实现类间解耦。因此桥梁模式的作用就是实现类间解耦，这也是它的优点。两种角色可以自己进行扩展，但互相之间不影响，这也符合ocp原则（开放封闭原则）。
目前网上对桥梁模式的实现有很多实例，这里就没神马必要去进行模拟实现了。但是JDBC的实现，还是很有必要进行研究的……