サービスのためのシングルトン/静的クラス

Question

私はいくつかの特定の機能を扱い、アプリケーション自体に等しい寿命を持ち、プログラムの多くの部分で使用されることを意図したクラスを持つアプリケーションを持っています。この最後の理由のために私は彼らをサービスと呼んでいます。 例えば、オーディオサービスはオーディオファイルを再生し、オーディオに関連する他の多くのことを行います。

Theeseクラスは、アプリケーションの起動時に1回だけインスタンス化され、1つのタイプにつき複数のクラスを持つことは意味を持ちません。

ここではシングルトンについての多くの回答を読んでいるので、その使用法が推奨されていないので、必要に応じて参考にしてください。 プロジェクトが成長しているので、コンストラクタ上でサービス参照が必要な多くのクラスがあり、場合によってはすべてのサービス参照を追加するのを避けるためにそれらのサービスのファサードさえも必要です。

私はそれが間違っていると思います。私はこれが静的/シングルトンクラスのための良い使用であるべきだと思います。

これは正しい方法ですか？

Answer 1

春を紹介する回答が1つあります。カバーの下で、Springは依然としてその参照を必要な場所に渡しています。

新しいフレームワークをアプリに導入するのではなく、なぜシングルトンを使用しないのですか？それが仕事をし、サービスの参照を回すよりも維持しやすいなら、私はそれを使用すると言う。

シングルトンに関する懸念がテスト容易性の影響である場合は、Dependency Injection（フレームワークではなくパターン）を使用して、実装との結合を減らしてください。

Answer 2

autowiring機能を備えた依存性注入コンテナが必要なようです。 Javaを使用している場合は、たとえばSpringを考えてみてください。

Answer 3

実際には、アプリケーションライフサイクルの間に1回だけ作成されるべきオブジェクトを表します。これらのオブジェクトには実際に固定設定の一部が含まれています。たとえば、htmlだけを解析するためのパーサークラスがあるとします。 HTMLのルートは ""タグでなければなりません。さらに、クラスのすべてのインスタンスが同じことをするため、このパーサークラスからインスタンスのロードを作成したくない場合もあります。インスタンスはhtmlの文字列を取得し、Xを返します。 クラスが一度に1つしか処理しないと思う場合は、シングルトンに行くことができます。しかし、たとえば、オーディオサービスが一度に異なるオーディオを再生する必要があるとすれば、クラスのインスタンスを作成することは、それをシングルトンにするよりも優れています。

Answer 4

私はMikeGに同意します。シングルトンを使用します。これらのクラスはほとんどがサービス指向だと言うので、私はそれが何か問題を引き起こすとは思わないでしょう。