大家好，今天给大家介绍一种新的设计模式——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公众号。
