我是Design Patterns的新手,正在尝试了解它们的外观。现在我正在尝试了解Facade模式。我觉得Facade Pattern是一个相当广泛的概念,所以我想知道我的第二张图是否会被视为Facade Template的一部分。
我知道一个典型的Facade Pattern基本上看起来像这样(A-class是外观):
但如果我们有一个更加微妙的图表怎么办:
A级仍然会被视为Facade级别还是依赖于上下文?
答案 0 :(得分:2)
首先,要了解外观,我喜欢将其视为一种重构。想象一下你的图没有外观类。客户端必须直接与Facade管理的所有类进行交互。因此,它们会更复杂,耦合更多。
Facade为客户端提供简化的服务(减少耦合),隐藏背后的复杂性。
我最喜欢的例子(在Java中)是JOptionPane
类。它在最早的Java版本中不存在,如果你想创建一个Yes / No问题对话框,你(作为一个客户端)必须管理对Dialog,Button等的所有调用以及处理事件,所有这些复杂性已经简化为JOptionPane
facade类中的静态方法。这是来自https://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html
现在回答你的问题:
A级仍然会被视为Facade级别还是依赖于上下文?
如果A
为有效使用B
,C
,F
和E
的复杂子系统的客户提供简化服务,客户端必须直接与所有这些客户进行交互(然后联系),然后我会说A
是一个门面。
答案 1 :(得分:0)
当然,使用复合设计模式时有一个例外,但通常特别是在你的情况下,facade类不会改变。此外,可以随时添加新的依赖项。希望这会有所帮助。
答案 2 :(得分:0)
我想说这取决于上下文。
如果您是设计模式的新手,而不是描述设计模式的real life stories,可以帮助您加快学习/理解主题。
答案 3 :(得分:0)
是的,A
类在第二个示例中与第一个示例中的Façade一样,只要A
是客户端和“子系统”之间的唯一入口点。隐藏的子系统是扁平的还是分层的对于客户或实际上对于模式而言并不重要。
请注意,外观的感知效用与客户提取(隐藏)的复杂程度有些成正比。所以第一个例子可能被认为是一个更有用的Façade,因为它隐藏了另外四个类。第二个示例仅隐藏来自客户端的两个类,假设在没有B
的情况下它们仅与C
和A
进行交互。