java - 桥接模式——用 Java 编译的好处？

Question

Design Patterns - Elements of Reusable Object-Oriented Software一书中说:

In situations where there's only one implementation (one-to-one) ,creating an abstract implementor class isn't necessary.This is a degenerate case of the bridge pattern; there's a one-to-one relationship between Abstraction and Implementor.Nevertheless,this seperation is still useful when a change in the implementation of a class must not affect its existing clients- that is they shouldn't have to be recompiled,just relinked.

我怀疑编译时间的好处，因为我无法想象在 Java 中实现的更改会导致重新编译其父类(super class)(在本例中为抽象类)的情况。

例如，如果我们有 X extends Y 并且客户端执行:

Y y = new X();  

X 的改变并不意味着 Y 的重新编译(当然如果我们不想改变 X 的方法签名)

使用桥接模式时完全一样:

YAbstraction yabstraction = new YRefinedAbstraction(new XImplementor());

XImplementor 的改变并不意味着 YAbstraction 的重新编译。

因此，根据我的说法，这种好处不会出现在 Java 中，并且对于一对一 => 不需要桥接模式。

也许子类中的更改强制父类(super class)以其他语言重新编译？比如 SmallTalk 和 C++？

你有什么看法？

Answer 1

在桥接模式中，您有两个类层次结构:一个用于抽象(例如，具有派生类的窗口，如 DialogWindow 和 IconWindow)，一个用于实现器(例如，具有派生类的 WindowImpl，如 XWindowImpl 和 PMWindowImpl)。实现者的接口(interface)应该对抽象的客户隐藏。通常，实现者提供低级原语，抽象根据这些原语构建更高级别的操作，因此在分层良好的系统中，客户端不需要看到实现者提供的低级接口(interface)。如果有一天，事实证明 WindowImpl 提供的接口(interface)不够通用，无法容纳新的 XYZWindowImpl，您可以保留更改它的自由，因为 WindowImpl 永远不应由您的客户直接使用，而只能由 Window 及其子类使用。因此，WindowImpl 接口(interface)的变化可能需要对 Window 进行修改，但不会传播到客户端。此外，人们经常将实现者隐藏在用于配置网桥的抽象工厂后面。

您描述的桥接模式的优势取决于对抽象的客户端隐藏实现者的接口(interface)。在 C++ 中，您可以通过简单地不提供头文件来轻松隐藏 Implementor 的接口(interface)。在 Java 中，您可以使 Implementor 成为具有包私有(private)成员的抽象类。

在抽象的 C++ 客户端中，不需要重新编译，只需要重新链接。在 Java 中，不是链接而是类加载，因此您需要做的就是使用新设置和新 jar 文件重新加载应用程序。

想象一下这样一种情况，抽象工厂使用命令行选项或环境变量来配置具有正确类型的 ConcreteImplementor 的桥。在这种情况下，您只需使用新的命令行/环境设置和包含新的 ConcreteImplementor 的新 jar 文件重新加载应用程序。您无需重新编译客户端代码即可执行此操作。

因此直接回答您的问题:同样在 Java 中，Bridge 模式确实具有问题中描述的优势。如果考虑到从未发生过重新链接这一事实，则可能会更大。