桥模式和组合模式

抽象的业务应用抽象的业务实现

组合模式需要是树形结构而且关系比较深的情况。

java 设计模式 结构模式 桥梁模式(Bridge)  

阅

桥梁模式的用意是将问题的抽象和实现分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题。 
比如我们有一个画图程序 有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 
所以说是这是一种简化了的桥梁 
转自:http://www.iteye.com/topic/57178

《Design Patterns Explained》对Bridge模式的特征：
意图：将一组实现与另一组使用他们的对象分离
问题：一个抽象类 的派生类 必须使用多个实现 ，但出现类数量增长
1.未使用Bridge实例：
java 代码 
abstract   class  Shape{   
     public   void  draw();   
}   
  
class  Rectangle  extends  Shape{}   
  
class  Circle  extends  Shape{}   
  
//这里业务出现了多种画图方式，DP1,DP2……   
  
//使用继承，创建不同绘图的类，类数量增多   
  
class  V1Rectangle  extends  Rectangle{   
     public   void  draw(){   
        DP1.draw_line();   
    }   
}   
  
class  V2Rectangle  extends  Rectangle{   
     public   void  draw(){   
        DP2.draw_line();   
    }   
}   
  
class  V1Circle  extends  Circle{   
     public   void  draw(){   
        DP1.draw_Circle();   
    }   
}   
  
class  V2Circle  extends  Circle{   
     public   void  draw(){   
        DP2.draw_Circle();   
    }   
}   
  
2.传说中的Bridge模式
java 代码 
abstract   class  Shape{   
     public   void  draw();   
}   
  
//这里业务出现了多种画图方式，DP1,DP2……   
//抽象出接口出DP1,DP2   
interface  Drawing{   
     public   void  drawLine();   
     public   void  drawCircle();   
}   
  
class  V1Drawing{   
     public   void  drawLine(){};   
     public   void  drawCircle(){};   
}   
  
class  V2Drawing{   
     public   void  drawLine(){};   
     public   void  drawCircle(){};   
}   
  
//使用组合 ，聚集Drawing   
class  Rectangle  extends  Shape{   
     public   void  draw(Drawing dp){   
        dp.drawLine();   
    }   
}   
  
class  Circle  extends  Shape{   
     public   void  draw(Drawing dp){   
        dp.drawCircle();   
    }   
}
//抽象类Shape的派生类，使用一组实现(DP1,DP2)的接口
//使得派生类不依赖于一组具体的实现，从设计模式而言，这称为Bridge模式 
3.Bridge与Strategy模式
初读Bridge模式一头雾水，看过实例代码后，才略为知道其用途。感觉与Strategy模式相似，查阅相关信息后，个人认为如下   
从考虑问题而言：   
Strategy模式：将具体算法封装，便于使用类替换算法   
Bridge模式：将一组抽象类的派生类使用的另一组实现进行抽象，使得派生类不依赖于具体实现
  
从实现而言，两者十分相似：   
Strategy和Bridge目的都是将实现抽象化，使用组合，而非直接继承。   
区别就在Strategy思考的是抽象具体算法，Bridge是一组派生类在使用，抽象另外一组服务。  
实际处理的问题不同，故分为两种不同模式 
转自:http://www.iteye.com/topic/137469

从桥接模式与策略模式谈起

桥接(Bridge)模式是结构型模式的一种，而策略(strategy)模式则属于行为模式。以下是它们的UML结构图。

在桥接模式中，Abstraction通过聚合的方式引用Implementor。 

在策略模式中，Context也使用聚合的方式引用Startegy抽象接口。

从他们的结构图可知，在这两种模式中，都存在一个对象使用聚合的方式引用另一个对象的抽象接口的情况，而且该抽象接口的实现可以有多种并且可以替换。可以说两者在表象上都是调用者与被调用者之间的解耦，以及抽象接口与实现的分离。

那么两者的区别体现在什么地方呢？

1. 首先，在形式上，两者还是有一定区别的，对比两幅结构图，我们可以发现，在桥接模式中不仅Implementor具有变化 （ConcreateImplementior），而且Abstraction也可以发生变化（RefinedAbstraction），而且两者的变化 是完全独立的，RefinedAbstraction与ConcreateImplementior之间松散耦合，它们仅仅通过Abstraction与 Implementor之间的关系联系起来。而在策略模式中，并不考虑Context的变化，只有算法的可替代性。

2. 其次在语意上，桥接模式强调Implementor接口仅提供基本操作，而Abstraction则基于这些基本操作定义更高层次的操作。而策略模式强调 Strategy抽象接口的提供的是一种算法，一般是无状态、无数据的，而Context则简单调用这些算法完成其操作。

3. 桥接模式 中不仅定义Implementor的接口而且定义Abstraction的接口，Abstraction的接口不仅仅是为了与Implementor通信 而存在的，这也反映了结构型模式的特点：通过继承、聚合的方式组合类和对象以形成更大的结构。在策略模式中，Startegy和Context的接口都是 两者之间的协作接口，并不涉及到其它的功能接口，所以它是行为模式的一种。行为模式的主要特点就是处理的是对象之间的通信方式，往往是通过引入中介者对象 将通信双方解耦，在这里实际上就是将Context与实际的算法提供者解耦。

所以相对策略模式，桥接模式要表达的内容要更多，结构也更加 复杂。桥接模式表达的主要意义其实是接口隔离的原则，即把本质上并不内聚的两种体系区别开来，使得它们可以松散的组合，而策略在解耦上还仅仅是某一个算法 的层次，没有到体系这一层次。从结构图中可以看到，策略的结构是包容在桥接结构中的，桥接中必然存在着策略模式，Abstraction与 Implementor之间就可以认为是策略模式，但是桥接模式一般Implementor将提供一系列的成体系的操作，而且Implementor是具 有状态和数据的静态结构。而且桥接模式Abstraction也可以独立变化。