シングルトンパターンが悪である理由 (翻訳)_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 10:30:02958ブラウズ
元のリンク: http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
この記事は私が書いたものではありませんが、記事内の見解に完全に同意します。ブライアン・バトンはおそらく私が知っている中で最も才能のある人の一人です。きっと彼はあなたのフィードバックを気に入ると思います。
1. シングルトン パターンは、特定のサービスにグローバル アクセス ポイントを提供するためによく使用されます
はい、可能ですが、コストはどれくらいかかりますか?ご存知のとおり、シングルトン パターンはアプリケーション内の特定のサービスへのグローバル アクセス ポイントを提供するため、どこにでもサービスへの参照を渡す必要はありません。これはグローバル変数とどう違うのでしょうか? (グローバル変数はダメだということを覚えておいてください。) 最終的に何が起こるかというと、設計内の依存関係がコード内に隠されており、クラスやメソッドのインターフェイスからは検査できないということです。クラス内で他のオブジェクトがどのように使用されているかを正確に知るには、コードを調べる必要があります。これは不明確かもしれません（訳者注：これが翻訳であるかどうかはわかりません、原文：これは可能な限り明確ではありません）。渡されることを避けるためにグローバルなものを衝動的に作成することは、設計の悪臭になります。これはグローバル変数やシングルトンの機能ではありません。設計をより注意深く検討すれば、ほとんどの場合、すべてのオブジェクトやメソッドに「浮遊データ」を渡す必要のない、より良い設計を考えることができます。
2. シングルトン パターンを使用すると、作成するオブジェクトの数を制限できます
これも当てはまりますが、2 つの異なる責任を同じクラスに混在させることになり、単一責任の原則に違反します。クラスは、それがシングルトンであるかどうかを気にする必要はなく、ビジネス上の責任のみを気にする必要があります。特定のクラスのインスタンス化を制限したい場合は、作成をカプセル化し、必要に応じて作成機能を制限するファクトリまたはオブジェクト ジェネレーターを作成して、作成の責任がビジネス エンティティの責任から分離されるようにします。
3. シングルトン パターンはクラス間の密結合を促進します。
コードをテスト可能にする基本的な属性は、周囲の環境と疎結合であることです。このプロパティを使用すると、特定のテスト目標 (モック オブジェクトを考える) を達成するために、テスト中に代替の共同作業者を置き換えることができます。シングルトン パターンは、シングルトン オブジェクトの正確な型を緊密に結合するため、ポリモーフィズムを使用してそれを置き換える機会を失います。上記の最初の点で説明したように、より良いオプションは、クラスとメソッドにオブジェクト参照を渡せるように設計を変更することです。これにより、上記の結合の問題を軽減できます。
4. シングルトン モードは、プログラムの継続中に常に最後の状態を保存します。
永続的な状態は単体テストの敵です。単体テストを効果的にする理由の 1 つは、各テストが他のすべてのテストから独立している必要があることです。そうでない場合は、テストの実行順序がテストの結果に影響します。これにより、テストが実行すべきでない場所で失敗したり、さらに悪いことに、単に実行順序が原因でテストが成功したりする可能性があります。これによりバグが隠蔽され、悪質になる可能性があります。あるテストから別のテストに状態が引き継がれるのを防ぐ良い方法は、静的変数の使用を避けることです。シングルトン パターンは、その性質上、インスタンスを静的変数に保持することに依存しています。これは依存関係をテストする際の課題ですが、オブジェクトへの参照をクラスやメソッドに渡すことで回避できます。
この記事がシングルトン パターンに関する私の見解を多かれ少なかれ説明してくれることを願っています。私には、Google などで見つけたリンクの小さなコレクションがあります。その中には、同様の意見を共有する Jim Hyslop と Herb Sutter も含まれています。もし気に入ったら、私に知らせてください。
その他の記事については、私の個人ブログをご覧ください: http://www.nomoneynowife.com