design-patterns - 桥接模式的上桥下桥变化

Question

有人可以解释使用“桥接”模式的“桥接”和“桥接”方法之间的区别吗？可能，我就是想不通。为了清楚起见，我在说什么，看看这本书的解释部分

Answer 1

对于 StackOverflow 来说，这可能不是一个很好的问题，但由于我是您参考的这本书的技术编辑，所以我觉得我应该在这里努力。

首先让我们总结一下问题。

我们有一些提供服务的代码——称之为OriginalService，我们有一些使用服务的代码——称之为客户端。我们希望以这样的方式第二次实施该服务，即客户端可以以同等便利的方式与OriginalService和NewService进行对话。

毕晓普教授正在区分两种情况。在“桥接”场景中，您有一个现有的OriginalService和一个直接与之对话的Client ；为了添加第二个服务，您必须对服务进行抽象。在“桥接”场景中，您知道当您设计原始服务时，客户将需要与该服务的多个版本通信，并从一开始就在抽象层中进行设计。

例如考虑视频驱动程序的问题。如果您的操作系统（客户端）知道如何与一个视频卡（原始服务）进行通信，那么该操作系统不太可能非常流行。相反，操作系统与驱动程序对话。每个显卡制造商都为其支持的操作系统制作驱动程序，现在操作系统可以与许多驱动程序通信。驱动程序在操作系统和显卡之间“架起一座桥梁”。

如果您从一个只知道如何与一种视频卡通信的操作系统开始，然后在此基础上改装一个驱动程序系统，那么您就处于“桥接”场景中。

如果您从第一天开始就意识到您将需要对硬件进行抽象并立即开始构建基于驱动程序的架构，那么您就处于“桥接”场景中。