设计模式，一看就懂的桥模式，解耦可变量与主体逻辑

 大家好，设计今天给大家介绍一种新的模式模式设计模式——bridge模式，即桥模式。看懂可变

举个例子

桥模式的解耦辑主要功能也是解耦，把会独立变化的量主量从整个逻辑中抽离出来，从而节省我们的体逻代码量。我们用奶茶来举个简单的设计例子。

对于奶茶而言，模式模式它的看懂可变原料往往比较简单，就是解耦辑糖、水、量主茶以及奶盖等等。体逻但是设计制作过程往往大相径庭，珍珠奶茶可能就只是模式模式把茶和奶混合加上珍珠，其他的看懂可变奶茶可能完全不同。

假如我们希望用程序来模拟奶茶制作的整个过程，我们会发现如果我们对每一种奶茶都单独实现一个类是非常麻烦的。因为不同奶茶往往只是制作手法有差别，但是云服务器整体的原料以及流程可能都是一样的。所以我们只希望可以单独抽离出制作过程即可，这个时候我们就可以使用桥接模式，说穿了其实非常简单，尤其是在Python当中。

代码实现

这里我们先放出奶茶这个类主体的逻辑，大家估计一看就明白了。

class BubbleTea:     def __init__(self, ice, sugar, tea, cheese, making_api):         self._ice = ice         self._sugar = sugar         self._tea = tea         self._cheese = cheese         self._making_api = making_api     def no_ice(self):         self._ice = 0     def additional_sugar(self):         self._sugar += 5     def additional_cheese(self):         self._cheese += 5     def prepare(self):         self._making_api.make(self._ice, self._sugar, self._tea, self._cheese) 

这里的ice、sugar、tea和cheese都是我们日常奶茶当中都会添加的原料，对于奶茶的制作我们往往也会提一些加芝士、去冰以及加糖这些要求，我们也把它们做成了单独的方法，这些也都很好理解。

这里唯一有些需要注意的就是对于奶茶的制作过程，也就是prepare这个方法，其实并不是在BubbleTea这个类当中实现的，源码库而是通过making_api从外界传来的。这里也就是我们bridge模式的应用了，既然处理逻辑是外界传来的，那么它其实就和奶茶这个类解耦了，我们可以在外面自己随意定义这个api的实现方式，也不会有任何影响。如果我们要在BubbleTea这个类内部来实现奶茶的话，要么我们对每一种奶茶实现一个类，要么我们在其中做大量的判断，无论是哪一种情况显然都不太好，会导致代码大量的堆积和臃肿。

最后我们看一下making_api的实现，以及使用示例：

class CheeseTeaAPI:     def make(self, ice, sugar, tea, cheese):         print(cheese tea! cheese: { }, bubbles: 5, sugar: { }, tea: { }, ice: { }.format(cheese, sugar, tea, ice)) class BubbleTeaAPI:     def make(self, ice, sugar, tea, cheese):         print(bubble tea! sugar: { }, tea: { }, ice: { }.format(sugar, tea, ice)) if __name__ == __main__:     teas = [BubbleTea(0, 5, 3, 0, BubbleTeaAPI()), BubbleTea(2, 5, 2, 4, CheeseTeaAPI())]     for tea in teas:         tea.no_ice()         tea.additional_sugar()         tea.prepare() 

如果大家还有困惑的话，不妨再看下代码细节，仔细思考一下。整体来说，bridge模式在Python当中的实现还是比较简单的，站群服务器最起码比在Java中的实现简单多了。

本文转载自微信公众号「TechFlow」，可以通过以下二维码关注。转载本文请联系TechFlow公众号。