什么是外墙类的好名字？

Question

一点背景：我们正在建立一个用于处理科学模型的图书馆/框架。我们有一个接口Model，它定义了模型必须实现的操作，这是非常小的。也就是说：Model接口从模型实现者的角度定义模型的契约。

该框架在模型周围添加了许多其他功能，但是现在客户端代码必须通过使用一堆其他类来访问该功能，例如ModelInfo，ModelHost，{{1等等。

在我们使用此框架的应用程序中，我们不希望实际上必须处理运行模型的所有这些机制等。所以我们决定使用façade pattern来包装框架功能在一个易于使用的对象。 （我们已经将这种模式应用到框架的其他部分，并取得了很好的成功。）

这是一个问题：假设我们已经有了一个接口ModelInstance，什么是façade类的好名字？ Model接口是两者之间的契约框架和模型实现，新类将定义框架与客户端应用程序之间的契约。

或者，更一般地说：当我们有一个库或框架提供的抽象时，我们如何命名抽象的“双方”，以便清楚地识别“提供者”和“消费者”接口。抽象？

（如果重要的是，对于这个项目，我们使用的是Java 6。）

Answer 1

我知道这看起来很陈腐，但是......你考虑过使用“ModelFacade”作为门面类的类名吗？我认为使用文档表明接口已经命名为Model，它看起来相对简单，并且非常清楚你正在使用哪种设计模式。

Answer 2

* Provider和* Consumer怎么样？我想你在问题中自己说过了。也许*制作人和*消费者是更好的匹配？

Answer 3

在我们团队的讨论中，我们提出了另一个选项：我们可以将现有的Model界面重命名为其他内容，只需调用新的façadeModel即可。实际上，它们现在都可以被称为Model，因为它们将存在于单独的包中。 （虽然我不喜欢不同名称空间中同名的类。）

Answer 4

PureMVC使用名为ApplicationFacade的单身，并使用registerProxy

中定义的IFacade等方法注册所有模型

Answer 5

ModelInfo，ModelHost和ModelInstance之类的声音都应该是Model的成员。

请参见https://softwareengineering.stackexchange.com/questions/316840/is-it-bad-practice-to-name-a-class-with-a-facade-suffix，了解为什么通常不应该使用所使用的特定实现来命名类。基本上，有一天您可能想使用Model的不同实现，而该实现恰好不是外观。