桥模式 - Java编译的好处？

Question

在设计模式 - 可重用面向对象软件的元素书中说:

在只有一个实现(一对一)的情况下,创建一个抽象的实现者类是没有必要的.这是桥模式的退化情况; Abstraction和Implementor之间存在一对一的关系.然而,当类的实现中的更改不得影响其现有客户端时,这种分离仍然有用 - 即它们不应该被重新编译,只需重新链接.

我对编译时间的好处表示怀疑,因为我无法想象Java中的一个案例,即实现中的更改会重新编译其超类(在本例中为abstract).

例如,如果我们有X扩展Y并且客户端执行:

Y y = new X();  

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

使用Bridge Pattern时完全相同:

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

XImplementor中的更改并不意味着重新编译YAbstraction.

因此,根据我的说法,这种好处不会发生在Java中,并且需要一对一=>无桥模式.

也许子类强制超类的更改要在其他语言中重新编译？喜欢SmallTalk和C++？

你有什么看法？

Answer 1

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

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

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

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

因此，为您的问题提供直接答案：在 Java 中，桥接模式也确实具有问题中描述的优点。如果您考虑到从未发生过重新链接的事实，那么可能会更大。