これを思い出すとシングルトンの使用に関するいくつかの問題を列挙した投稿シングルトン パターンを使用する Android アプリケーションの例をいくつか見てきましたが、グローバル アプリケーション状態 (android.os.Application をサブクラス化し、context.getApplication() を介して取得) を通じて共有される単一のインスタンスの代わりにシングルトンを使用するのが良い考えかどうか疑問に思っています。
両方のメカニズムにはどのような利点と欠点がありますか?
正直に言うと、この投稿でも同じ答えを期待していますWeb アプリケーションでのシングルトン パターンは、良い考えではありません。しかし、Android に適用されました。私の考えは正しいでしょうか? それ以外では DalvikVM で何が違うのでしょうか?
編集: 関係するいくつかの側面について意見を伺いたいです:
- 同期
- 再利用性
- テスト
ベストアンサー1
私は Dianne Hackborn の回答にはまったく同意できません。私たちは、実際に必要なときに簡単に再作成できる軽量のタスク スコープ オブジェクトを採用するために、プロジェクトからすべてのシングルトンを少しずつ削除しています。
シングルトンはテストにとって悪夢であり、遅延初期化されると、微妙な副作用を伴う「状態の不確定性」が発生します (呼び出しをあるスコープから別のスコープに移動すると突然表面化する場合があります)。可視性は別の問題として言及されており、シングルトンは共有状態への「グローバル」(= ランダム)getInstance()アクセスを意味するため、同時実行アプリケーションで適切に同期されていない場合、微妙なバグが発生する可能性があります。
私はこれをアンチパターンだと考えています。これは本質的にグローバル状態を維持することに等しい、不適切なオブジェクト指向スタイルです。
質問に戻ります。
アプリ コンテキスト自体はシングルトンと見なすことができますが、フレームワークによって管理され、ライフサイクル、スコープ、アクセス パスが明確に定義されています。したがって、アプリ全体の状態を管理する必要がある場合は、他の場所ではなく、ここに配置する必要があると思います。それ以外の場合は、シングルトン オブジェクトが本当に必要かどうか、またはシングルトン クラスを書き直して、代わりにタスクを実行する小さくて短命なオブジェクトをインスタンス化できるかどうかを再検討してください。