说说设计模式~桥梁模式(Bridge)
在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式。
意图
【GOF95】在提出桥梁模式的时候指出,桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化"。这句话有三个关键词,也就是抽象化、实现化和脱耦。
桥梁模式的成员
抽象化
存在于多个实体中的共同的概念性联系,就是抽象化。作为一个过程,抽象化就是忽略一些信息,从而把不同的实体当做同样的实体对待。
实现化
抽象化给出的具体实现,就是实现化,这里的实现化不是具体的实现,而是一个接口或者抽象类,它是对抽象化的扩展。
脱耦
所谓耦合,就是两个实体的行为的某种强关联。而将它们的强关联去掉,就是耦合的解脱,或称脱耦。在这里,脱耦是指将抽象化和实现化之间的耦合解脱开,或者说是将它们之间的强关联改换成弱关联。
将两个角色之间的继承关系改为聚合关系,就是将它们之间的强关联改换成为弱关联。因此,桥梁模式中的所谓脱耦,就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系,从而使两者可以相对独立地变化。这就是桥梁模式的用意。
何时能用到它?
某些类型由于自身的逻辑,它具有两个或多个维度的变化,这时使用桥梁模式
桥梁模式的结构图
桥梁模式实现说明
Abstraction:抽象者,有对实现者的引用
RefinedAbstraction:更新抽象者,对抽象者进行扩展,它可以添加或者修改抽象者的部分功能
Implementor:实现者,它是一个接口或者功能类,它是对实现进行的一个抽象
ConcreteImplementorA:具体实现者,是实现Implementor的一种方式
桥梁模式的C#实现
#region bridge pattern #region 抽象者 // "Abstraction" class Abstraction { // Fields protected Implementor implementor; // Properties public Implementor Implementor { set { implementor = value; } } // Methods virtual public void Operation() { implementor.Operation(); } } // "RefinedAbstraction" class RefinedAbstraction : Abstraction { // Methods override public void Operation() { implementor.Operation(); } } #endregion #region 实现者 // "Implementor" abstract class Implementor { // Methods abstract public void Operation(); } // "ConcreteImplementorA" class ConcreteImplementorA : Implementor { // Methods override public void Operation() { Console.WriteLine("ConcreteImplementorA Operation"); } } // "ConcreteImplementorB" class ConcreteImplementorB : Implementor { // Methods override public void Operation() { Console.WriteLine("ConcreteImplementorB Operation"); } } #endregion #endregion
调用代码
Abstraction abstraction = new RefinedAbstraction(); // Set implementation and call abstraction.Implementor = new ConcreteImplementorA(); abstraction.Operation(); // Change implemention and call abstraction.Implementor = new ConcreteImplementorB(); abstraction.Operation();
结果截图