设计模式与泡mm的关系之Bridge桥接模式及桥接模式的再思考

我跑我跑我跑

7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我"早上碰到MM新做了个发型怎么说"这种问题，自己用BRIDGE组合一下不就行了。

桥梁模式：将抽象化与实现化解耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。

点评：

感觉这个例子举的不是很好的哦。他这样子为什么用Bridge模式呢？这里的变化存在于不同情况下说不同的话，以及这些不同情况存在着组合的情况。当然了，如果非要用Bridge实现的话也是可以的哦。但是我不知道这样做是否是最好的。

ConcreteImp是具体情况下的mm，比如穿了件新衣服的mm或者做了新发型的mm之类的或者是做了头发穿了新衣服的mm。我是abstraction，我要对mm说上面的那些话。但是一开始由于我比较木，不知道mm这么善变，我只考虑到mm只会有一样变化（比如说做了头发就不穿新衣服了之类的，好像有点牵强）。这个时候，如果mm既做了头发又穿了新衣服的话，我说话的那个operation函数显然就不行了。所以，我就只能通过继承重新实现一下operation这个函数了，就下子就有了RefinedAbstraction了。

这个例子感觉怪怪的。我觉得好像有点不合适。如果不用bridge模式的话，那我会用什么模式呢？这里的变化是，有不同style的mm，然后我要根据具体style的mm来说不同的话。首先能够抽象出来的就是interface mm了，以及concrete mm，mm有一个style属性。这样子的话，我们就可以非常容易的创建一个特殊style的mm了。我只要用一个简单的Factory Method模式就解决了哦。讲到这里，突然发现Bridge模式的一个非常关键的就是refined abstraction。如果在这个例子中我们突出了一个"早上碰到MM新做了个发型怎么说"这种问题，那么用bridge模式还是挺自然的。恩。关键就是abstraction和implementor要独立地变化。也就是说如果class factory要变化的话，我就可以用bridge模式了。Over。