桥梁模式

桥梁模式的用意是将问题的抽象和实现分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题。
比如我们有一个画图程序 有2个图形（Circle Rectangle ）和2种画图方法（Drawing1 Drawing2）
图形可能会使用Drawing1来画图 也可能使用Drawing2来画图
在这个画图程序中有两个可变因素 一个是图形的种类 有可能会增加新的图形 另一个是画图方法 可能会有Drawing3出现
当系统有两个可变因素时 我就应该考虑到桥梁模式，至少它应该在你的脑子里闪过
在面向对象设计中有两条重要原则
1.找出变化并封装之
2.优先使用聚合而不是继承

这两条将在桥梁模式中得到完美体现

在上例中图形是一个变化 我们可以抽象出一个形状接口 和 一些形状类

interface Shape{
    void doDraw();
}
class Circle implements Shape{}
class Rectangle implements Shape{}

画图方法也可以抽象出一个Drawing接口 和 各种画法

interface Drawing{
    void draw();
}
class Drawing1 implements Drawing{}
class Drawing2 implements Drawing{}

最后将两个变化联系起来
在问题域中是图形使用画图方法 所有应该在Shape中使用Drawing
我们可以通过在具体的图形类中通过构造函数传入具体的画图方法来实现
如下

class Circle implements Shape{
    private Drawing drawing; 
    public Circle(Drawing drawing){
        this.drawing = drawing;
    }

    public void doDrow(){
        drawing.draw();
    }
}

class Client(){
    public static void main(String[] args){
        Shape circle = new Circle(new Drawing2());
        circle.draw();
    }
}

仔细体会了一下桥梁模式，感觉凡是‘调用和实现’之间的问题都可以用桥梁模式解决
比如说Dao层给Service层之间的调用，service作为调用方 dao为实现方
只不过service层只有一种实现罢了，可以看作是一种简化了的桥梁模

dao 可能有 HibernateDao JdbcDao。
service 使用dao
如下

interface Dao{   
    List findAll();   
}   
class HibernateUserDao implements Dao{}   
class JdbcUserDao implements Dao{}   
  
interface UserService{   
    List findAllUser();   
}   
  
class UserServiceImpl implements UserService{   
    private Dao dao;   
    public UserServiceImpl(Dao dao){   
        this.dao = dao;   
    }   
  
    public List findAllUser(){   
        dao.findAll();   
    }   
} 

这个代码是不是给上面的画图程序很类似呢
不同之处就是service层只有一个实现UserServiceImpl
所以说是这是一种简化了的桥梁