设计模式—桥梁模式(Bridge)

 桥梁模式是一个非常有用的模式,也是比较复杂的一个模式。熟悉这个模式对于理解面向对象的设计原则,包括"开-闭"原则(OCP)以及组合/聚合复用原则(CARP)都很有帮助

桥梁模式的用意

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

抽象化

存在于多个实体中的共同的概念性联系,就是抽象化。作为一个过程,抽象化就是忽略一些信息,从而把不同的实体当做同样的实体对待【LISKOV94】。

实现化

抽象化给出的具体实现,就是实现化。

脱耦

所谓耦合,就是两个实体的行为的某种强关联。而将它们的强关联去掉,就是耦合的解脱,或称脱耦。在这里,脱耦是指将抽象化和实现化之间的耦合解脱开,或者说是将它们之间的强关联改换成弱关联。

将两个角色之间的继承关系改为聚合关系,就是将它们之间的强关联改换成为弱关联。因此,桥梁模式中的所谓脱耦,就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系,从而使两者可以相对独立地变化。这就是桥梁模式的用意

结构图

可以看出,这个系统含有两个等级结构,也就是:

由抽象化角色和修正抽象化角色组成的抽象化等级结构。
由实现化角色和两个具体实现化角色所组成的实现化等级结构。
桥梁模式所涉及的角色有:

抽象化(Abstraction)角色:抽象化给出的定义,并保存一个对实现化对象的引用。
修正抽象化(Refined Abstraction)角色:扩展抽象化角色,改变和修正父类对抽象化的定义。
实现化(Implementor)角色:这个角色给出实现化角色的接口,但不给出具体的实现。必须指出的是,这个接口不一定和抽象化角色的接口定义相同,实际上,这两个接口可以非常不一样。实现化角色应当只给出底层操作,而抽象化角色应当只给出基于底层操作的更高一层的操作。
具体实现化(Concrete Implementor)角色:这个角色给出实现化角色接口的具体实现。
 

实现代码如下:

public abstract class BaseLog

{

    public abstract void Execute(string msg);

}


public class SysLog extends BaseLog

{

    public override void Execute(string msg)

    {

        //...... .系统日志

    }

}


public class OpreateLog extends BaseLog

{

    public override void Execute(string msg)

    {

        //...... 操作日志

    }

}
public abstract class Log

{

    protected BaseLog implementor;

 

    public BaseLog Implementor

    {

        set { implementor = value; }   

    }


    public virtual void Write(string log)

    {

        implementor.Execute(log);

    }

}


public class DatabaseLog extends Log

{

    public override void Write(string log)

    {

        implementor.Execute(log);

    }

}


public class TextFileLog extends Log

{

    public override void Write(string log)

    {

        implementor.Execute(log);

    }

}

 public static void Main(string[] args)

    {
       
        Log dblog = new DatabaseLog();

        dblog.Implementor = new SysLog();

        dblog.Write();
       

        Log txtlog = new TextFileLog();

        txtlog.Implementor = new OpreateLog();

        txtlog.Write();

    }

效果及实现要点

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

适用性

在以下的情况下应当使用桥梁模式:
1.如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的联系。
2.设计要求实现化角色的任何改变不应当影响客户端,或者说实现化角色的改变对客户端是完全透明的。
3.一个构件有多于一个的抽象化角色和实现化角色,系统需要它们之间进行动态耦合。
4.虽然在系统中使用继承是没有问题的,但是由于抽象化角色和具体化角色需要独立变化,设计要求需要独立管理这两者。

博客