私はこれが古いことを知っていますが、Dr8kの答えはほとんどそこにありました.
コードを書くことを検討しているときは、それが変更されると想定してください。これは、将来のある時点でどのような変化がもたらされるかを想定しているという意味ではなく、何らかの形の変化が行われるという意味です。
それを目標にして、将来の変更の痛みを軽減します。グローバルは、1 つの場所で管理するのが難しいため危険です。将来、そのデータベース接続コンテキストを認識させたい場合はどうすればよいですか? 5回使用するたびに閉じてから再度開くようにしたい場合はどうすればよいですか。アプリをスケーリングするために、10 個の接続のプールを使用することにした場合はどうなりますか? または、構成可能な接続数ですか?
シングルトン ファクトリはその柔軟性を提供します。余分な複雑さをほとんど加えずにセットアップし、同じ接続にアクセスするだけではありません。その接続が後で簡単な方法で自分に渡される方法を変更することができます。
単にsingletonではなく、 singleton factoryと言うことに注意してください。シングルトンとグローバルの間にはほとんど違いがありません。そのため、シングルトン接続を使用する理由はありません。代わりに通常のグローバルを作成できるのに、なぜそれを設定するのに時間を費やすのでしょうか?
ファクトリが取得するのは、接続を取得する理由と、取得する接続 (または接続) を決定する別の場所です。
例
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」の境界線ですが、ある時点で、「明日のために今日コーディングする」という考えは常に悪いことではありません。