桥模式应对的是哪种变化，结合类图举个例子
RT
[解决办法]
我在另一个帖子的回复，差不多能回答你的问题：
你可以从Bridge的一点基本要点开始理解：
1. 它强调的是抽象和实现的分离，注意，这的实现不是用‘类继承’的方式，而是用‘对象组合’的方式。
传统的方式是：把具体的实现代码，写在子类里，但是Bridge却把实现代码，放在别的类里面。
2. 对于适用Bridge模式的问题，而不Bridge来解决，会有什么后果？答案是：可以解决，但是随着问题复杂度的增加，要写的类，也会大大的增加，很难维护。
3. 为什么会分开、为什么有变化？假设你要做一辆车，需要解决刹车的问题。‘车’是一个抽象的概念，它下面有‘卡车’、‘私家车’、‘公交车’，每种车的刹车方式都不一样，假设目前，我们有2个刹车方式：普通刹车、ABS刹车，每次只能选择一个。
你要知道，每种车的设计都可以用这两种刹车方式之一，如果不用Bridge模式，我们用普通的类继承的方式实现’刹车‘，那么我们需要为这3类车各自实现它们的这2种刹车方式，总共有6种组合。
变化1来了：假设你的业务做大了，你开始生产一种新类型的车：装甲车。你需要在装甲车里面把刹车方式重新实现一遍，这样需要新增2个类：普通刹车的装甲车类，ABS刹车的装甲车类。
变化2来了：假设你新研发了一种刹车方式：用降落伞包刹车（类似航天飞机的刹车方式），你之前的所有类型的车都可以使用该刹车方式，怎么办？我们需要增加4个新的类，因为目前为止，共有4类车。
变化3来了：假设现在的3种刹车方式需要调整、升级，你得修改4个类，因为具体的方式已经内嵌到这些类中了。
如果用Bridge模式，车本身不实现刹车的功能，它只有一个接口。所有车的子类，也不实现刹车功能，它们都有一个’刹车‘对象的指针。这个刹车对象，或者叫刹车装置，是来自于外部。
再来看下上面的3个变化
变化1：新增一个’装甲车‘类即可，因为刹车方式已经用外部的类实现，装甲车本身无须实现。
变化2：新增一个’降落伞刹车‘类即可
变化3：哪个刹车功能需要调整，就调整哪个，对于车来说是透明的。
综上，你可以看到，用了Bridge，所有组合的具体信息，都在最后组装车的时候用到：
(new 装甲车().setBraker(new ABS())).brake();
