[[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公眾號。