PHPでデータベースにアクセスするシングルトンのユースケースはありますか？

PDOを介してMySQLデータベースにアクセスします。私はデータベースへのアクセスを設定しており、私の最初の試みは次のものを使用することでした：

私が最初に考えたのはglobal：

$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'root', 'pwd');

function some_function() {
    global $db;
    $db->query('...');
}

これは悪い習慣だと考えられています。少し検索したところ、シングルトンパターンになりました。

「クラスの単一インスタンスが必要な状況に適用されます。」

マニュアルの例によると、これを行う必要があります：

class Database {
    private static $instance, $db;

    private function __construct(){}

    static function singleton() {
        if(!isset(self::$instance))
            self::$instance = new __CLASS__;

        return self:$instance;
    }

    function get() {
        if(!isset(self::$db))
            self::$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'user', 'pwd')

        return self::$db;
    }
}

function some_function() {
    $db = Database::singleton();
    $db->get()->query('...');
}

some_function();

これができるのになぜ比較的大きなクラスが必要なのですか？

class Database {
    private static $db;

    private function __construct(){}

    static function get() {
        if(!isset(self::$db))
            self::$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'user', 'pwd');

        return self::$db;
    }
}

function some_function() {
    Database::get()->query('...');
}

some_function();

この最後の1つは完全に動作し、$dbもう心配する必要はありません。

より小さなシングルトンクラスを作成するにはどうすればよいですか？または、PHPにないシングルトンのユースケースはありますか？

さて、私がキャリアを始めたとき、しばらくの間それについて疑問に思いました。さまざまな方法で実装し、静的クラスを使用しないことを選択する2つの理由を考え出しましたが、それらはかなり大きなものです。

1つは、非常に多くの場合、複数のインスタンスが存在することは絶対にないと確信していることがわかり、最終的には2番目のインスタンスが存在することです。最終的には、2番目のモニター、2番目のデータベース、2番目のサーバーなど、何でもかまいません。

これが発生すると、静的クラスを使用した場合は、シングルトンを使用した場合よりもはるかに悪いリファクタリングが発生します。シングルトンはそれ自体が不明瞭なパターンですが、かなり簡単にインテリジェントなファクトリパターンに変換されます。あまり問題なく依存関係注入を使用するように変換することもできます。たとえば、シングルトンがgetInstance（）を介して取得される場合、それをgetInstance（databaseName）にかなり簡単に変更して、複数のデータベースを許可することができます-他のコードの変更はありません。

2番目の問題はテストです（正直なところ、これは最初の問題と同じです）。データベースをモックデータベースに置き換えたい場合があります。実際には、これはデータベースオブジェクトの2番目のインスタンスです。これは、シングルトンを使用する場合よりも静的クラスを使用する場合の方がはるかに困難です。静的クラスのすべての単一のメソッドではなく、getInstance（）メソッドをモックアウトするだけです（一部の言語では非常に難しい場合があります）。

それは本当に習慣に帰着します-そして、人々が「グローバル」が悪いと言うとき、彼らはそう言う非常に正当な理由がありますが、あなたが自分で問題にぶつかるまでそれは必ずしも明白ではないかもしれません。

あなたができる最善のことは、（あなたがしたように）質問してから選択し、決定の結果を観察することです。時間の経過に伴うコードの進化を解釈する知識を持つことは、最初から正しく行うことよりもはるかに重要です。

シングルトンには、PHPでの使用はほとんどありません。

オブジェクトが共有メモリに存在する言語では、シングルトンを使用してメモリ使用量を低く抑えることができます。2つのオブジェクトを作成する代わりに、グローバルに共有されるアプリケーションメモリから既存のインスタンスを参照します。PHPでは、そのようなアプリケーションメモリはありません。1つのリクエストで作成されたシングルトンは、そのリクエストに対してのみ有効です。同時に行われた別のリクエストで作成されたシングルトンは、まだ完全に異なるインスタンスです。したがって、シングルトンの2つの主要な目的の1つはここでは適用されません。

さらに、アプリケーションで概念的に一度しか存在できないオブジェクトの多くは、これを実施するための言語メカニズムを必ずしも必要としません。あなたがいる場合必要なインスタンスを1つだけ、その後、別のインスタンスを作成しないでください。それはあなたがする場合にのみです何もないことがありますが、2番目のインスタンスを作成するときに子猫が死ぬとき、あなたはシングルトンのために有効なユースケースを持っているかもしれないこと、例えば、他のインスタンスを。

他の目的は、同じリクエスト内のインスタンスへのグローバルアクセスポイントを持つことです。これは望ましいことのように聞こえるかもしれませんが、グローバルスコープ（他のグローバルやスタティックと同様）への結合を作成するため、実際には望ましくありません。これにより、単体テストが困難になり、アプリケーションのメンテナンスが一般的に難しくなります。これを軽減する方法はいくつかありますが、一般に、多くのクラスで同じインスタンスを使用する必要がある場合は、依存性注入を使用します。

詳細については、PHPのシングルトンのスライドを参照してください-なぜシングルトンが悪いのか、そしてアプリケーションからそれらを排除する方法を参照してください。

シングルトンパターンの発明者の1人であるErich Gammaでさえ、現在このパターンを疑っています。

「私はシングルトンを落とすことに賛成です。その使用は、ほとんど常にデザインの匂いです。」

参考文献

• PHPでレジストリパターンまたはシングルトンをテストするのはどうですか？
• PHPデータベースクラスをシングルトンとして使用することの欠点は何ですか？
• PHP PDOを使用したデータベース抽象化クラスの設計
• シングルトンはマイクロブログサイトの良いデザインパターンでしょうか？
• 継承ではなくカプセル化するようにクラスを変更する
• 別のクラスからオブジェクトにアクセスする方法は？
• シングルトンがPHPで役に立たない理由
• クリーンコードトーク-シングルトンとグローバルステート

上記の方法を試しても、次のことについて判断する必要がある場合：

PHPでシングルトンが必要なのは誰ですか？

シングルトンに対するほとんどすべての異論は技術的な見地から来ていることに注意してください-しかし、それらはその範囲も非常に制限されています。特にPHPの場合。最初に、シングルトンを使用する理由のいくつかをリストし、次に、シングルトンの使用に対する異論を分析します。まず、それらを必要とする人々：

-多くの異なる環境で使用される大規模なフレームワーク/コードベースをコーディングしている人々は、クライアント/ボスからの多くの異なる変化する気まぐれなリクエストを実装する必要があるため、既存の異なるフレームワーク/コードベースを使用する必要があります。 / management / unitリーダーが行います。

シングルトンパターンは自己包括的です。完了すると、シングルトンクラスは、それを組み込んだすべてのコードで固定され、メソッドと変数を作成した方法とまったく同じように動作します。また、特定のリクエストでは常に同じオブジェクトです。2つの異なるオブジェクトになるように2回作成することはできないため、シングルトンオブジェクトがコードの任意の時点で何であるかがわかります。シングルトンが2つ、3つ、古い、スパゲッティのコードベースに挿入されている場合でも同様です。したがって、開発目的の面でより簡単になります。そのプロジェクトで多くの人が作業している場合でも、特定のコードベースのある時点でシングルトンが初期化されているのを見ると、それが何であるか、何をするか、どのように行われるかがわかりますそれが伝統的なクラスであった場合、そのオブジェクトが最初に作成された場所を追跡する必要があります。コードのその時点までに呼び出されたメソッドとその特定の状態。ただし、シングルトンをそこにドロップします。適切なデバッグおよび情報メソッドをドロップし、コーディング中にシングルトンに追跡すると、それが正確にわかります。そのため、異なる哲学で以前に行われたコードを統合したり、連絡先のない人々によって行われたコードを統合する必要があるため、異なるコードベースで作業する必要がある人々にとって、それはより簡単になります。（つまり、vendor-project-company-what何もない、何もサポートされない）。これは、以前にさまざまな哲学で行われたコードを統合したり、連絡先のない人々によって行われたりする必要があるため、さまざまなコードベースで作業する必要のある人々にとって簡単になります。（つまり、vendor-project-company-what何もない、何もサポートされない）。これは、以前にさまざまな哲学で行われたコードを統合したり、連絡先のない人々によって行われたりする必要があるため、さまざまなコードベースで作業する必要のある人々にとって簡単になります。（つまり、vendor-project-company-what何もない、何もサポートされない）。

-サードパーティのAPI、サービス、ウェブサイトで作業する必要がある人。

よく見ると、これは前のケースとそれほど変わらない-サードパーティのAPI、サービス、ウェブサイトは、制御できない外部の分離されたコードベースのようなものです。何でも起れる。したがって、シングルトンセッション/ユーザークラスを使用すると、OpenID、Facebook、Twitterなどのサードパーティプロバイダーからのあらゆる種類のセッション/承認実装を管理できます。また、同じシングルトンオブジェクトからこれらすべてを同時に実行できます。 -簡単にアクセスできます。プラグインを接続したコードのどの時点でも、既知の状態にあります。独自のWebサイト/アプリケーションで、同じユーザー用の複数の異なるサードパーティAPI /サービスへの複数のセッションを作成し、それらを使用してやりたいことを行うこともできます。

もちろん、これらすべては、通常のクラスとオブジェクトを使用することにより、従来のメソッドと調和することもできます-ここでの問題は、シングルトンがよりきちんとしていて、すっきりしているため、そのような状況での従来のクラス/オブジェクトの使用と比較して、管理/テストが容易であるためです。

-迅速な開発を行う必要がある人

シングルトンのグローバルな動作により、構築するシングルトンのコレクションがあるフレームワークを使用してあらゆる種類のコードを簡単に構築できます。これは、シングルトンクラスを適切に構築すると、確立された成熟したメソッドとセットメソッドが簡単に利用できるようになるためです。いつでもどこでも一貫した方法で使用できます。クラスを成熟させるにはしばらく時間がかかりますが、その後はしっかりしていて一貫性があり、便利です。シングルトンに好きなだけ多くのメソッドを実行できます。これにより、オブジェクトのメモリフットプリントが増加する可能性がありますが、迅速な開発に必要な時間を大幅に節約できます。アプリケーションは別の統合されたアプリケーションで使用でき、クライアント/ボス/プロジェクトマネージャーがいくつかの変更を加えるだけで要求される新しい機能をたたくことができます。

あなたはアイデアを得ます。次に、シングルトンへの異議と、有用なものに対する不聖な十字軍に移りましょう：

-一番の問題は、テストが難しくなることです。

そして、実際には、適切な予防策を講じてデバッグルーチンをシングルトンにコーディングすることで簡単に軽減できる場合でも、シングルトンをデバッグすることを認識して、ある程度はそれを行います。しかし、これは、他に存在する他のコーディング哲学/方法/パターンとそれほど違いはありません-ただ、シングルトンは比較的新しく、広く普及していないため、現在のテスト方法は、それらと比較的互換性がありません。しかし、それはプログラミング言語のどの側面でも違いはありません-異なるスタイルは異なるアプローチを必要とします。

この異論は、アプリケーションが開発された理由が「テスト」ではないという事実を無視し、アプリケーションの開発に入る唯一のフェーズ/プロセスではないという点で、この異論は横ばいになります。アプリケーションは本番用に開発されています。そして、「シングルトンが必要な人」セクションで説明したように、シングルトンは、コードを多くの異なるコードベース/アプリケーション/サードパーティサービスで機能させなければならないという複雑さから、大きな取引を削減できます。テストで失われる可能性がある時間は、開発と展開で得られる時間です。これは、サードパーティの認証/アプリケーション/統合の時代に特に役立ちます。

それは理解できますが、プログラマーはキャリアに応じて非常に異なる状況で作業します。そして、比較的大きな会社で働いており、定義された部門が異なる定義されたソフトウェア/アプリケーションを快適な方法で扱い、予算削減/レイオフの差し迫った破滅とそれに伴う多くの異なるものでたくさんのことを行う必要がない人々のために安価/高速/信頼性の高い方法では、シングルトンはそれほど必要ではないようです。そして、それは彼らがすでに持っているものへの迷惑/妨害でさえあるかもしれません。

しかし、「アジャイル」開発の汚い溝で作業する必要があり、クライアント/マネージャー/プロジェクトから多くの異なる要求（時には無理）を実装する必要がある場合、前述の理由により、シングルトンは節約の恩恵です。

-もう1つの反対点は、そのメモリフットプリントが高いことです。

各クライアントからのリクエストごとに新しいシングルトンが存在するため、これはPHPに対する異論となる可能性があります。適切に構築および使用されていないシングルトンでは、多くのユーザーが任意の時点でアプリケーションのサービスを受けている場合、アプリケーションのメモリフットプリントは高くなる可能性があります。

ただし、これは、コーディング中に実行できるあらゆる種類のアプローチに有効です。尋ねられるべき質問は、これらのシングルトンによって保持および処理されるメソッド、データは不要ですか？たとえば、アプリケーションが取得する要求の多くで必要な場合、シングルトンを使用しなくても、それらのメソッドとデータは、コードを通じて何らかの形でアプリケーションに存在します。したがって、従来のクラスオブジェクト1/3をコード処理に初期化し、3/4に破棄すると、どれだけのメモリを節約するかという問題になります。

このようにすると、質問はまったく無関係になります。シングルトンを使用するかどうかに関係なく、不要なメソッドやコード内のオブジェクトに保持されるデータはありません。そのため、シングルトンに対するこの異議は本当に陽気になり、不必要なメソッド、使用するクラスから作成されたオブジェクト内のデータがあると想定しています。

-「複数のデータベース接続を維持できない/困難にする」などのいくつかの無効な異論

複数のデータベース接続、複数のデータベース選択、複数のデータベースクエリ、特定のシングルトンの複数の結果セットを維持する必要があるときに、この異論を理解することすらできません。それらは必要です。これは、配列に保持するのと同じくらい簡単ですが、そのために使用したいメソッドを発明することができます。しかし、最も単純なケースである、与えられたシングルトンでの変数と配列の使用を調べてみましょう：

以下が特定のデータベースシングルトン内にあると想像してください。

$ this- > connections = array（）; （間違った構文、私はあなたに絵を与えるためにこのように入力しました-変数の適切な宣言はpublic $ connections = array（）;であり、その使用法は当然$ this-> connections ['connectionkey']です）

この方法で、一度に複数の接続をセットアップし、アレイに保持できます。クエリや結果セットなども同様です。

$ this-> query（QUERYSTRING、 'queryname'、$ this-> connections ['particulrconnection']）;

これは、選択した接続を使用して選択したデータベースに対してクエリを実行し、

$ this- >結果

キー 'queryname'の配列。もちろん、このためにクエリメソッドをコーディングする必要があります。これは簡単なことです。

これにより、必要に応じて、事実上無数の（リソース制限で許可されている限り）さまざまなデータベース接続と結果セットを維持できます。また、このシングルトンクラスがインスタンス化されたコードベースの任意のポイントで、任意のコードで使用できます。

もちろん、当然、結果セットと接続が不要になった場合は接続を解放する必要がありますが、それは言うまでもなく、シングルトンやその他のコーディング方法/スタイル/コンセプトに固有のものではありません。

この時点で、同じシングルトンでサードパーティのアプリケーションまたはサービスへの複数の接続/状態を維持する方法を確認できます。それほど違いはありません。

要するに、シングルトンパターンは、プログラムを作成するための別の方法/スタイル/哲学にすぎず、正しい場所で正しい方法で使用される場合、他のどのパターンとも同じように役立ちます。何も変わらない。

シングルトンがバッシングされているほとんどの記事では、「グローバル」が「悪」であることへの言及もあることに気づくでしょう。

それに直面しましょう-適切に使用されていない、虐待されている、誤用されているものはすべて悪です。これは、言語、コーディング概念、メソッドに限定されません。誰かが「X is evil」のような包括的なステートメントを発行しているのを見たら、その記事から逃げてください。視点が特定の分野での長年の経験の結果である場合でも、限られた視点の産物である可能性は非常に高く、通常、特定のスタイル/方法-典型的な知的保守主義で働きすぎた結果です。

「グローバルは悪である」から「iframeは悪である」まで、無限の例がそのために与えられます。10年ほど前に、特定のアプリケーションでiframeの使用を提案することさえも異端でした。次に、Facebook、iframeがどこにでもあり、何が起こったかを確認します-iframeはそれほど悪ではありません。

それでも頑固に「邪悪」だと主張する人もいますが、正当な理由がある場合もあります。

プログラマー/コーダー/ソフトウェアエンジニアの最も重要な資産は、自由でオープンで柔軟な心です。

シングルトンはグローバル変数を美化しただけなので、アンチパターンと見なされます。実際には、クラスがインスタンスを1つだけ持つ必要があるシナリオは比較的少数です。通常は、1つのインスタンスで十分です。その場合、シングルトンとして実装する必要はまったくありません。

質問に答えるには、シングルトンはここでは過剰であることは正しいです。単純な変数または関数で十分です。ただし、より良い（より堅牢な）アプローチは、依存性注入を使用してグローバル変数の必要性を完全に取り除くことです。

あなたの例では、一見変わらない一片の情報を扱っています。この例では、シングルトンはやりすぎです。クラスで静的関数を使用するだけで十分です。

より多くの考え：あなたはパターンのためにパターンを実装するケースを経験しているかもしれません、そしてあなたの腸はあなたが綴った理由のために「いいえ、あなたはする必要はありません」とあなたに言っています。

しかし、私たちはあなたのプロジェクトの規模と範囲を知りません。これが単純なコードである場合、おそらく捨てて、変更する必要はないでしょう。そうです。先に進んで、静的メンバーを使用してください。しかし、プロジェクトをスケーリングする必要があるか、メンテナンスコーディングの準備をする必要があると思われる場合は、はい、シングルトンパターンを使用することをお勧めします。

まず、シングルトンパターンはあまり使用されていないと言いたいだけです。アプリケーション全体を通して単一のオブジェクトを保持したいのはなぜですか？特にデータベースの場合、別のデータベースサーバーに接続する場合はどうなりますか？毎回切断して再接続する必要があります...？とにかく...

アプリケーションでグローバルを使用することには、いくつかの欠点があります（これは、従来のシングルトンパターンの使用と同じです）。

• 単体テストが難しい
• 依存性注入の問題
• ロックの問題を引き起こす可能性があります（マルチスレッドアプリケーション）

シングルトンの最大の問題は静的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パターン）に渡すだけで、モデルで使用できます。

単純にあなたのソリューションがPHPドキュメントで提示されたものとどのように異なるかを考えてください。実際、「小さな」違いが1つだけあります。ソリューションではゲッターの呼び出し元にPDOインスタンスを提供しますが、ドキュメント内のインスタンスでは呼び出し元にインスタンスを提供Database::singletonしDatabaseます（それらのインスタンスでゲッターを使用してPDOインスタンスを取得します）。

それでは、どのような結論に達しましたか？

• ドキュメントコードでは、呼び出し元はDatabaseインスタンスを取得します。Databaseこのクラスは、（実際には、それがさらされる可能性がなければならないあなたの場合は、すべてこのトラブルに行く「再公開）よりもリッチまたはより高いレベルのインタフェースPDOそれがラップするオブジェクトを。
• 実装を変更して、以外の（より豊富な）型を返すPDO場合、2つの実装は同等です。手動での実装に従うことによる利益はありません。

実際面では、シングルトンはかなり物議を醸しているパターンです。これは主に次の理由によります：

• 使いすぎです。初心者プログラマーは、他のパターンを処理するよりもはるかに簡単にシングルトンを処理します。その後、シングルトンがなくても手元の問題をより良く解決できる場合でも、ハンマーを持っているとすべてが釘のように見えますが、彼らは新しい知識をどこにでも適用し続けます。
• プログラミング言語によっては、漏れのない気密な方法でシングルトンを実装することは、大変な作業であることがわかります（特に、高度なシナリオがある場合：別のシングルトンに依存するシングルトン、破棄して再作成できるシングルトンなど）。 ）。C ++での「最も確実な」シングルトン実装を検索してみてください。あえてあなたです（私はAndrei Alexandrescuの画期的なModern C ++ Designを所有しています。
• シングルトンのコーディング時とそれにアクセスするためのコードの作成時の両方で追加のワークロードを課します。このワークロードは、プログラム変数を使って何をしようとするかについて、いくつかの自主的な制約に従うことなく実行できます。

つまり、最後の結論として、シングルトンは大丈夫です。ほとんどの場合、シングルトンをまったく使用しなくても問題ありません。

あなたの解釈は正しいです。シングルトンはその場所を持っていますが、使いすぎです。多くの場合、静的メンバー関数へのアクセスで十分です（特に、構築時間を制御する必要がない場合）。さらに、名前空間にいくつかの無料の関数と変数を置くことができます。

プログラミングするとき、「正しい」と「間違った」はありません。「良い習慣」と「悪い習慣」があります。

シングルトンは通常、後で再利用されるクラスとして作成されます。それらは、プログラマが深夜に酔っ払ってコーディングしているときに誤って2つのインスタンスをインスタンス化しないように作成する必要があります。

2回以上インスタンス化してはならない単純な小さなクラスがある場合、それをシングルトンにする必要はありません。もしそうなら、それは単なる安全策です。

グローバルオブジェクトを持つことは必ずしも悪い習慣ではありません。グローバルに、どこでも、いつでもそれを使用することがわかっている場合、それは数少ない例外の1つである可能性があります。ただし、グローバルは一般に、悪い習慣と見なされるのと同じ方法で「悪い習慣」gotoと見なされます。

私はこれについて何の意味もないと思います。接続文字列をコンストラクタのパラメータとして取得し、PDOオブジェクトのリスト（一意の接続文字列ごとに1つ）を維持するような方法でクラスを実装した場合、いくつかの利点がありますが、シングルトンの実装はこのインスタンスは無意味な練習のようです。

私が見る限り、あなたは何も見逃していません。この例にはかなり欠陥があります。シングルトンクラスにいくつかの非静的インスタンス変数がある場合、それは違いを生むでしょう。