门面设计模式与国家

Question

在实现Facade以隐藏一些复杂的子系统之后，我们最终为客户端提供了一个类。但问题是这个单一类仍然有超过100个API。这似乎是反对凝聚力的原则。 facade类还管理状态，以便隐藏子系统中使用的对象。该系统由子系统（例如项目，政策，用户，权限等）组成，我认为我们可以以更模块化的方式设计外观。在这种情况下，任何可以与外观配合良好的设计模式？

Answer 1

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

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

Answer 2

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

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