设计模式学习之Bridge模式

情绪有点复杂啊, 真是不好。总是会因为各种各样的情绪影响着学习生活。

怎么说呢, 今天应该是开心的吧, 嗯,的确是的,幸福就在自己身边,是很美好的一件事。

好了,废话少说了, 很多事情都还没有结论,只能慢慢努力吧。只有自己实力强大了, 一切才有可能。

不怕寂寞, 不怕繁华。

Bridge、桥梁(桥接)模式。

——“将抽象与其实现解耦, 使他们都可以独立的变化。” 这个, 的确好抽象啊, 话说我也开不太懂这个概念, 抽象和实现解耦,独立变化是什么概念。

抽象是不同事物之间概念上的联系方式, 也就是说是共性部分, 而解耦是让各种事物互相独立地形式, 或者至少明确地声明之间的关系。

看了这个图以后貌似有了点新的理解,不过可能还是不得其门而入。

举个例子吧, 又带MM去“啃不起”吃汉堡,(-。-,真心啃不起啊, 而且个人也没觉得这里有多好吃的, 哈哈,不过幸好这不是真的,-。-, 那就意味着妹纸也没有哇), 然后我们假设这些汉堡都是要加番茄酱的, 他们有各种名字各种口味的汉堡, 然后番茄酱也有从酸到甜各个等级, 然后客户往往会要求加某个等级的番茄酱,但是每个客户都不一样,然后就会有很多配搭,那怎么样才能快速的分类呢? 如果每个汉堡都对应各个等级的番茄酱。 假如有3种口味的汉堡,3个等级的番茄酱, 那么就会出现如下的情况:

假设我又更多的汉堡和更多的番茄酱,那么这个阵容就很庞大了啊。

能够看得出来这种设计汉堡跟番茄酱的耦合性太高了。

怎么就觉得自己越讲越迷糊了, 看来还是例子举得不好啊。 哈哈

根据Bridge模式的定义和概念图,应该是如下所示的:

根据《设计模式解析》的例子, 它是形状和绘图两种对象,然后把绘图对联作为形状对象的一个包含对象, 用聚集来解决的这个问题。 把聚集关系作为桥梁吧,我是这么理解的。

我举得例子可能不太恰当, 貌似用抽象工厂模式也可以解决, 或许可能会更加合适。

ok,来看一看Bridge模式的关键特征:

意图:将一组实现与另一组使用它们的对象分离。 (看这个意思的话,两组之间是使用关系,跟抽象和实现两者的关系貌似不太符合)

问题:一个抽象类的派生类必须使用多个市县, 但不能出现类数量爆炸性增长。

解决方案:为所有实现定义一个接口,仅供抽象类的所有派生类使用。

参与者与协作者:抽象类为要实现的对象定义接口, 接口类为具体实现类定义接口, 抽象类的派生类使用接口类的派生类, 但不需要知道自己具体使用哪一个接口派生类。(跟抽象工厂方法类似)

效果:实现与使用实现的对象解耦, 提供了可扩展性(这点是的,抽象工厂的扩展性不如桥接模式好), 客户对象无需操心实现问题。

实现:1:将实现封装在一个抽象类中。2:在要实现的抽象的基类中包含一个实现的句柄。

注意:在java中可以在实现中用接口代替抽象类。

下面是《设计模式解析》中给出的Bridge模式的一般结构图:

最后说几个概念吧

1:“一条规则, 实现一次”;

2:“重构”;

3:“找到变化并封装之”;

4:“优先使用对象聚集而不是类继承”;

生活上的事还是不在这里说了。 还是等空了写一封放在阿狸童话里吧。

路漫漫, 加油。

blog comments powered by Disqus