.Net结构型设计模式之桥接模式(Bridge)

一、动机(Motivation)

在很多游戏场景中,会有这样的情况:【装备】本身会有的自己固有的逻辑,比如枪支,会有型号的问题,同时现在很多的游戏又在不同的介质平台上运行和使用,这样就使得游戏的【装备】具有了两个变化的维度——一个变化的维度为“平台的变化”,另一个变化的维度为“型号的变化”。如果我们要写代码实现这款游戏,难道我们针对每种平台都实现一套独立的【装备】吗?复用在哪里?如何应对这种“多维度的变化”?如何利用面向对象技术来使得【装备】可以轻松地沿着“平台”和“型号”两个方向变化,而不引入额外的复杂度?

二、意图(Intent)

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

桥模式不能只是认为是抽象和实现的分离,它其实并不仅限于此。其实两个都是抽象的部分,更确切的理解,应该是将一个事物中多个维度的变化分离。

三、结构(Structure)

其中imp的地方就是一个组合。Abstraction就是我们例子中的Tank,它的子类RefinedAbstraction就是T50等型号。Implementor是TankPlatformImplementation类,ConcreteImplementorA和ConcreteImplementorB分别是PCTankImplementation和MobileTankImplementation。

整个设计模式的关键就是组合的使用。

四、模式的组成

桥接模式的结构包括Abstraction、RefinedAbstraction、Implementor、ConcreteImplementorA和ConcreteImplementorB五个部分,其中: 
(1)、抽象化角色(Abstraction):抽象化给出的定义,并保存一个对实现化对象(Implementor)的引用。 
(2)、修正抽象化角色(Refined Abstraction):扩展抽象化角色,改变和修正父类对抽象化的定义。 
(3)、实现化角色(Implementor):这个角色给出实现化角色的接口,但不给出具体的实现。必须指出的是,这个接口不一定和抽象化角色的接口定义相同,实际上,这两个接口可以非常不一样。实现化角色应当只给出底层操作,而抽象化角色应当只给出基于底层操作的更高一层的操作。 
(4)、具体实现化角色(Concrete Implementor):这个角色给出实现化角色接口的具体实现。 
在桥接模式中,两个类Abstraction和Implementor分别定义了抽象与行为类型的接口,通过调用两接口的子类实现抽象与行为的动态组合。

五、桥接模式的具体代码实现

假如我们需要开发一个同时支持PC和手机端的坦克游戏,游戏在PC和手机上功能都一样,都有同样的类型,面临同样的功能需求变化,比如坦克可能有很多种不同的型号:T50,T75,T90……

对于其中的坦克设计,我们可能很容易设计出来一个Tank的抽象基类,然后各种不同型号的Tank继承自该类;

这一步实现一点问题也没有,也符合开闭原则,继续往下看。

另外的变化原因

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

我们一般会设计成这样,但是这样看很怪,这样的设计会带来很多问题:有很多重复代码,类的结构过于复杂,难以维护,最致命的是引入任何新平台,比如在TV上的Tank游戏,都会让整个类层级结构复杂化。我们做软件,修改的时候,修改的越少越好,说明隔离的比较好。

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();
}

/// 

/// PC坦克
///
public class PCTankImplatation : TankPlatformImplementation
{
    string _tankModel;
    public PCTankImplatation(string tankModel)
    {
        _tankModel = tankModel;
    }
    /// 

    /// 绘制坦克
    ///
    public override void DrawTank()
    {
        Console.WriteLine(_tankModel + "PC坦克绘制成功!");
    }
    /// 

    /// 坦克移动
    ///
    /// x坐标
    /// y坐标
    public override void MoveTankTo(int x, int y)
    {
        Console.WriteLine(_tankModel + "PC坦克已经移动到了坐标(" + x + "," + y + ")处");
    }
    /// 

    /// 攻击
    ///
    public override void Attack()
    {
        Console.WriteLine(_tankModel + "PC坦克开始攻击");
    }
}
/// 

/// T50型号坦克
///
public class T50 : TankModel
{
    public T50(TankPlatformImplementation tankImp) : base(tankImp) { }
    public override void Run()
    {
        _tankImp.DrawTank();
        _tankImp.MoveTankTo(100, 100);
        _tankImp.Attack();
    }
}

/// 

/// 客户端调用
///
public class App
{
    void Main(string[] agrs)
    {
        T50 t = new T50(new PCTankImplatation("T50"));
        t.Run();
    }
}

使用了桥接模式后,当需求发生变化后就很容易来应对了,假如现在又多了一种T60型号的坦克,并且添加了一个手机平台。只需要添加T60型号的具体类和手机平台具体类即可,如下:

///
/// 手机坦克
///
public class MobileTankImplatation : TankPlatformImplementation
{
    string _tankModel;
    public MobileTankImplatation(string tankModel)
    {
        _tankModel = tankModel;
    }
    /// 

    /// 绘制坦克
    ///
    public override void DrawTank()
    {
        Console.WriteLine(_tankModel+"Mobile坦克绘制成功!");
    }
    /// 

    /// 坦克移动
    ///
    /// x坐标
    /// y坐标
    public override void MoveTankTo(int x, int y)
    {
        Console.WriteLine(_tankModel+"Mobile坦克已经移动到了坐标(" + x + "," + y + ")处");
    }
    /// 

    /// 攻击
    ///
    public override void Attack()
    {
        Console.WriteLine(_tankModel+"Mobile坦克开始攻击");
    }
}
/// 

/// T60型号坦克
///
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平台、手机平台,虽然只添加了两个类,但现在有了四种组合,看客户端代码的调用:

///
/// 客户端调用
///
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();
    }
}

六、桥接模式的实现要点:

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

1、桥接模式的优点:

(1)、把抽象接口与其实现解耦。 
(2)、抽象和实现可以独立扩展,不会影响到对方。 
(3)、实现细节对客户透明,对用于隐藏了具体实现细节。

2、桥接模式的缺点:

增加了系统的复杂度

3、桥接模式的使用场景:

(1)、如果一个系统需要在构件的抽象化角色和具体化角色之间添加更多的灵活性,避免在两个层次之间建立静态的联系。 
(2)、设计要求实现化角色的任何改变不应当影响客户端,或者实现化角色的改变对客户端是完全透明的。 
(3)、需要跨越多个平台的图形和窗口系统上。 
(4)、 一个类存在两个独立变化的维度,且两个维度都需要进行扩展。

下面是针对上面的例子,多继承接口的一种写法:

这样PCT50既需要写T50的实现,又要写Platform的实现,它把型号和平台的变化都引入了PCT50。这样就把两个本不该扭在一起的事务扭在了一起,这样的设计更加糟糕,而且也违背了类的单一职责原则。

Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。

桥模式并不同于适配器模式,适配器模式其实是一个事后诸葛亮,当发现以前的东西不适用了才去做一个弥补的措施。桥模式相对来说所做的改变比适配器模式早,它可以适用于有两个甚至两个以上维度的变化。

到此这篇关于.Net结构型设计模式之桥接模式(Bridge)的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • .Net结构型设计模式之适配器模式(Adapter)

    一.动机(Motivation) 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的. 如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口? 二.意图(Intent) 将一个类的接口转换成客户希望的另一个接口.Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作. 例说Adapter应用 这种实际上是一种委派的调用,本来是发送请求给MyStack,但是M

  • .Net结构型设计模式之桥接模式(Bridge)

    一.动机(Motivation) 在很多游戏场景中,会有这样的情况:[装备]本身会有的自己固有的逻辑,比如枪支,会有型号的问题,同时现在很多的游戏又在不同的介质平台上运行和使用,这样就使得游戏的[装备]具有了两个变化的维度——一个变化的维度为“平台的变化”,另一个变化的维度为“型号的变化”.如果我们要写代码实现这款游戏,难道我们针对每种平台都实现一套独立的[装备]吗?复用在哪里?如何应对这种“多维度的变化”?如何利用面向对象技术来使得[装备]可以轻松地沿着“平台”和“型号”两个方向变化,而不引入

  • Java结构型设计模式之桥接模式详细讲解

    目录 桥接模式 概述 应用场景 优缺点 主要角色 桥接模式的基本使用 创建实现角色 创建具体实现角色 创建抽象角色 创建修正抽象角色 客户端调用 桥接模式实现消息发送 创建实现角色 创建具体实现角色 创建抽象角色 创建修正抽象角色 客户端调用 桥接模式 概述 桥接模式(Bridge Pattern)也称为桥梁模式.接口(Interfce)模式或柄体(Handle and Body)模式,属于结构型模式. 它是将抽象部分与它的具体实现部分分离,使它们都可以独立地变化. 桥接模式主要目的是通过组合的

  • .Net结构型设计模式之代理模式(Proxy)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.代理模式的分类: 六.代理模式的具体实现 七.代理模式的实现要点: 1.代理模式的优点: 2.代理模式的缺点: 3.代理模式的使用场景: 八..NET 中代理模式的实现 九.总结 一.动机(Motivate) 在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者.或者系统结构带来很多麻烦.如何在不失去

  • .Net结构型设计模式之组合模式(Composite)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.组合模式的具体代码实现 1.透明式的组合模式 2.安全式的组合模式 六.组合模式的实现要点: 组合模式的优点: 组合模式的缺点: 在以下情况下应该考虑使用组合模式: 七..NET 中组合模式的实现 一.动机(Motivate) 在我们的操作系统中有文件夹的概念,文件夹可以包含文件夹,可以嵌套多层,最里面包含的是文件,这个概念和“俄罗斯套娃”很像.当然还有很多的例子,例如我们使用系统

  • .Net结构型设计模式之外观模式(Facade)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.外观模式的具体实现 六.实现要点: 1.外观模式的优点: 2.外观模式的缺点: 3.在以下情况下可以考虑使用外观模式: 七.NET 中外观模式的实现 一.动机(Motivate) 在软件系统开发的过程中,当组件的客户(即外部接口,或客户程序)和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战.如何简化外部客户程序和系统间的交互

  • Java结构型设计模式中代理模式示例详解

    目录 代理模式 分类 主要角色 作用 静态代理与动态代理的区别 静态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 JDK动态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 小优化 CGLIB动态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 小优化 CGLIB与JDK动态代理区别 1.执行条件 2.实现机制 3.性能 代理模式 代理模式(Proxy Pattern)属于结构型模式. 它是指为其他对象提供一种代理以控制对这个对象的

  • Java结构型设计模式中建造者模式示例详解

    目录 建造者模式 概述 角色 优缺点 应用场景 基本使用 创建产品类 创建建造者类 使用 链式写法 创建产品类与建造者类 使用 建造者模式 概述 建造者模式(Builder Pattern)属于创建型模式. 它是将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示. 简而言之:建造者模式就是使用多个简单的对象一步一步构建成一个复杂的对象. 建造者模式适用于创建对象需要很多步骤,但是步骤的顺序不一定固定.如果一个对象有非常复杂的内部结构(很多属性),可以将复杂对象的创建和使用进行分

  • Java结构型设计模式之组合模式详解

    目录 组合模式 应用场景 优缺点 主要角色 组合模式结构 分类 透明组合模式 创建抽象根节点 创建树枝节点 创建叶子节点 客户端调用 安全组合模式 创建抽象根节点 创建树枝节点 创建叶子节点 客户端调用 组合模式 组合模式(Composite Pattern)也称为整体-部分(Part-Whole)模式,属于结构型模式. 它的宗旨是通过将单个对象(叶子节点)和组合对象(树枝节点)用相同的接口进行表示,使得客户端对单个对象和组合对象的使用具有一致性. 组合模式一般用来描述整体与部分的关系,它将对象

  • C++设计模式之桥接模式(Bridge)

    桥接模式属于先天模式,这里的先天模式就是说一开始就要把结构搭建好,方便后来的扩展,而不是对已经出现的模块和接口进行改进扩展的.桥接的核心在于实体类和操作类之间的聚合关系,这个聚合关系就是我们所说的"桥",不同于装饰.代理和适配器模式的中的聚合关系,桥接不存在两者之间的继承关系,操作类是完全解耦的,而实体类对于操作类也只是弱耦合. 作用 将抽象部份与它的实现部份分离,使它们都可以独立地变化. 类视图 实现 //操作类 class action { public: virtual void

  • java设计模式之桥接模式(Bridge)

    概述 桥接模式一种结构型模式,它主要应对的是:由于实际的需要,某个类具有两个或以上的维度变化,如果只是用继承将无法实现这种需要,或者使得设计变得相当臃肿. 桥接模式的做法是把变化的部分抽象出来,使变化部分与主类分离开来,从而将多个维度的变化彻底分离.最后,提供一个管理类来组合不同维度上的变化,通过这种组合来满足业务的需要. UML结构图 代码示例 package interview; interface Implementor{ void operationImpl(); } abstract

随机推荐