带有状态的立面设计模式答案

【问题标题】：Facade design pattern with states带有状态的立面设计模式
【发布时间】：2023-03-04 12:09:01
【问题描述】：

在实现了一个门面来隐藏一些复杂的子系统之后，我们最终得到了一个用于客户端的类。但问题是这个单一的类仍然有超过 100 个 API。这似乎违反了内聚原则。外观类还管理状态，以便可以隐藏子系统之间使用的对象。该系统由子系统（例如项目、策略、用户、权限等）组成，我认为我们可能能够以更模块化的方式设计外观。在这种情况下，有哪些设计模式可以很好地与外观配合使用？

【问题讨论】：

“但问题是这个类仍然有超过 100 个 API。” - 你的意思是“有超过 100 种方法”？
是的。由于所有方法都是面向客户端的，所以我使用了 API。

标签： .net oop design-patterns

【解决方案1】：

正如您已经说过的，在一个类中拥有 100 多个 API 并不是一个好主意。它们可以分为不同的外观类。通用功能可以移动到基类。这不是设计模式，而是 OO 的核心。状态仍可维持。我不确定您是否已经在使用会话作为存储来保存状态。如果是这样，您仍然可以继续这样做。

您还可以使用缓存来存储状态或使用数据库。如果您使用的是 EJB，那么 SFSB 会提供此功能。

【讨论】：

我没有足够的 .NET 专业知识来评论它的使用。

【解决方案2】：

如果我们遵循领域驱动设计的原则，那么您可以将您的系统分为无状态服务和有状态实体。将服务和状态机组合在一个外观中不一定是一个好主意。

顺便说一句，在我看来，使用外观几乎就像将过程编程强制到面向对象的语言上一样。外观只是一组函数，就像非 OOP 语言中的模块一样。所以通常我在使用 OOP 时尽量避免使用外观，尽管务实是好的。

【讨论】：

好点。外观在这里用于一些常见的用例。不是通用的编程接口，所以我们从外观开始简化系统。