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

[[374350]]

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