实现了抽象和实现部分的分离，从而极大的提供了系统的灵活性，让抽象部分和实现部分独立开来，这有助于系统进行分层设计，从而产生更好的结构化系统。
对于系统的高层部分，只需要知道抽象部分和实现部分的接口就可以了，其它的部分由具体业务来完成。
桥接模式替代多层继承方案，可以减少子类的个数，降低系统的管理和维护成本。
桥接模式的引入增加了系统的理解和设计难度，由于聚合关联关系建立在抽象层， 要求开发者针对抽象进行设计和编程
桥接模式要求正确识别出系统中两个独立变化的维度（抽象，和实现），因此其使用范围有一定的局限性，即需要有这样的应用场景。
桥接模式其它应用场景对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用
常见的应用场景:
-JDBC驱动程序
-银行转账系统
抽象）转账分类: 网上转账，柜台转账，AMT转账
行为）转账用户类型：普通用户，银卡用户，金卡用户..
-消息管理
抽象）消息类型：即时消息，延时消息
行为）消息分类：手机短信，邮件消息，QQ消息…
装饰者模式 星巴克咖啡订单项目星巴克咖啡订单项目（咖啡馆）：
咖啡种类/单品咖啡：Espresso(意大利浓咖啡)、ShortBlack、LongBlack(美式 咖啡)、Decaf(无因咖啡)
调料：Milk、Soy(豆浆)、Chocolate
要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便
使用OO的来计算不同种类咖啡的费用: 客户可以点单品咖啡，也可以单品咖啡+调料组合。
方案1-解决星巴克咖啡订单项目 （较差的方案） 示意图Drink 是一个抽象类，表示饮料
des就是对咖啡的描述, 比如咖啡的名字
cost() 方法就是计算费用，Drink 类中做成一个抽象方法.
Decaf 就是单品咖啡， 继承Drink, 并实现cost
Espress && Milk 就是单品咖啡+调料， 这个组合很多
问题：这样设计，会有很多类，当我们增加一个单品咖啡，或者一个新的调料， 类的数量就会倍增，就会出现类爆炸
方案2-解决星巴克咖啡订单 （好点）前面分析到方案1因为咖啡单品 + 调料 组合会造成类的倍增，因此可以做改进，将调料内置到Drink类，这样就不会造成类数量过多。从而提高项目 的维护性(如图)
示意图说明: milk,soy,chocolate 可以设计为Boolean,表示是否要添加相应的调料.
方案2-的问题分析方案2可以控制类的数量，不至于造成很多的类
在增加或者删除调料种类时，代码的维护量很大
考虑到用户可以添加多份调料时，可以将hasMilk返回一个对应int
考虑使用装饰者 模式
装饰者模式定义装饰者模式：动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性，装饰者模式也体现了开闭原则(ocp)
这里提到的动态的将新功能附加到对象和ocp原则，在后面的应用实例上会以代 码的形式体现，请同学们注意体会。
装饰者模式(Decorator)原理 示意图
装饰者模式就像
打包一个快递
主体：比如：陶瓷、衣服 (Component) // 被装饰者
包装：比如：报纸填充、塑料泡沫、纸板、木板(Decorator) 装饰者
Component
主体：比如类似前面的Drink
ConcreteComponent和Decorator
ConcreteComponent：具体的主体， 比如前面的各个单品咖啡
Decorator: 装饰者，比如各调料.