桥接模式(bridge)

场景
商城系统中常见的商品分类，以电脑为类，如何良好的处理商品分类销售的问题?
我们可以用多层继承结构实现右图的关系。

电脑可以做一个接口


增加子类
联想

神州

戴尔

问题：
扩展性问题(类个数膨胀问题)：
如果要增加一个新的电脑类型:智能手机，则要增加各个品牌下面的类。
如果要增加一个新的品牌，也要增加各种电脑类型的类。

违反单一职责原则：
每个类都承担了两个职责，违反了单一职责原则，承担了品牌和类型
一个类：联想笔记本，有两个引起这个类变化的原因

场景分析
商城系统中常见的商品分类，以电脑为类，如何良好的处理商品分类销售的问题?
这个场景中有两个变化的维度：电脑类型、电脑品牌。


这是一个新的类、这是一个新的类、用桥把它们连接起来

桥接模式核心要点：

处理多层继承结构，处理多维度变化的场景，将各个维度设计成独立的继承结构，使各个维度可以独立的扩展在抽象层建立关联。

另一个继承结构作为属性放到桥里面！

品牌


写电脑类型的维度
使用抽象类，因为需要有一个共有的属性–品牌
写构造器的时候把品牌传进来
（电脑类型里面持有对品牌的引用）



现在新加品牌：在品牌里加一个子类即可

新加类型：在电脑里加一个子类即可
测试


可以独立变化，后期的扩展非常的方便

桥接模式总结：

桥接模式可以取代多层继承的方案。 多层继承违背了单一职责原则，复用性较差，类的个数也非常多。桥接模式可以极大的减少子类的个数，从而降低管理和维护的成本。

桥接模式极大的提高了系统可扩展性，在两个变化维度中任意扩展一个维度，都不需要修改原有的系统，符合开闭原则。

就像一个桥，将两个变化维度连接起来。各个维度都可以独立的变化。故称之为：桥模式

桥接模式实际开发中应用场景

JDBC驱动程序
AWT中的Peer架构
银行日志管理：
格式分类：操作日志、交易日志、异常日志
距离分类：本地记录日志、异地记录日志
人力资源系统中的奖金计算模块：
奖金分类：个人奖金、团体奖金、激励奖金。
部门分类：人事部门、销售部门、研发部门。
OA系统中的消息处理：
业务类型：普通消息、加急消息、特急消息
发送消息方式：系统内消息、手机短信、邮件
两个变化维度