在OOD中转换层次结构的接口答案

【问题标题】：Converting the interfaces in hierarchical structure in OOD在OOD中转换层次结构的接口
【发布时间】：2018-07-30 00:24:16
【问题描述】：

我对@987654323@ 设计模式有疑问。当我开始从这本书中学习设计模式时：Elements of re-useable object-oriented-software，对它是什么以及它如何解决问题进行了很好的解释。

这张图片来自那本书：

问题： 假设我在Domain 是Facade/interface 的子系统中添加了一些额外的功能。有了这种设计，我认为不可能在不更改Domain 类的情况下在子系统中添加额外的功能？

其次，假设我使用抽象类Domain（创建层次结构）并将所有请求委托给它的子类，这样每当我想添加新功能时，我只需使用@987654328 扩展我的新类/子系统@，这是错误的还是我仍然会有一个Facade 结构？

Adapter 模式中也发生了同样的事情。我们可以有不同种类的适配器，而不是硬编码一个类，我们可以在不违反任何 OOD 规则的情况下创建这样的层次结构吗？

【问题讨论】：

标签： oop design-patterns object-oriented-analysis

【解决方案1】：

外观和适配器设计模式是所谓的“包装器”模式（以及装饰器和代理）的一部分。它们本质上包装了某些功能并提供了不同的界面。他们的区别在于他们的意图：

facade：用于为客户端提供一个简单的接口，隐藏其背后提供的操作的复杂性
适配器：允许两个不兼容的接口在不改变其内部结构的情况下协同工作
装饰器：允许将新功能静态或动态添加到对象，而不会影响同一类对象的行为
代理：一个类（代理）用于表示并允许访问另一个类的功能

如果您的组件“在后面”添加了新功能，并且您希望外观公开此功能，则必须调整外观才能这样做。

如果您将 Domain 类（您的场景中的外观）作为其他人扩展的抽象类，则您没有外观，您拥有使用您的类创建的任何继承。简单地说，没有“包装”来实现外观模式的意图。

【讨论】：

【解决方案2】：

通过这种设计，我认为不可能在不更改 Domain 类的情况下在子系统中添加额外的功能？

没错。但是，您所做的更改可能（或可能不会）影响客户端 (Process) 类。如果您将 new 方法添加到 Façade，它不会破坏“旧”客户端。虽然这不是它的明确意图（隐藏子系统的复杂性），但 Façade 可以为其客户端提供一个可以扩展的稳定接口。当我说 interface 时，我并不是指 Java 或 C# 接口。这是一个编程接口。

一个真实的例子是 Java/Swing 中的JOptionPane Façade。检查我放置的链接中的 Java 文档，您会发现它的一些方法存在于 1.4 中，一些存在于 1.6 中，等等。基本上，由于这个类是 Swing 库的一部分，它必须保持稳定，所以老客户它的界面不会损坏。但它仍然扩展通过简单地添加新方法来增加新功能。

我会说这就是外墙的典型扩展方式，而不是子类或层次结构。层次结构很难维护，因为它们很脆弱。如果抽象错误（层次结构的根），那么当您需要更改它时，它会影响整个树。当层次结构中的抽象是稳定的（确定）时，层次结构才有意义。

适配器模式具有层次结构，因为适配器采用一种方法来处理无法更改的服务的多个变体。您可以在https://stackoverflow.com/a/13323703/1168342 看到几个稳定（抽象）服务的示例，例如税收计算、会计服务、信用授权等。

【讨论】：