原文：http://www.runoob.com/design-pattern/
少许个人理解，如有错误请指出。欢迎一起讨论。
同之前的原型模式，这一节菜鸟教程也比较抽象，仍然找一篇好懂的博客文章补充。
原文：
http://www.cnblogs.com/houleixx/archive/2008/02/23/1078877.html
桥接模式
桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。
这种模式涉及到一个作为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。
意图：
将抽象部分与实现部分分离，使它们都可以独立的变化。
主要解决：
在有多种可能会变化的情况下，用继承会造成类爆炸问题（类爆炸指由于开始的设计不合理，每次增加新的功能，系统类的数量急剧上升），扩展起来不灵活。
何时使用：
实现系统可能有多个角度分类，每一种角度都可能变化。
如何解决：
把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。
关键代码：
抽象类依赖实现类。
优点：
1、抽象和实现的分离。
2、优秀的扩展能力。
3、实现细节对客户透明。（透明是指用户不需要了解是如何实现具体功能的，只知道他有这个功能）
缺点：
桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。
使用场景：
1、如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。
2、对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。
3、一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。
注意事项：
对于两个独立变化的维度，使用桥接模式再适合不过了。
————-以下是侯垒大佬的博客摘抄
生活中的一个例子:
就拿汽车在路上行驶的来说。即有小汽车又有公共汽车，它们都不但能在市区中的公路上行驶，也能在高速公路上行驶。这你会发现，对于交通工具（汽车）有不同的类型，然而它们所行驶的环境（路）也在变化，在软件系统中就要适应两个方面的变化？怎样实现才能应对这种变化呢？
概述:
在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
意图:
将抽象部分与实现部分分离，使它们都可以独立的变化。
——《设计模式》GOF
结构图:
传统的做法:
通过类继承的方式来做上面的例子;
先看一下类结构图:
代码实现:
class Road {
void run() {
System.out.println("路");
}
} //市区街道
class Street extends Road {
void run() {
System.out.println("市区街道");
}
} //高速公路
class SpeedWay extends Road {
void run() {
System.out.println("高速公路");
}
} //小汽车在市区街道行驶
class CarOnStreet extends Street {
void run() {
System.out.println("小汽车在市区街道行驶");
}
} //小汽车在高速公路行驶
class CarOnSpeedWay extends SpeedWay {
void run() {
System.out.println("小汽车在高速公路行驶");
}
} //公交车在市区街道行驶
class BusOnStreet extends Street {
void run() {
System.out.println("公交车在市区街道行驶");
}
} //公交车在高速公路行驶
class BusOnSpeedWay extends SpeedWay {
void run() {
System.out.println("公交车在高速公路行驶");
}
} //测试
public static void main(String[] args) {
//小汽车在高速公路行驶
CarOnSpeedWay carOnSpeedWay = new CarOnSpeedWay();
carOnSpeedWay.run();
//公交车在市区街道行驶
BusOnStreet busOnStreet = new BusOnStreet();
busOnStreet.run();
} 缺点:
但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起变化的原因却有两个，即路类型的变化和汽车类型的变化；其次是重复代码会很多，不同的汽车在不同的路上行驶也会有一部分的代码是相同的；再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化，我们会看到这个类的结构会迅速的变庞大。
应用设计模式 桥接模式（Bridge）来做;
先看一下类结构图:
代码实现:
abstract class AbstractRoad{
AbstractCar aCar;
void run(){};
} abstract class AbstractCar{
void run(){};
} class Street extends AbstractRoad{
@Override
void run() {
// TODO Auto-generated method stub
super.run();
aCar.run();
System.out.println("在市区街道行驶");
}
} class SpeedWay extends AbstractRoad{
@Override
void run() {
// TODO Auto-generated method stub
super.run();
aCar.run();
System.out.println("在高速公路行驶");
}
} class Car extends AbstractCar{
@Override
void run() {
// TODO Auto-generated method stub
super.run();
System.out.print("小汽车");
}
} class Bus extends AbstractCar{
@Override
void run() {
// TODO Auto-generated method stub
super.run();
System.out.print("公交车");
}
} 测试
public static void main(String[] args){
AbstractRoad speedWay = new SpeedWay();
speedWay.aCar = new Car();
speedWay.run();
AbstractRoad street = new Street();
street.aCar = new Bus();
street.run();
} 总结：
可以看到，通过对象组合的方式，Bridge 模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。
这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。
应用设计模式:
桥接模式（Bridge）来做(多维度变化);
结合上面的例子,增加一个维度”人”,不同的人开着不同的汽车在不同的路上行驶(三个维度);
结合上面增加一个类”人”,并重新调用.
代码实现:
abstract class People {
AbstractRoad road;
void run() {}
} class Man extends People{
@Override
void run() {
// TODO Auto-generated method stub
super.run();
System.out.print("男人开着");
road.run();
}
} class Woman extends People{
@Override
void run() {
// TODO Auto-generated method stub
super.run();
System.out.print("女人开着");
road.run();
}
} public static void main(String[] args) {
AbstractRoad speedWay = new SpeedWay();
speedWay.aCar = new Car();
People man = new Man();
man.road = speedWay;
man.run();
} 效果及实现要点：
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同路上的不同汽车。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。
适用性：
在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
最终总结：
Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承（和实现？）这两个面向对象原则。
桥接模式与装饰的区别:（先抄下来，之后学到装饰模式再看下）
装饰模式:
这两个模式在一定程度上都是为了减少子类的数目，避免出现复杂的继承关系。但是它们解决的方法却各有不同，装饰模式把子类中比基类中多出来的部分放到单独的类里面，以适应新功能增加的需要，当我们把描述新功能的类封装到基类的对象里面时，就得到了所需要的子类对象，这些描述新功能的类通过组合可以实现很多的功能组合 .
桥接模式：
桥接模式则把原来的基类的实现化细节抽象出来，在构造到一个实现化的结构中，然后再把原来的基类改造成一个抽象化的等级结构，这样就可以实现系统在多个维度上的独立变化 。
————-end摘抄
有个疑问：
在增加一个维度的时候的写法如果写成以下写法是不是好一些？
public abstract class AbstractPeople {
public void drive() {
}
public AbstractCar aCar;
}
public class Men extends AbstractPeople{
@Override
public void drive() {
super.drive();
System.out.print("Men drive");
}
} public class Women extends AbstractPeople{
@Override
public void drive() {
super.drive();
System.out.print("Women drive");
}
} public abstract class AbstractRoad{
public AbstractCar aCar;
public AbstractPeople aPeople;
public void run(){};
} public class SpeedWay extends AbstractRoad{
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
aCar.run();
aPeople.drive();
System.out.println("在高速公路行驶");
}
} public class Street extends AbstractRoad{
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
aCar.run();
aPeople.drive();
System.out.println("在市区街道行驶");
}
} 测试类：
public class Client {
public static void main(String[] args) {
AbstractRoad speedWay = new SpeedWay();
speedWay.aCar = new Car();
speedWay.aPeople = new Women();
speedWay.run();
AbstractRoad street = new Street();
street.aCar = new Bus();
street.aPeople = new Men();
street.run();
}
}类的结构图
这样写似乎没啥不妥，论结构清晰度还是这个好一些，求哪位大虾指点一二。
完成后三维添加的代码：
https://github.com/caihuijian/pro_designpattern.git
444
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
