如何理解設計模式之橋模式

本篇內容介紹了“如何理解設計模式之橋模式”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

舉個例子

橋模式的主要功能也是解耦，把會獨立變化的量從整個邏輯中抽離出來，從而節省我們的代碼量。我們用奶茶來舉個簡單的例子。

對于奶茶而言，它的原料往往比較簡單，就是糖、水、茶以及奶蓋等等。但是制作過程往往大相徑庭，珍珠奶茶可能就只是把茶和奶混合加上珍珠，其他的奶茶可能完全不同。

假如我們希望用程序來模擬奶茶制作的整個過程，我們會發現如果我們對每一種奶茶都單獨實現一個類是非常麻煩的。因為不同奶茶往往只是制作手法有差別，但是整體的原料以及流程可能都是一樣的。所以我們只希望可以單獨抽離出制作過程即可，這個時候我們就可以使用橋接模式，說穿了其實非常簡單，尤其是在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中的實現簡單多了。

“如何理解設計模式之橋模式”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！