设计模式------桥模式~bridge

[code]
/**
语义：实现系统可能有多个维度的分类，每一种分类都可能变化，那么就把这种多角度分离出来让他们独立变化，减少他们之间的耦合
* 按性质划分，按类型划分----两个维度的划分
* 所以说这两个维度会有排列组合---怎么构建子类是个问题，必须避免类爆炸
* 先看传统方法

不用桥接模式的坏处： 如果使用继承，那么子类和父类是紧耦合的，当你需要复用子类时，如果继承下来的实现不合适解决新问题，则父类必须重写或被其他更合适的类替换，这种依赖关系限制了灵活性并最终限制了复用性。

怎么办呢？ 优先使用合成/聚合复用原则。。。。

比如：手机是不同的品牌公司，各自做自己的软件，就像继承结构的设计一样，而PC却是硬件厂商做硬件，软件厂商做软件，组合起来才是可用的机器。。是的。。组合。。。当类的划分太多了，我们就做小粒度的东西，然后再组合起来形成千变万化的产品
*/
例子1：
手机可以这样分类：
手机品牌
-----手机品牌M
-------手机品牌M通讯录
-------手机品牌M游戏
-----手机品牌N
------手机品牌N通讯录
------手机品牌N游戏
也可以这样分类：
手机软件
------通讯录
------手机品牌N通讯录
-------手机品牌M通讯录
------游戏
-------手机品牌M游戏
------手机品牌N游戏

但是从面向对象的观点来看，他们明显是继承关系。。。没错。。是父子的关系哈。。因为从树形的结构上就可以看出来嘛。。。。。，继承可以把多维度全部表现出来


我们从细粒度的方式来考虑:

我们的分类无非有两种， 第一按照品牌分类，第二按照功能分类
手机品牌
-----手机品牌N
-----手机品牌M

手机软件
-----通讯录
-----游戏
这里只能按照一个维度表现出来，不能按照多维度表现出来。。。所以是细粒度的。。我们只关注一个维度。。。然后组合成多个维度

剩下一个问题：怎么组合（这里的组合其实是面向对象术语上的聚合。。。）
从语文角度来考虑。。。
手机品牌N的通讯录 通讯录的手机品牌N 哪个能读通呢？
当然是 手机品牌N的通讯录。。。那么手机品牌包含通讯录，他们是聚合关系（软件并不是品牌的一部分）


---------------------------忧郁的分割线-----------------------------------------------------
例子2：

public class Gift {

}
//第一个维度：
public class Flower extends Gift {

}
public class Ring extends Gift {

}
//第二个维度
public class WarnGift extends Gift {

}
public class WildGift extends Gift {

}



public class Gift {
protected GiftImpl g; //只允许子类用啦，所以用protected
//其实写Gift g;也一样，反正是设置一个插头的接受者，就是那个铜片片
//不过如果具体的和抽象的有区别的话，用GiftImpl可以继承下来更多的东西
}
public class WarnGift extends Gift {

//这个是抽象的维度，当然需要扩展所以他得是一个插座
public WarnGift(GiftImpl g){
this.g = g;
}
}
/*
所以温暖的花 GiftImpl g = new Flower();
WarnGift wg = new WarnGift(g);//温暖的花就有了哦
*/
[/code]