我知道这很旧，但是Dr8k的答案 几乎 就在那里。
当您考虑编写一段代码时，假设它会改变。这并不意味着您要假设它会在将来的某个时刻对它进行更改，而是要进行某种形式的更改。
将其作为目标可以减轻将来进行更改的痛苦：全球性组织很危险，因为很难在一个地方进行管理。如果将来我想让该数据库连接上下文知道怎么办？如果我希望它每使用5次就关闭并重新打开一次，该怎么办？如果我决定为了扩展我的应用程序而要使用10个连接池怎么办？还是可配置数量的连接？
一个 单身的工厂
为您提供了灵活性。我以很少的额外复杂性进行设置，并且获得的不仅仅是访问同一连接。稍后，我将能够以一种简单的方式更改该连接传递给我的方式。
请注意，我说的是 singleton工厂 ，而不是 单例
。单例与全局之间几乎没有什么区别。因此，没有理由建立单例连接：为什么当您可以创建常规全局变量时，为什么要花时间进行设置呢？
工厂能为您带来什么是获得连接的原因，并且是一个单独的位置来决定您将获得的连接（或连接）。
例
class ConnectionFactory{ private static $factory; private $db; public static function getFactory() { if (!self::$factory) self::$factory = new ConnectionFactory(...); return self::$factory; } public function getConnection() { if (!$this->db) $this->db = new PDO(...); return $this->db; }}function getSomething(){ $conn = ConnectionFactory::getFactory()->getConnection(); . . .}然后，在6个月内，当您的应用程序非常出名，并且变得笨拙而又断线，并且您决定需要的连接不止一个时，您要做的就是在getConnection（）方法中实现一些池化。或者，如果您决定要实现SQL日志记录的包装器，则可以传递PDO子类。或者，如果您决定在每次调用时都需要一个新的连接，则可以这样做。它是灵活的，而不是僵化的。
16行代码，包括花括号，可以节省您数小时的时间，也可以节省数小时的重构工作。
请注意，我不考虑这种“功能蠕变”，因为在第一轮测试中我没有进行任何功能实现。这是边界线“ Future Creep”，但在某些时候，“为今天的明天编码”
始终 是一件坏事的想法对我来说并不成立。
