桥梁模式的用以是将问题的抽象和现实分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题，比如我们有一个画图程序有2个图形（Circle Rectangle）和2种画图方法（Drawing1 Drawing2）图形可能会使用Dawing1来画图，也可能使用Dawing2来画图，在这个画图程序中有两个可变因素，一是图形的种类有可能会增加新的图形，另一个是画图方法有可能会有Drawing3出现，当系统有两个可变因素是我们就应该考虑到桥梁模式，至少他应该在你脑海里闪过。
在面型对象设计中有两条重要原则：
1.找出变化并封装之
2.优先使用聚合而并不是继承
这两条将在桥梁模式中得到完美体现，在上例中图形是一个变化我们可以抽象出一个形状借口和一些形状类。
Java代码：
interface Shope{
void doDraw();
}
class Circle implements Shape{};
class Rectangle implements Shape{}
画图方法也可以抽象出一个Drawing借口和各种方法
Java代码：
interface Drawing{
void draw();
}
class Drawing1 implements Drawing{}
class Drawing2 implements Drawing{}
最后将两个变化联系起来
在问题域中是图形使用画图方法，所以应该在Shape中使用Drawing，我们可以通过在具体的图形中通过构造函数传入具体的画图方法来实现如下
Java代码：
class Circle implements Shape{
private Drawing drawing;
private Circle(Drawing drawing){
this.drawing = drawing;
}
public void doDraw(){
drawing.draw();
}
class Client(){
public static void main(String[] args){
Shape cirde = new Circle(new Drawing2());
circle.draw();
}
}
仔细体会了一下桥梁模式，感觉凡是“调用和实现”之间的问题都可以用桥梁模式解决，比如说Dao层给Service层之间的调用，Service作为调用方dao为实现方只不过Service层只有一种实现罢了，可以看作是一种简化了的桥梁模型，dao可能有 HibernateDao 、JdbcDao
Java代码如下：
interface Dap{
List findAll();
}
class HibernateUserDao implements Dao{}
class JdbcUserDao implements Dao{}
interface UserService{
List findAllUser();
}
class UserServiceImpl implements UserService(Dao dao){
private Dao dao;
public UserService Impl(Dao dao){
this.dao = dao;
}
public List findAllUser(){
dao.findAll();
}
这个代码是不是给上面的画图程序很类似呢，不同指出就是Service层只有一个实现UserServiceImpl，所以说是这是一种简化的桥梁