一点背景：我们正在建立一个与科学模型合作的图书馆/框架。我们有一个接口Model，它定义了模型必须实现的操作，这是非常小的。即：Model接口从模型实现者的角度定义模型的契约。
该框架在模型周围添加了许多其他功能，但是现在客户端代码必须通过使用一堆其他类来访问该功能，例如ModelInfo，ModelHost，ModelInstance等。
在我们使用这个框架的应用程序中，我们不希望实际上必须处理运行模型的所有这些机制等。所以我们决定使用façade pattern以易于使用的方式包装框架功能宾语。 （我们已经将这种模式应用到框架的其他部分，并取得了很好的成功。）
这是一个问题：鉴于我们已经有了一个接口Model，那么façade类的名字是什么？ Model接口是框架和模型实现之间的契约，新类将定义框架和客户端应用程序之间的契约。
或者，更一般地说：当我们有一个库或框架提供的抽象时，我们如何命名抽象的“双方”，以便清楚地识别抽象的“提供者”和“消费者”接口？
（如果重要的话，对于这个项目，我们使用Java 6.）
我知道这看起来很陈旧，但是......你考虑过使用“ModelFacade”作为门面类的类名吗？我认为使用文档表明接口已经命名为Model，它看起来相对简单，并且非常清楚你正在使用哪种设计模式。
*提供商和*消费者怎么样？我想你在问题中自己说过了。也许*制作人和*消费者是更好的匹配？
在我们团队的讨论中，提出了另一种选择：我们可以将现有的Model界面重命名为其他东西，然后调用新的façadeModel。事实上，他们现在都可以被称为Model，因为他们将生活在不同的包中。 （虽然我不是不同名称空间中同名类的粉丝。）
PureMVC使用名为ApplicationFacade的单例并使用registerProxy中定义的IFacade等方法注册所有模型
听起来像ModelInfo，ModelHost和ModelInstance都应该是Model的成员。
请参阅https://softwareengineering.stackexchange.com/questions/316840/is-it-bad-practice-to-name-a-class-with-a-facade-suffix，了解为何您通常不应使用所使用的特定实现来命名类。基本上，有一天你可能想要使用不同的Model实现，这恰好不是一个外观。