桥接模式,将抽象部分与它的实现部分分离,使他们都可以独立地变化。其主要目的就是不要盲目的使用继承,因为继承是一种强耦合结构,父类变,子类就要跟着变。所以在使用继承时,一定是“is-a”关系时才使用。桥接模式简单点来说就是实现系统可能有多角度分类,每一种分类都有可能变化,那么就把这种多角度分离出来让它们独立变化,减少他们之间的耦合。其适用性体现在,1.不希望在抽象和它的实现部分之间有一个固定的绑定关系;2.类的抽象以及它的实现都应该可以通过声场子类的方法加以扩充;3.一个抽象的实现部分的修改应该对客户不产生影响,或者想对客户完全隐藏抽象的实现部分;4.在多个对象间共享实现,但同时要求客户并不知道这一点。
《大话设计模式》里面举的例子是手机品牌和手机游戏之间的关系,不管是继承游戏还是继承手机品牌,未来扩展起来的时候都很痛苦。那么按照通用计算机软件处理的方式是怎样的呢?那就是,开发硬件的开发硬件去,开发软件的开发软件去,开发操作系统的去想办法统一市场,让软件支持这个操作系统就完了~说笑了哈,让手机品牌去继承手机接口,各种软件去继承手机软件接口,让手机接口去调用手机软件接口,这样以后不管增加手机品牌还是增加手机软件都只要扩展类可以了。
古剑里面,我是这样想的,战斗技能和人物状态之间的关系貌似也可以用这个模式啊。首先,人物状态主要包括这样一些影响:一些状态数值的增减,包括精气神,攻防武运速等,异常状态的产生和消去,包括残、铸、冻,中毒啊什么的;其次,影响人物状态的不止是使用技能,补血点,客栈,剧情,迷宫场景里的某些物体(火焰、冰凌、石块、毒沼)等都会对人物状态产生影响。这样其实就可以把状态的变化看成手机软件,影响状态的技能、物体、补血点之类的东西当做手机型号,这就可以构成很经典的桥接模式。
估计我又想偏了,不过就这样吧,这是我在操场上走了两圈,晃悠了十几分钟,回来又想了好久记下来的成果。我觉得其实还是比较靠的上的。
代码如下。
implementor.h 文件
concreteImplementorA.h 文件
concreteImplementorA.cpp 文件
concreteImplementorB.h 文件
concreteImplementorB.cpp 文件
abstraction.h 文件
abstraction.cpp 文件
refinedAbstraction.h 文件
refinedAbstraction.cpp 文件
main.cpp 文件
运行结果