在 PHP 中是否存在具有数据库访问权限的单例用例？

我看不出这有什么意义。如果你以这样的方式实现这个类，连接字符串被作为构造函数的一个参数，并维护一个 PDO对象列表(每个唯一的连接字符串一个) ，那么可能会有一些好处，但是在这个实例中实现单例似乎是一个毫无意义的练习。

在我看来，你没有错过任何东西。这个例子有很大的缺陷。 如果单例类具有一些非静态实例变量，那么结果会有所不同。

在您的示例中，您处理的是一条看似不变的信息。对于这个例子来说，一个 Singleton 可能有点过了，在类中使用一个静态函数就足够了。

更多的想法: 你可能正在经历一个为了模式而实现模式的案例，而你的直觉告诉你“不，你不必这样做”，因为你已经说明了原因。

但是: 我们不知道您的项目的规模和范围。如果这是一个简单的代码，也许可以扔掉，这是不太可能需要改变，那么是的，继续使用静态成员。但是，如果您认为您的项目可能需要扩展，或者需要为将来的维护编码做准备，那么，是的，您可能需要使用单例模式。

你的解释是正确的。单身人士有他们的位置，但过度使用。通常，访问静态成员函数就足够了(特别是当您不需要以任何方式控制构造时间时)。更好的方法是，只需在名称空间中放入一些自由函数和变量。

编程时没有“对”和“错”，只有“好的实践”和“坏的实践”。

单例通常被创建为一个类，以便以后重用。它们需要以这样的方式创建，即程序员在午夜醉醺醺地编写代码时不会意外地实例化两个实例。

如果有一个简单的小类 不应该被实例化不止一次，那么就不需要使用 需要来使它成为一个单例。这只是一个安全网，如果你这样做。

拥有全局对象并不是 一直都是的坏习惯。如果您知道您将在全球/所有地方/所有时间使用它，那么它可能是为数不多的例外之一。然而，全球化通常被认为是“不良做法”，就像 goto被认为是不良做法一样。

许多人认为单例被认为是 反模式，因为它们实际上只是美化了的全局变量。在实践中，一个类只有一个实例是 有需要的情况相对较少; 通常只有一个实例是 足够，在这种情况下，完全没有必要将其实现为单例。

回答这个问题，你是对的，单身在这里是过度杀戮。一个简单的变量或函数就可以了。然而，一个更好的(更健壮的)方法是使用 依赖注入来完全消除对全局变量的需求。

首先，我想说的是，我并没有发现这种单例模式有多大用处。为什么要在整个应用程序中保留单个对象？特别是对于数据库，如果我想连接到另一个数据库服务器该怎么办？我每次都要断开和重新连接？不管怎样。

在应用程序中使用全局单例模式有以下几个缺点:

• 很难进行单元测试
• 依赖注入问题
• 可以创建锁定问题(多线程应用程序)

使用静态类代替单例实例也提供了一些相同的缺点，因为单例实例的最大问题是静态 getInstance方法。

你可以不使用传统的 getInstance方法来限制一个类的数量:

class Single {


static private $_instance = false;


public function __construct() {
if (self::$_instance)
throw new RuntimeException('An instance of '.__CLASS__.' already exists');


self::$_instance = true;
}


private function __clone() {
throw new RuntimeException('Cannot clone a singleton class');
}


public function __destruct() {
self::$_instance = false;
}


}


$a = new Single;
$b = new Single; // error
$b = clone($a); // error
unset($a);
$b = new Single; // works

这将有助于上面提到的第一点: 单元测试和依赖注入，同时仍然确保类的单个实例存在于您的应用程序中。例如，您可以将生成的对象传递给您的模型(MVC 模式) ，供它们使用。

好吧，我刚开始工作的时候也想过这个问题。用不同的方法实现了它，并提出了两个选择不使用静态类的理由，但这两个理由都很重要。

一个是你会发现，通常情况下，你绝对肯定你不会有多于一个实例的东西，你最终会有第二个。您最终可能会有第二个监视器、第二个数据库、第二个服务器——无论是什么。

当这种情况发生时，如果您使用了静态类，那么与使用了单例相比，您所处的重构要糟糕得多。单例模式本身是一种可疑的模式，但它很容易转换为智能工厂模式——甚至可以转换为使用依赖注入模式，而不会遇到太多麻烦。例如，如果您的单例是通过 getInstance ()获得的，那么您可以很容易地将其更改为 getInstance (database aseName)并允许多个数据库——不需要更改其他代码。

第二个问题是测试(老实说，这和第一个问题是一样的)。有时需要用模拟数据库替换数据库。实际上，这是数据库对象的第二个实例。这在静态类中要比在单例类中困难得多，您只需要模拟 getInstance ()方法，而不是静态类中的每一个方法(在某些语言中这是非常困难的)。

这实际上可以归结为习惯——当人们说“全球化”是不好的，他们有很好的理由这样说，但它可能并不总是显而易见，直到你自己找到了问题所在。

你能做的最好的事情就是询问(就像你做的那样) ，然后做出选择，观察你的决定的后果。拥有解释代码随时间演化的知识要比一开始就正确地进行代码演化重要得多。

简单地考虑一下您的解决方案与 PHP 文档中提供的解决方案有何不同。实际上，只有一个“小”区别: 您的解决方案为 getter 的调用者提供了一个 PDO实例，而文档中的解决方案为 Database::singleton的调用者提供了一个 Database实例(然后他们使用该实例上的 getter 来获得一个 PDO实例)。

那么我们得出了什么结论呢？

• 在文档代码中，调用方获得一个 Database实例。Database类可能公开(实际上，如果您遇到所有这些麻烦，它将公开 应该)一个比它所包装的 PDO对象更丰富或更高级的接口。
• 如果更改实现以返回另一种比 PDO更丰富的类型，那么这两种实现是等价的。遵循手动实现没有任何好处。

在实践方面，Singleton 是一个颇具争议的模式。这主要是因为:

• 它被过度使用了。新手程序员理解 Singleton 要比理解其他模式容易得多。然后，他们继续将他们新发现的知识应用到每一个地方，即使手头的问题没有 Singleton 也能更好地解决(当你拿着锤子时，一切看起来都像钉子)。
• 根据不同的编程语言，以密不透风、不泄漏的方式实现单例可能是一项艰巨的任务(特别是如果我们有高级场景: 一个单例依赖于另一个单例，单例可以被销毁和重新创建，等等)。试着搜索一下“最终的”c + + 单例实现，我敢说(我拥有 Andrei Alexandrescu 开创性的现代 c + + 设计，它记录了很多混乱)。
• 在编写 Singleton 代码和编写访问它的代码时，它都增加了额外的工作负载，这些工作负载不需要遵循对程序变量执行操作的一些自我约束即可完成。

因此，作为最后的结论: 您的单例模式很好。在大多数情况下，完全不使用 Singleton 也是可以的。

单例模式在 PHP 中几乎没有用处——如果不是说没有用处的话。

在对象位于共享内存中的语言中，可以使用单例来降低内存使用。不需要创建两个对象，而是从全局共享应用程序内存中引用现有实例。在 PHP 中没有这样的应用程序内存。在一个请求中创建的单例对应于该请求。在另一个同时完成的请求中创建的 Singleton 仍然是一个完全不同的实例。因此，Singleton 的两个主要目的之一在这里是不适用的。

此外，在应用程序中概念上只存在一次的许多对象不一定需要语言机制来实现这一点。如果 需要只有一个实例，那么 不要实例化另一个。只有当您使用 可能没有其他实例时，例如当您创建第二个实例时，小猫死亡，您才可能拥有一个有效的 Singleton 用例。

另一个目的是在同一个请求中拥有一个实例的全局访问点。虽然这听起来可能是可取的，但实际上并非如此，因为它创建了与全局范围的耦合(就像任何全局变量和静态变量一样)。这使得单元测试更加困难和您的应用程序一般较难维护。有一些方法可以减轻这种情况，但是一般来说，如果您需要在许多类中使用相同的实例，请使用 依赖注入。

有关更多信息，请参见我的 PHP 中的单例——为什么它们不好以及如何从应用程序中消除它们幻灯片。

甚至连单例模式的发明者之一 Erich Gamma也对如今的这种模式表示怀疑:

“我赞成放弃 Singleton。它的用途几乎总是一种设计气味”

进一步阅读

• 在 PHP 中如何测试注册表模式或单例模式？
• 使用 PHP 数据库类作为单例有哪些缺点？
• 基于 PHP PDO 的数据库抽象类设计
• 对于微博客站点来说，单例模式是一个好的设计模式吗？
• 将类修改为封装而不是继承
• 如何从另一个类访问一个对象？
• 为什么单件在 PHP 中没有用处
• 清洁代码对话-单例与全球状态

如果在上述情况之后，你仍然需要帮助来决定:

在 PHP 中谁需要单例？

请注意，几乎所有反对单例模式的理由都来自技术层面——但是它们的范围也非常有限。特别是 PHP。首先，我将列出一些使用单例的理由，然后我将分析使用单例的反对意见。首先，需要它们的人:

编写大型框架/代码库的人，将在许多不同的环境中使用，将不得不使用以前存在的，不同的框架/代码库，必须实现许多不同的，不断变化的，甚至是来自客户/老板/管理层/单位领导的异想天开的请求。

单例模式是自我包容的。这样做之后，单例类在包含它的任何代码中都是严格的，它的行为与创建其方法和变量的方式完全相同。并且在给定的请求中总是相同的对象。因为它不能被创建两次成为两个不同的对象，所以你知道一个单例对象在代码的任何给定点是什么——即使这个单例对象被插入到两个、三个不同的、古老的、甚至意大利面条式的代码库中。因此，就开发目的而言，它使开发变得更加容易——即使有很多人在那个项目中工作，当你在任何给定的代码库中看到一个单例被初始化时，你知道它是什么，它做什么，它是如何做的，以及它处于什么状态。如果它是传统类，则需要跟踪该对象最初在哪里创建，在代码中的那一点之前在其中调用了哪些方法，以及它的特定状态。但是，如果在这里删除一个单例模式，并且在编写单例模式时删除了正确的调试和信息方法以及跟踪，那么您就确切地知道它是什么了。因此，对于那些不得不使用不同代码库的人来说，它使得集成代码变得更加容易，因为集成代码的必要性在早期是用不同的理念完成的，或者是由您没有接触过的人完成的。(也就是说，供应商-项目-公司-无论是有没有更多，没有任何支持)。

- 需要与第三方 应用程式界面、服务和网站合作的人员