设计模式——理解外观模式
Design Patterns - Understanding Facade Pattern
我是设计模式的新手，正在尝试了解它们通常是什么样子的。现在我正在尝试理解外观模式。我觉得 Facade 模式是一个相当宽泛的概念，所以我想知道我的第二张图是否会被视为 Facade 模板的一部分。
我知道一个典型的外观模式基本上是这样的（A-class 是外观）：
但是如果我们有一个像这样更微妙的图表呢：
A-class 仍会被视为 Facade-class 还是取决于上下文？
当然，使用复合设计模式时会有例外，但通常情况下，尤其是在您的情况下，外观 class 不会改变。此外，可以随时添加新的依赖项。希望这有帮助。
我会说这取决于上下文。
如果您是设计模式的新手，那么描述设计模式的 real life stories 可以帮助您加快 learning/understand 主题。
是的，A class 在第二个示例中和在第一个示例中一样是 Façade，因为 A 是客户端和 "subsystem"。隐藏子系统是扁平的还是分层的对于客户端或者实际上对于模式来说并不重要。
请注意，Façade 的感知效用与它从客户端抽象（隐藏）的复杂性在某种程度上成正比。因此，第一个示例可能被认为是更有用的 Façade，因为它隐藏了四个额外的 classes。第二个例子只对客户端隐藏了两个 classes，假设他们在没有 A.
的情况下只会与 B 和 C 交互
首先，要理解外观，我喜欢将其视为一种重构。想象一下，您的两个图表 都没有 外观 class。客户端必须直接与外观管理的所有 classes 交互。因此，它们会更复杂，耦合度更高。
外观为客户端提供简化的服务（减少耦合），隐藏外观背后的复杂性。
我最喜欢的例子（在 Java 中）是 JOptionPane class。它在 Java 的最早版本中不存在，如果您想创建一个 Yes/No 问题对话框，您（作为客户端）必须管理对 Dialog、Button 等的所有调用，因为以及处理事件等。所有这些复杂性都已简化为 JOptionPane 门面 class 内的静态方法。这是来自 https://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html
的 UML 图
现在回答你的问题：
Would the A-class still be considered a Facade-class or does it depend on the context?
如果 A 正在为有效使用 B、C、F 和 E 的复杂子系统的客户提供简化服务，没有它，客户端将不得不直接与所有这些交互（耦合到），那么我会说 A 是一个门面。
我是设计模式的新手，正在尝试了解它们通常是什么样子的。现在我正在尝试理解外观模式。我觉得 Facade 模式是一个相当宽泛的概念，所以我想知道我的第二张图是否会被视为 Facade 模板的一部分。
我知道一个典型的外观模式基本上是这样的（A-class 是外观）：
但是如果我们有一个像这样更微妙的图表呢：
A-class 仍会被视为 Facade-class 还是取决于上下文？
当然，使用复合设计模式时会有例外，但通常情况下，尤其是在您的情况下，外观 class 不会改变。此外，可以随时添加新的依赖项。希望这有帮助。
我会说这取决于上下文。
如果您是设计模式的新手，那么描述设计模式的 real life stories 可以帮助您加快 learning/understand 主题。
是的，A class 在第二个示例中和在第一个示例中一样是 Façade，因为 A 是客户端和 "subsystem"。隐藏子系统是扁平的还是分层的对于客户端或者实际上对于模式来说并不重要。
请注意，Façade 的感知效用与它从客户端抽象（隐藏）的复杂性在某种程度上成正比。因此，第一个示例可能被认为是更有用的 Façade，因为它隐藏了四个额外的 classes。第二个例子只对客户端隐藏了两个 classes，假设他们在没有 A.
B 和 C 交互
首先，要理解外观，我喜欢将其视为一种重构。想象一下，您的两个图表 都没有 外观 class。客户端必须直接与外观管理的所有 classes 交互。因此，它们会更复杂，耦合度更高。
外观为客户端提供简化的服务（减少耦合），隐藏外观背后的复杂性。
我最喜欢的例子（在 Java 中）是 JOptionPane class。它在 Java 的最早版本中不存在，如果您想创建一个 Yes/No 问题对话框，您（作为客户端）必须管理对 Dialog、Button 等的所有调用，因为以及处理事件等。所有这些复杂性都已简化为 JOptionPane 门面 class 内的静态方法。这是来自 https://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html
现在回答你的问题：
Would the A-class still be considered a Facade-class or does it depend on the context?
如果 A 正在为有效使用 B、C、F 和 E 的复杂子系统的客户提供简化服务，没有它，客户端将不得不直接与所有这些交互（耦合到），那么我会说 A 是一个门面。