举例说明
假如我们需要开发一个同时支持PC和手机端的坦克游戏,游戏在PC和手机上功能都一样,都有同样的类型,面临同样的功能需求变化,比如坦克可能有很多种不同的型号:T50,T75,T90……
对于其中的坦克设计,我们可能很容易设计出来一个Tank的抽象基类,然后各种不同型号的Tank继承自该类;
这一步实现一点问题也没有,也符合开闭原则,继续往下看。
另外的变化原因
但是PC和手机上的图形绘制、声效、操作等实现完全不同……因此对于各种型号的坦克,都要提供各种不同平台上的坦克实现:
我们一般会设计成这样,但是这样看很怪,这样的设计会带来很多问题:有很多重复代码,类的结构过于复杂,难以维护,最致命的是引入任何新平台,比如在TV上的Tank游戏,都会让整个类层级结构复杂化。我们做软件,修改的时候,修改的越少越好,说明隔离的比较好。
思考上述问题的症结:事实上由于Tank类型的固有逻辑,使得Tank类型具有了两个变化的维度——一个变化的维度为“平台的变化”,一个变化的维度为“型号的变化”。
如何应对这种“多维度的变化”?如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化,而不引入额外的复杂度?
将抽象部分与实现部分分离,使它们都可以独立地变化。
其中imp的地方就是一个组合。Abstraction就是我们例子中的Tank,它的子类RefinedAbstraction就是T50等型号。Implementor是TankPlatformImplementation类,ConcreteImplementorA和ConcreteImplementorB分别是PCTankImplementation和MobileTankImplementation。
整个设计模式的关键就是组合的使用。
public abstract class TankModel { protected TankPlatformImplementation _tankImp; public TankModel(TankPlatformImplementation tankImp) { _tankImp = tankImp; } public abstract void Run(); } public abstract class TankPlatformImplementation { public abstract void MoveTankTo(int x, int y); public abstract void DrawTank(); public abstract void Attack(); } /// <summary> /// PC坦克 /// </summary> public class PCTankImplatation : TankPlatformImplementation { string _tankModel; public PCTankImplatation(string tankModel) { _tankModel = tankModel; } /// <summary> /// 绘制坦克 /// </summary> public override void DrawTank() { Console.WriteLine(_tankModel + "PC坦克绘制成功!"); } /// <summary> /// 坦克移动 /// </summary> /// <param name="x">x坐标</param> /// <param name="y">y坐标</param> public override void MoveTankTo(int x, int y) { Console.WriteLine(_tankModel + "PC坦克已经移动到了坐标(" + x + "," + y + ")处"); } /// <summary> /// 攻击 /// </summary> public override void Attack() { Console.WriteLine(_tankModel + "PC坦克开始攻击"); } } /// <summary> /// T50型号坦克 /// </summary> public class T50 : TankModel { public T50(TankPlatformImplementation tankImp) : base(tankImp) { } public override void Run() { _tankImp.DrawTank(); _tankImp.MoveTankTo(100, 100); _tankImp.Attack(); } } /// <summary> /// 客户端调用 /// </summary> public class App { void Main(string[] agrs) { T50 t = new T50(new PCTankImplatation("T50")); t.Run(); } }
使用了桥接模式后,当需求发生变化后就很容易来应对了,假如现在又多了一种T60型号的坦克,并且添加了一个手机平台。只需要添加T60型号的具体类和手机平台具体类即可,如下:
/// <summary> /// 手机坦克 /// </summary> public class MobileTankImplatation : TankPlatformImplementation { string _tankModel; public MobileTankImplatation(string tankModel) { _tankModel = tankModel; } /// <summary> /// 绘制坦克 /// </summary> public override void DrawTank() { Console.WriteLine(_tankModel+"Mobile坦克绘制成功!"); } /// <summary> /// 坦克移动 /// </summary> /// <param name="x">x坐标</param> /// <param name="y">y坐标</param> public override void MoveTankTo(int x, int y) { Console.WriteLine(_tankModel+"Mobile坦克已经移动到了坐标(" + x + "," + y + ")处"); } /// <summary> /// 攻击 /// </summary> public override void Attack() { Console.WriteLine(_tankModel+"Mobile坦克开始攻击"); } } /// <summary> /// T60型号坦克 /// </summary> public class T60 : TankModel { public T60(TankPlatformImplementation tankImp) : base(tankImp) { } public override void Run() { _tankImp.DrawTank(); _tankImp.MoveTankTo(400, 100); _tankImp.Attack(); } }
添加这两个类后现在我们有T50型号、 T60型号 、PC平台、手机平台,虽然只添加了两个类,但现在有了四种组合,看客户端代码的调用:
/// <summary> /// 客户端调用 /// </summary> public class App { void Main(string[] agrs) { //T50在PC上 T50 t50PC = new T50(new PCTankImplatation("T50")); t50PC.Run(); //T50在Mobile上 T50 t50Mobile = new T50(new MobileTankImplatation("T50")); t50Mobile.Run(); //T60在PC上 T60 t60PC = new T60(new PCTankImplatation("T60")); t60PC.Run(); //T60在Mobile上 T60 t60Mobile = new T60(new MobileTankImplatation("T60")); t60Mobile.Run(); } }
Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象(Tank的型号)和实现(不同的平台)可以沿着各自的维度来变化。
所谓抽象和实现沿着各自维度的变化,即“子类化”它们(比如不同的Tank型号子类,和不同的平台子类),得到各个子类之后,便可以任意组合它们,从而获得不同平台上的不同型号。
Bridge模式有时候类似于多继承方案,但是多继承方案往往违背单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方法。
下面是针对上面的例子,多继承接口的一种写法:
这样PCT50既需要写T50的实现,又要写Platform的实现,它把型号和平台的变化都引入了PCT50。这样就把两个本不该扭在一起的事务扭在了一起,这样的设计更加糟糕,而且也违背了类的单一职责原则。
Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。
桥模式并不同于适配器模式,适配器模式其实是一个事后诸葛亮,当发现以前的东西不适用了才去做一个弥补的措施。桥模式相对来说所做的改变比适配器模式早,它可以适用于有两个甚至两个以上维度的变化。
原文:https://www.cnblogs.com/springsnow/p/11304414.html