桥接(Bridge)模式

 依赖倒置原则

抽象B是相对稳定的,实现细节B是相对变化的。

如果抽象B也不稳定,也会变化,怎么办?

假如我们需要一个支持PC和手机的坦克游戏,在PC上和手机上功能都一样。都有同样的类型,面临同样的需求功能变化,比如坦克可能有不同种的型号,T50 ,T75,T90......
对于其中的设计,我们很可能很容易地设计出来一个Tank的抽象类,然后不同类型的Tank继承自该类。

public abstract class Tank
{
 public abstract void Run();
 public abstract void Shot();
 public abstract void Thun();
}

public class T50:Tank{...}
public class T75:Tank{...}
public class T90:Tank{...}

但是PC上和手机上的图形绘制、声响、操作等实现完全不同,因此对于各种型号的坦克,都要提供各种平台上的各种坦克实现:

public class PCT50:T50{...}
public class PCT75:T75{...}
public class PCT90:T90{...}

public class MobileT50:T50{...}
public class MobileT75:T75{...}
public class MobileT90:T90{...}

这样的设计会带来很多问题,有很多重复代码,类的结构过于复杂,难以维护,最致命的是引入任何新平台,比如在TV上的坦克游戏,都会让
整个类层级结构复杂化。

1、动机
思考上述问题的症结,事实上由于Tank类型的固有逻辑,使得Tank类型具有了两个变化的维度,——一个变化的维度是“平台的变化”,一个变化的维度是“型号的变化”。

如何应对这种“多维度的变化”?如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化,而不引入额外的复杂度?


2、意图
将抽象部分与实现部分分离,使它们都可以独立地变化。

3、图

4、代码

public  class Abstraction
{
 protected Implementor imp;
 
 public void operation()
 {
  imp.operationImp();
 }
}

public abstract class Implementor
{
 public abstract void operationImp();
}

public class ConcreteImplementorA : Implementor
{
 public void operationImp()
 {
  ....
 }
}

Tank系统的具体代码:

public abstract class Tank
{
 TankPlatformImpletion tankImpl;
 public Tank(TankPlatformImpletion tankImpl)
 {
  this.tankImpl = tankImpl;
 }
 public abstract void Run();
 public abstract void Shot();
 public abstract void Thun();
}


public class T50:Tank
{
 public T50(TankPlatformImpletion tankImpl):base(tankImpl)
 {
 
 }

 public void Run()
 {
  tankImpl.MoveTankTo(from ,to)
 }

 public void Shot()
 {
  tankImpl.DoShot();
 }

 public void Thun
 {
  ...
 }
}

public abstract class TankPlatformImpletion
{
 public abstract void MoveTankTo(Point from , Point to);
 public abstract void DrawTank();
 public abstract void DoShot();
}

public class PCTankPlatformImpletion
{
 public void MoveTankTo(Point from , Point to)
 {
  ...
 }

 ....
}

public class App
{
 public static void Main()
 {
  TankPlatformImpletion tankImpl = new PCTankPlatformImpletion();
  TankT50 = new TankT50(tankImpl);
 }
}

5、要点
(1) Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象(Tank)的型号和实现(不同的平台)可以沿着各自的维度来变化。
(2) 所谓抽象和实现沿着各自维度的变化,即“子类化”它们,比如不同的Tank型号子类,和不同的平台子类。得到各个子类之后,便可以任意组合他们,从而获得不同的平台上的不同型号。
(3) Bridge模式有时候类似于多继承方案,但是多继承方案往往违背单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方案。
(4) Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,不一定要使用Bridge模式。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
设备树(device tree)机制是Linux内核从linux-3.x版本开始引进的一种机制,目的是解决内核源码的arch/arm目录下代码混乱的问题:随着ARM生态的快速发展,在内核源码的arch/arm目录下,存放着几十种arm芯片和几百个开发板相关的源文件,很多开发板和处理器的中断、寄存器等相关硬件资源都在这个目录下以.c或.h的文件格式定义。而对于内核来说,与这些硬件耦合,会导致内核代码混乱不堪,每个开发板上运行的内核镜像都必须单独编译配置,无法通用。什么时候Linux内核能像Windows镜像那样,无论你的电脑什么配置,一个Windows安装包,都可以直接下载安装运行呢?设备树机制,实现了Linux内核和硬件平台的解耦:每个硬件平台的硬件资源使用一个设备树文件(xxx.dts)来描述,而不是在arch/arm下以.c 或 .h 文件来定义。Linux内核是一个通用的内核,在启动过程中,在通过解析设备树中的硬件资源来初始化某个具体的平台。 引入设备树后,很多和内核驱动开发的工作也发生了变化:以往驱动工程师关注的头文件宏定义、寄存器定义,现在这些基本上不用关注,关注的重点则转向了如何根据硬件平台去配置和修改设备树文件。很多驱动的编程接口也发生了变化,开始慢慢使用device tree提供的编程接口去开发驱动。本期课程主要面向嵌入式开发人员,分享Linux下驱动开发所需要的设备树知识和必备技能
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值