Question

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

在只有一个实现（一对一）的情况下，创建一个抽象的实现者类是没有必要的。这是一个退化的案例桥梁模式;两者之间有一对一的关系抽象和实施者。尽管如此，这种分离仍然存在当类的实现中的更改不得影响时有用它现有的客户 - 他们不应该这样做重新编译，只是重新链接。

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

例如，如果我们有X扩展Y和客户端做：

Y y = new X();

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

使用Bridge Pattern时完全相同：

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

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

所以，根据我的说法，这种好处不会发生在Java和一对一=＆gt;不需要桥模式。

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

你有什么看法？

Answer 1

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

您描述的Bridge模式的优点取决于从Abstract的客户端隐藏Implementor的接口。在C ++中，您可以通过简单地不提供头文件来轻松隐藏Implementor的界面。在Java中，您可以使Implementor成为包含私有成员的抽象类。

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

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

因此，为了直接回答您的问题：在Java中，Bridge模式确实具有问题中描述的优势。如果你算上没有重新发生的事实，可能会更大程度上。

Answer 2

Java没有像C / C ++那样“链接”。但是，我认为这个概念仍然适用：如果实现类在抽象的单独库（.jar文件）中，那么您不必重新打包包含抽象的.jar文件。这可以简化复杂系统的维护。

桥模式 - Java编译的好处？

2 个答案: