C# 立面设计模式的使用

在我们的应用程序（C#）中，facade被用作核心的API——facade将被应用程序本身用来处理核心。知道这一点，我的问题如下：

假设我的一个核心对象（facade包装）中有一个递归位？例如，facade从树中提供了一个“GetX”，每个节点都需要从其子树中获取x。这个节点应该使用facade的“GetX”吗

门面是否应该向应用程序公开核心对象？例如，用户希望构建一棵树、添加节点、打印树、计算树上的内容等。应用程序应该使用树对象，还是应该要求facade创建树对象、保存树对象、撬动树对象等

谢谢

facade是一个对象，它为更大的应用程序提供了一个简化的接口 代码体

因此，保持简单

不。将立面封装在其内部。我假设您有一个用于检索树的私有实现，在内部使用它，只公开返回填充对象的public方法（参见第2点）

不。立面应该做所有的事情，否则创建它就没有什么意义了。您可能希望创建一个可以在facade方法中使用的DTO，但不应该公开核心对象

---

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

为了保持一致性，您可能希望这样做，但是如果有另一种更简单的方法来保存facade提供的抽象，那就更好了

如果您想添加一些功能，那么就不应该公开任何核心代码（这与facade的目的背道而驰），然后向facade添加一个函数，该函数将调用facade中的核心函数

---

关于问题1: 正如其他人所说；不是，而是考虑为这个操作使用一个单独的接口（这里可能适用），并且首先通过FACIDE访问该接口上的操作。递归后，可以直接再次使用内部接口。这可能会提供一些关注点分离，同时也使以后在必要时更容易更改实现

在我看来，递归本身似乎是一个实现细节，而不是facade需要了解的东西。类似地，facade是实现算法不需要知道的东西（即，不要通过facade重复出现）

---

关于问题2:如何定义该问题的接口？例如，

ITree

，

ITreeNode

等，并包括在门面上使用这些的操作。现在，让实现实现这些接口，从而在不暴露核心对象的情况下，在外观外部提供所需的对象

二,。HeadFirst提到外观简化了，但仍然让用户可以访问内部细节。如果我必须按外观做所有事情，我不会得到一个类似C的代码吗？例如：创建树、添加节点、打印树、将树转换为XML等。？如果我要公开树（通过创建它），用户难道不能使用它的功能吗。如果你想了解细节，你可能不需要门面。只是引用。我在想，我们应该包装我们的核心，这样它就不会与我们的应用程序层耦合（我们可能也必须向其他应用程序提供该核心）。我的想法是，我们应该有一些API来提供诸如“get tree”之类的功能，并返回一个应用程序可以使用的树。你能解释一下这个概念的错误吗？