所有的 Front Classes 都应该使用单例吗？

Question

考虑 Martin Fowler 的企业应用架构模式和前端控制器模式：http://martinfowler.com/eaaCatalog/frontController.html 显然，它使用单例模式。好吧，我在 php 应用程序中有一个类包，它们可以一起工作（如 Zend 的控制器包），并且有一个类使它们都可用，因为它类似于 Front Controller 的大部分概念，所以我将它命名为 PackageName_Front。但它不应该是一个单例类（与 Front Controller 相对），所以我仍然让它有 Front 这个名字吗？如果不是，我给它取什么名字？ 由于它是一个相当大的包，我只需要它尽可能地遵循约定（不是以教条的方式！）以便其他开发人员可以阅读。

更多信息：它与控制器无关。它只是一个像 Zend_Form 一样工作的对象（它将 Zend_Form_Element_X 和 Zend_Validate 等所有其他对象的使用合并到一个对象中）但我不能只将其命名为 PackageName。它必须是PackageName_Something，我只是不知道Something应该是什么。也许是“处理程序”？...我只是想确保当有人读到它的名字时，不会对它在整个包中的作用感到困惑 :)

Answer 1

显然，它[FrontController]使用了单例模式。

FrontController 不必实现为 Singleton。这本书没有提出这样的建议。书中的示例使用 Servlet 作为 Handler。

仅仅因为一个类在应用程序中只需要一次并不能证明它作为单例实现是合理的。它缺少单例的目的，即强制一个类只能有一个实例并且提供对它的全局访问。如果您只需要一次特定实例，请考虑使用Just Create One。

现在很多人（包括 GoF 名气的 Erich Gamma）都将 Singleton 视为代码异味，不鼓励使用它。在 shared-nothing-architecture 中，Singleton 无论如何只能限制当前请求中的实例，因此在 PHP 中的使用是有限的。可以通过（邪恶的）全局关键字或静态方法在没有单例模式的情况下实现对对象的全局访问。全局访问总是会产生不必要的耦合。更好的方法是使用依赖注入，它的额外好处是提供更少的耦合，从而提供更好的可维护性。

所以我仍然让它有名称 Front 吗？如果不是，我给它取什么名字？由于它是一个相当大的包，我只需要它尽可能地遵循约定（不是以教条的方式！）

据我所知，关于命名类Front 类没有这样的约定。不过，您所描述的可能是Facade 或Gateway。另外，您确定不能在 PackageName 之后命名该类吗？毕竟Zend_Form 包也有一个Zend_Form 类。

Answer 2

仅从纯粹的设计角度来看，当您说：

有一个类可以使它们全部 可用

Fowler 对该模式的实现说：

前端控制器整合了所有 通过通道处理请求 通过单个处理程序请求 对象

这暗示 Singleton 可能用于实现 Front Controller 类，但它肯定不会限制它使用它。不过他没有明确提及。

我认为它是否是单例并不重要。只要确保它是请求的唯一渠道，您就会成功使用该模式。 :)

Answer 3

单例模式背后的想法是确保只有一个对象的一个​​实例应该只存在于一个实例中。前端控制器很好地属于这一类，所以让它遵循单例模式可能是明智的。

但是，如果您的代码始终确保它只调用一次构造函数，那么您的非单例模式对象就有空间了。

我的 2 美分在这里，因为我不是任何书籍作者或什么的。