シングルトンデザインパターンを正しく使用しています

Question

私は時々クライアントが照会するものを検索する必要があるサーバーを実行しています。レコードのためにクライアントのクエリをディスクに書きたいと思っていますが、私はこれ以上検索を遅くしたくありません。 （検索はすでにボトルネックになっています...）

クライアントが検索を実行すると、クライアントのスレッドがシングルトンスレッドにメッセージを送信します。シングルトンスレッドは、クライアントスレッドクライアントの要求を引き続き処理します。この方法では、ディスク上のファイルは同期の問題に陥ることはなく、クライアントの動作が遅くなることはありません。

ここでは概念的な質問があります。この場合、シングルトンは適切ですか？最近のプログラミングでは、シングルトンのデザインパターンを少し使いすぎていましたが、意図した使い方で使用していることを確認したいのです。

ご意見をいただければ幸いです。

Answer 1

singleton patternは間違いなく過度に使用されており、そのシェアはdifficultiesです（単位テストは標準的な例です）。しかし、設計のすべてのものと同様に、特定のシナリオの長所と短所を比較する必要があります。シングルトンパターンにはその用途があります。

（多くの場合、アスペクト指向プログラミングと呼ばれますが、まったく同じことではないとの議論がありましたが、シングルトンの動作を得るためのオプションがあります。 ..これは私がこの時点で読む記事を見つけることができません）は間違いなく選択肢です。あなたは建設注入、decoratorパターン、抽象的な工場とinversion of control containerの任意の組み合わせを使用することができます。私はJavaのIoCコンテナではないですが、自動インターセプトを可能にするいくつかの.Netコンテナがあります（私はSpring.Netがそう考えているので、Spring（Java）にこれが組み込まれていると思います）。これは、複数のレイヤー（セキュリティ、ログなど）で特定のタイプのアクションを実行する必要がある、あらゆるタイプのクロスカッティングの問題に対して非常に便利です。また、ほとんどのIoCコンテナではライフタイム管理を制御できるため、実際にシングルトンパターンを手動で実装することなく、ロガーをシングルトンとして扱うことができます。

まとめてください。シングルトンがあなたのシナリオに合っている場合（あなたの説明からそうであるように思えます）、それに行きましょう。あなたが長所と短所を重視していることを確認してください。あなたは別のアプローチを試して、2つを比較したいかもしれません。