设计模式笔记--桥梁模式

常用设计模式有23中，分为：

创建型模式（主要用于创建对象）

1、单例模式    2、工厂方法模式    3、抽象工厂模式    4、建造者模式     5、原型模式 
行为型模式 （主要用于描述对象或类是怎样交互和怎样分配职责）

1、模板方法模式  2、中介者模式  3、命令模式    4、责任链模式   5、策略模式   6、迭代器模式  

7、观察者模式      8、备忘录模式   9、访问者模式   10、状态模式   11、解释器模式

结构型模式(主要用于处理类或对象的组合)

1、代理模式  2、装饰模式   3、适配器模式   4、组合模式 5、外观模式（门面模式）   6、享元模式    7、桥梁模式

桥梁模式 

桥梁模式（Bridge Pattern）也叫做桥接模式，是一个比较简单的模式，其定义如下：

将抽象和实现解耦，使得两者可以独立地变化。

桥梁模式的重点是在“解耦”上  

我们先来看桥梁模式中的4个角色。

● Abstraction——抽象化角色

它的主要职责是定义出该角色的行为，同时保存一个对实现化角色的引用，该角色一般是抽象类。

● Implementor——实现化角色

它是接口或者抽象类，定义角色必需的行为和属性。

● RefinedAbstraction——修正抽象化角色

它引用实现化角色对抽象化角色进行修正。

● ConcreteImplementor——具体实现化角色

它实现接口或抽象类定义的方法和属性。  

抽象角色引用实现角色，或者说抽象角色的部分实现是由实现角色完成的  

通用源码  

先看实现化角色，如代码清单29-16所示。

代码清单29-16 实现化角色
public interface Implementor {
//基本方法
public void doSomething();
public void doAnything();
}

它没有任何特殊的地方，就是一个一般的接口，定义要实现的方法。

其实现类如代码清单29-17所示。

代码清单29-17 具体实现化角色
public class ConcreteImplementor1 implements Implementor{
public void doSomething(){
//业务逻辑处理
}
public void doAnything(){
//业务逻辑处理
}
}

public class ConcreteImplementor2 implements Implementor{
public void doSomething(){
//业务逻辑处理
}
public void doAnything(){
//业务逻辑处理
}
}

上面定义了两个具体实现化角色——代表两个不同的业务逻辑。

我们再来看抽象化角色，如代码清单29-18所示。

代码清单29-18 抽象化角色
public abstract class Abstraction {
//定义对实现化角色的引用
private Implementor imp;
//约束子类必须实现该构造函数
public Abstraction(Implementor _imp){
this.imp = _imp;
}
//自身的行为和属性
public void request(){
this.imp.doSomething();
}
//获得实现化角色
public Implementor getImp(){
return imp;
}
}

为什么要增加一个构造函数？答案是为了提醒子类，你必须做这项工作，指定实现者，特别是已经明确了实现者，则尽量清晰明确地定义出来。

我们来看具体的抽象化角色，如代码清单29-19所示。

代码清单29-19 具体抽象化角色
public class RefinedAbstraction extends Abstraction {
//覆写构造函数
public RefinedAbstraction(Implementor _imp){
super(_imp);
}
//修正父类的行为
@Override
public void request(){
/*
* 业务处理...
*/
super.request();
super.getImp().doAnything();
}
}

想想看，如果我们的实现化角色有很多的子接口，然后是一堆的子实现。如果在构造函数中不传递一个尽量明确的实现者，代码就很不清晰。

我们来看场景类如何模拟，如代码清单29-20所示。

代码清单29-20 场景类
public class Client {
public static void main(String[] args) {
//定义一个实现化角色
Implementor imp = new ConcreteImplementor1();
//定义一个抽象化角色
Abstraction abs = new RefinedAbstraction(imp);
//执行行文
abs.request();
}
}

桥梁模式是一个非常简单的模式，它只是使用了类间的聚合关系、继承、覆写等常用功能，但是它却提供了一个非常清晰、稳定的架构。   

优点  

● 抽象和实现分离  

这也是桥梁模式的主要特点，它完全是为了解决继承的缺点而提出的设计模式。在该模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上。  

● 优秀的扩充能力  

● 实现细节对客户透明  

使用场景  

● 不希望或不适用使用继承的场景  

● 接口或抽象类不稳定的场景  

● 重用性要求较高的场景  

注意事项 

桥梁模式的意图还是对变化的封装，尽量把可能变化的因素封装到最细、最小的逻辑单元中，避免风险扩散。因此读者在进行系统设计时，发现类的继承有N层时，可以考虑使用桥梁模式。 

继承的优点有很多，可以把公共的方法或属性抽取，父类封装共性，子类实现特性，这是继承的基本功能。  

缺点有没有？有！即强侵入，父类有一个方法，子类也必须有这个方法。  

对于比较明确不发生变化的，则通过继承来完成；

若不能确定是否会发生变化的，那就认为是会发生变化，则通过桥梁模式来解决，这才是一个完美的世界。  

实例   山寨工厂

先看Product抽象类  

代码清单29-7 抽象产品类
public abstract class Product {
//甭管是什么产品它总要能被生产出来
public abstract void beProducted();
//生产出来的东西，一定要销售出去，否则亏本
public abstract void beSelled();
}

House产品类如代码清单29-8所示。

代码清单29-8 房子
public class House extends Product {
 //豆腐渣就豆腐渣呗，好歹也是房子
 public void beProducted() {
 System.out.println("生产出的房子是这样的...");
}
//虽然是豆腐渣，也是能够销售出去的
public void beSelled() {
 System.out.println("生产出的房子卖出去了...");
}
}

既然是产品类，那肯定有两种行为要存在：被生产和被销售，否则就不能称为产品了。

我们再来看iPod产品类，如代码清单29-9所示。

代码清单29-9 iPod产品
public class IPod extends Product {
public void beProducted() {
System.out.println("生产出的iPod是这样的...");
}
public void beSelled() {
System.out.println("生产出的iPod卖出去了...");
}
}

产品是由公司生产出来的，我们来看公司Corp抽象类，如代码清单29-10所示。

代码清单29-10 抽象公司类
public abstract class Corp {
//定义一个抽象的产品对象，不知道具体是什么产品
private Product product;
//构造函数，由子类定义传递具体的产品进来
public Corp(Product product){
this.product = product;
}
//公司是干什么的？赚钱的！
public void makeMoney(){
//每家公司都是一样，先生产
this.product.beProducted();
//然后销售
this.product.beSelled();
}
}

这里多了个有参构造，其目的是要继承的子类都必选重写自己的有参构造函数，把产品类传递进来，

再看子类HouseCorp的实现，如代码清单29-11所示。

代码清单29-11 房地产公司
public class HouseCorp extends Corp {
//定义传递一个House产品进来
public HouseCorp(House house){
super(house);
}
//房地产公司很High了，赚钱，计算利润
public void makeMoney(){
super.makeMoney();
System.out.println("房地产公司赚大钱了...");
}
}

继续看山寨公司的实现，如代码清单29-12所示。

代码清单29-12 山寨公司
public class ShanZhaiCorp extends Corp {
//产什么产品，不知道，等被调用的才知道
public ShanZhaiCorp(Product product){
super(product);
}
//狂赚钱
public void makeMoney(){
super.makeMoney();
System.out.println("我赚钱呀...");
}
}

HouseCorp类和ShanZhaiCorp类的区别是在有参构造的参数类型上，HouseCorp类比较明确，我就是只要House类，所以直接定义传递进来的必须是House类， 一个类尽可能少地承担职责，那方法也一样，既然HouseCorp类已经非常明确地只生产House产品，那为什么不定义成House类型呢？ShanZhaiCorp就不同了，它确定不了生产什么类型。

好了，两大对应的阵营都已经产生了。我们再看Client程序，如代码清单29-13所示。

代码清单29-13 场景类
public class Client {
public static void main(String[] args) {
House house = new House();
System.out.println("-------房地产公司是这样运行的-------");
//先找到房地产公司
HouseCorp houseCorp =new HouseCorp(house);
//看我怎么挣钱
houseCorp.makeMoney();
System.out.println("\n");
//山寨公司生产的产品很多，不过我只要指定产品就成了
System.out.println("-------山寨公司是这样运行的-------");
ShanZhaiCorp shanZhaiCorp = new ShanZhaiCorp(new IPod());
shanZhaiCorp.makeMoney();
}
}

深入思考一下，既然万物都是运动的，现在只有房地产公司和山寨公司，那以后我会不会增加一些其他的公司呢？或者房地产公司会不会对业务进行细化，如分为公寓房公司、别墅公司，以及商业房公司等呢？

绝对会的！但是你发觉没有，这种变化对我们上面 的类图来说不会做大的修改，充其量只是扩展：

● 增加公司，要么继承Corp类，要么继承HouseCorp或ShanZhaiCorp，不用再修改原有的类了。

● 增加产品，继承Product类，或者继承House类，你要把房子分为公寓房、别墅、商业用房等。

唯一要修改的就是Client类。类都增加了，高层模块也需要修改，也就是说Corp类和Product类都可以自由地扩展，而不会对整个应用产生太大的变更，这就是桥梁模式。