外观设计模式的使用答案

【问题标题】：Facade design pattern usage外观设计模式的使用
【发布时间】：2012-08-12 10:49:18
【问题描述】：

在我们的应用程序（C#）中，外观被用作核心的 API - 外观将被应用程序本身用来与核心做一些事情。知道了，下面是我的问题：

假设我的一个核心对象，它的外观包装，有一个递归位？例如，facade 提供了来自树的“GetX”，每个节点都需要从其子树中 GetX。该节点是否应该使用外观的“GetX”？
外观是否应该向应用程序公开核心对象？例如，用户想要构建一棵树、添加节点、打印树、计算树等。应用程序应该使用树对象还是应该请求外观创建、保存、打印等等？李>

谢谢。

【问题讨论】：

【解决方案1】：

Facade 是一个对象，它为更大的对象提供简化的接口代码体。

因此，请保持简单。

【讨论】：

2. HeadFirst 提到外观简化了，但仍然让用户可以访问内部细节。如果我必须在外观上做所有事情，我不会得到类似 C 的代码吗？例如：创建树、添加节点、获取树打印、将树转换为 XML 等？如果我无论如何都要公开树（通过创建它），用户不应该能够使用它的功能吗？
好吧。如果您想访问详细信息，您可能不需要外观。
只是引用。我在想我们应该包装我们的核心，这样它就不会与我们的应用程序层耦合（我们可能也必须将该核心提供给其他应用程序）。我的想法是我们应该有一些 API 来提供诸如“获取树”之类的功能，并返回应用程序可以使用的树。你能解释一下这个概念有什么问题吗？

【解决方案2】：

外观通常包裹您的核心并提供对一组特定功能的访问权限。

【讨论】：

【解决方案3】：

关于问题 1： 正如其他人所说；否。相反，请考虑为此操作使用单独的接口（@987654321@ 可能适用于此？），并首先通过 Facade 访问该接口上的操作。通过递归，内部接口可以直接再次使用。这可能会提供一些关注点分离，同时也可以在必要时更容易地在以后更改实现。

在我看来，递归本身就是一个实现细节，而不是外观需要知道的任何事情。类似地，外观是实现算法不需要知道的东西（即，不要通过外观重复出现）。

关于问题 2：如何也为此定义接口？例如。 ITree、ITreeNode 等，并包含在 Facade 上的操作以使用这些操作。现在让实现实现这些接口，从而在外观之外提供所需的对象，而不会暴露核心对象。

【讨论】：