または、別のデザインパターンを使用する方が良いですか？
5 に答える
13
数日前にここで同様の質問に答え、シングルトンを嘲笑しました。元の投稿は、シングルトンの動作をあざけることに関してC＃.Net向けですが、それでも適用する必要があります。
シングルトンパターンに関しては、それ自体に問題はありません。多くの場合、ロジックとデータを一元化する必要があります。ただし、シングルトンクラスと静的クラスには非常に大きな違いがあります。シングルトンを静的クラスとして構築すると、アプリケーション内のすべてのコンシューマーに実装されます。これにより、単体テストが非常に困難になります。
あなたがしたいのは、シングルトンのインターフェースを定義し、消費者が使用できるメソッドを公開することです。次に、コンシューマーには、それらをインスタンス化する人によって実装クラスへの参照が渡されます[通常、これはアプリケーション、または依存性注入\制御の反転に精通している場合はコンテナーです]。
コンシューマーをインスタンス化するのはこのフレームワークであり、1つのインスタンスだけが浮かんでいることを確認する責任があります。静的クラスからインターフェース参照への大きな飛躍ではありません[上記のリンクで示されているように]、グローバルにアクセス可能なインスタンスの利便性を失うだけです-私は知っています、グローバル参照はひどく魅惑的ですが、ルークは彼に背を向けましたダークサイド、そうすることができます！
一般的に、ベストプラクティスは静的参照を回避することを提案し、インターフェイスに対するプログラミングを推奨します。これらの制約を使用してシングルトンパターンを適用することは引き続き可能です。これらのガイドラインに従ってください。そうすれば、ユニットテストで問題が発生することはありません:)
お役に立てれば！
シングルトン！= public static class、むしろシングルトン==シングルインスタンス
于 2009-10-26T18:45:53.493 に答える
3
テスト容易性の欠如は、古典的なシングルトンモデル（インスタンスを返す静的クラスメソッド）の主な欠点の1つです。私に関する限り、これは、シングルトンを使用するコードを再設計して他の設計を使用するのに十分な理由です。
どうしても単一のインスタンスが必要な場合は、johnny gが提案しているように、依存性注入とインターフェースへの書き込みが間違いなく進むべき道です。
于 2009-10-26T19:24:17.303 に答える
1
私は通常、Flyweightオブジェクトまたは同様の値オブジェクトにのみシングルトンを使用します。（上記で説明したように）IoCコンテナーを調べることは、シングルトンよりも共有オブジェクトを処理するためのより良い方法です。
Smalltalk（これらのパターンの多くが発生した場所）では、trueとfalseの両方が事実上シングルトンであったことを考慮してください:)
于 2009-12-03T05:34:54.337 に答える
1
モックできる静的ベースのシングルトンを作成するときは、次のパターンを使用しています。コードはJavaですが、アイデアが浮かぶと思います。このアプローチの主な問題は、コンストラクターをパッケージで保護するように緩和する必要があることです（これにより、真のシングルトンが無効になります）。補足として-コードは、必ずしも単にそれを呼び出すのではなく、「静的」コードをモックする機能に適用されます
于 2009-10-26T18:50:54.937 に答える
0
シングルトンを使用する必要がある場合（そしてそうする理由があります...しかし、可能であれば常にそれを避けようとします）。IOCコンテナを使用して管理することをお勧めします。Delphi用のものがあるかどうかはわかりません。ただし、JavaではSpringを使用でき、.NETではWindsor/Castleを使用できます。IOCコンテナは、シングルトンを保持し、テスト用にさまざまな実装を登録できます。
このスニペットを超えてここに入るには、おそらく主題が大きすぎます。
于 2009-10-26T22:31:06.363 に答える