设计模式 - Bridge模式

1 代码

using UnityEngine;
using System.Collections;

public abstract class AbstractionImp{
    public virtual void operation(){
        Debug.Log("AbstractionImp....imp...");
    }
}

public class ConcreteAbstractionImpA : AbstractionImp{
    public override void operation(){
        Debug.Log("ConcreteAbstractionImpA....");
    }
}

public abstract class Abstraction{
    public abstract void operation();
}

public class RefinedAbstraction : Abstraction{
    public AbstractionImp imp;
    public RefinedAbstraction(AbstractionImp imp){
        this.imp = imp;
    }

    public override void operation(){
        if(null != imp){
            imp.operation();
        }
    }
}

public class BridgeDemo : MonoBehaviour {

    //桥连模式
    void Start(){
        AbstractionImp imp = new ConcreteAbstractionImpA();
        Abstraction abs = new RefinedAbstraction(imp);
        abs.operation();
    }
}

2 总结

Bridge 是设计模式中比较复杂和难理解的模式之一,也是 OO 开发与设计中经常会用到 的模式之一。使用组合(委托)的方式将抽象和实现彻底地解耦,这样的好处是抽象和实现 可以分别独立地变化,系统的耦合性也得到了很好的降低。
GoF 在说明 Bridge 模式时,在意图中指出 Bridge 模式“将抽象部分与它的实现部分分 离,使得它们可以独立地变化”。这句话很简单,但是也很复杂,连 Bruce Eckel 在他的大作 《Thinking in Patterns》中说“Bridge 模式是 GoF 所讲述得最不好(Poorly-described)的模 式”,个人觉得也正是如此。原因就在于 GoF 的那句话中的“实现”该怎么去理解:“实现” 特别是和“抽象”放在一起的时候我们“默认”的理解是“实现”就是“抽象”的具体子类 的实现,但是这里 GoF 所谓的“实现”的含义不是指抽象基类的具体子类对抽象基类中虚 函数(接口)的实现,是和继承结合在一起的。而这里的“实现”的含义指的是怎么去实现 用户的需求,并且指的是通过组合(委托)的方式实现的,因此这里的实现不是指的继承基 类、实现基类接口,而是指的是通过对象组合实现用户的需求。理解了这一点也就理解了 Bridge 模式,理解了 Bridge 模式,你的设计就会更加 Elegant 了。
实际上上面使用 Bridge 模式和使用带来问题方式的解决方案的根本区别在于是通过继 承还是通过组合的方式去实现一个功能需求。因此面向对象分析和设计中有一个原则就是: Favor Composition Over Inheritance。其原因也正在这里。

如果你会用C++的指针。。。这些都很好理解