5

シングルトンがコードで問題を引き起こす理由をすべて読みましたが、次のシナリオでは代替案が見つかりません。

Java Swing アプリケーションがあります。ユーザーは、アプリケーションの表示と機能の両方に影響する GUI を介して設定を行うことができます。これらの設定は、XML 構成ファイルに保存および取得されます。アプリケーションが読み込まれると、SettingsManager オブジェクトが構築されます。コンストラクターでは、設定マネージャーが XML 構成ファイルを解析し、すばやくアクセスできるようにすべての設定をローカルに保存します (これをキャッシュと呼びます)。アプリケーションで設定が変更されると、設定はすぐにファイルに書き込まれますが、同時にキャッシュも更新されます。

問題

設定マネージャーの複数のインスタンスが作成されている場合、1 つのインスタンスで 1 つの設定が変更されると、他のインスタンスのキャッシュが古くなります。シングルトンを使用せずにこれを修正する方法の 1 つは、キャッシュを使用せず、常にファイルから設定を取得することです。これは恐ろしい考えではありませんが、好ましくありません。これを行った場合、スレッドセーフにするために追加の作業を行う必要があると思います。

シングルトンが役立つ理由

SettingsManager が Singleton の場合、キャッシュは 1 つしかないため、古くなることはありません。ただし、これは基本的にグローバル変数であり、設定にアクセスする必要のないクラスがアクセスできるようになったため、これは良い考えではないことが既にわかります。そして、私が読んできたものから、他にもたくさんの問題があります。

シングルトンを使用せずに問題を解決するこれを設計する他の方法はありますか?

4

2 に答える 2

0

Brady の回答をフォローアップして、「handle-body」クラスのメソッドをprotectedと宣言することをお勧めします。これにより、その可用性が制限されます。もう 1 つの方法は、「internal」という名前を含むパッケージにクラスを配置することです (例: com.mycorp.abc.internal)。これはアクセスを制限しないかもしれませんが、クラス/メソッドを実際に使用してはならないという明確なメッセージを他の開発者に送信します。

于 2012-06-14T19:45:35.440 に答える
0

SettingsManager がクラス内で内部的にシングルトンとして管理されるように実装でき (このクラスは明らかにシングルトンにはなりません)、このクラス インスタンスはそれを必要とするクラスにのみ注入されます。ハンドルボディ (AKA ブリッジ) がうまく機能します。

これにより、両方の利点が得られます。

  • SettingsManager は 1 回だけインスタンス化され、そのキャッシュもインスタンス化されます。また、キャッシュが古くなることはありません。
  • それを必要とするオブジェクトだけがアクセスできます

明らかに、このハンドル本体クラス (またはその他のソリューション) はどこでもインスタンス化でき、依存性注入を回避できます。したがって、この問題に対する完璧な解決策が存在するかどうかはわかりませんが、これにより、数歩近づくことができます.

于 2012-06-14T19:26:51.360 に答える