如何理解设计模式之桥模式

本篇内容介绍了“如何理解设计模式之桥模式”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

举个例子

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

对于奶茶而言，它的原料往往比较简单，就是糖、水、茶以及奶盖等等。但是制作过程往往大相径庭，珍珠奶茶可能就只是把茶和奶混合加上珍珠，其他的奶茶可能完全不同。

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

“如何理解设计模式之桥模式”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注编程网网站，小编将为大家输出更多高质量的实用文章！