私は最近、仕事中に新しいプロジェクトに追加されました。そして、Javaコードには、どこでも使用されている約10-15のシングルトンクラスがあります。これらのクラスの目的は、クライアントアプリケーションが起動したときにサーバーからデータを取得し、そのデータをプログラム全体からアクセスできるようにすることで、必要なときにサービス呼び出しを行う必要がなくなり、わかりやすくなります。このシングルトンをどのように置き換えるのですか？
しかし、タイトなカップリングとテストできないために、恐ろしいシングルトンが何であるかについての多数の記事を読んだ後、どうやってそれらを置き換えるのですか？私は依存性注入について言われましたが、アプリケーションのほぼすべてのオブジェクトに同じデータを渡し続けたいと思いますか？どんな提案も便利です。
私はそのような場合に依存性注入（DI）を使用しますが、あなたが言っていたように、それは好きではありません。
私が考えることができる次のことは、FACADEパターンです.AppleFacadeクラスを作成し、必要に応じてDIを作成します。 （DIを気に入らないのであれば静的にしてください）
私はそれが各シングルトンに依存すると信じています。たとえば、シングルトンをいくつかの静的関数に分解できますか？それとも、いくつかの小さなクラスに分類できますか？たぶんそれはアプリケーションのごく一部でしか使われないかもしれません。したがって、そのモジュールで使用するためにリファクタリングされた小さなクラスがあります。私は最終的には、それぞれのシングルトンの使用に依存していると思います。あなたのコードをよりシンプルで、より拡張性があり、クリーナーなどにするなら、それを保つこと。そうでなければ、リファクタリングする。
編集：追加するには、リファクタリングの必要性は何ですか？コードはシンプルでクリーンで、動作しますか？その場合は、アプリケーションに機能を追加することを検討してください。既存のコードを変更するのではなく、常にコードや機能を追加する。結局あなたは答える必要があります、それは拡張可能ですか？
これらのクラスのほとんどは、サーバーから取得した何らかの種類のデータにアクセスするために使用されます。たとえば、シングルトンAは初期化時にサービス呼び出しを行ってデータを取得します。このクラスには、プログラム全体を通してアクセスされる2-3個のCollectionオブジェクトがあります（変更不可能）。プログラムのクラスがこのデータを使用して必要な機能を実行できるように、シングルトンを持つことは理にかなっていますか？ – Pattay
Guiceを見てください。直接依存関係（深い依存関係を下方に渡すファクトリはありません）を受け取り、それぞれの注入可能なコンストラクタに@injectと注釈を付け、次に使用する抽象クラスまたはインタフェースに使用する実装を定義する "Module"クラスを作成しますそれらのコンストラクタ。
Guiceはリフレクトマジックを使用して、モジュールクラスの命令に基づいて実装を見つけ、オブジェクトグラフをインスタンス化します。モジュール内で明示的に定義していない依存関係に対して、引数なしのコンストラクタを自動的に使用するだけでもスマートに機能します。
Guiceにあなたのアーキテクチャーをより多く結びつけることができますが、避けたいのは、依存関係を注入するための一連の工場がある場合、Guiceのほんの少しです。
あなたのクラスを設計する方法は明示的な依存関係を考慮して行います。クラスがシングルトンを使用する場合：
class Client {
public void Method() {
SomeService.getInstance().doSomething();
}
}
この依存関係は内部に隠れています。それは（オプション2を示す）理にかなっている場合は、関係する方法で、それを引き出し（1）建設または（2）の上にそれを取るために：
class Client {
public void Method(SomeService service) {
service.doSomething();
}
}
をこれが最初のステップです。後で、シングルトンからインターフェースを抽出して使用することができます。これは遅いプロセスです：リファクタリング、再テスト、反復...
私はこの質問でショットを撮りたいですが、それは広すぎます。このタイトルは、特定のシングルトンを念頭に置いていることを暗示しています。交換したい特定の例と、いくつかの用途を投稿できますか？ –
以下のコメントを参照してください。 – Pattay