1

オブジェクトを作成する必要があり、複数のクラスがそのオブジェクトにアクセスして変更する必要があるアプリケーションを開発しています。他のクラス オブジェクトによって行われた最近の変更を確認する方法と、そのオブジェクトをすべてのクラスでパラメーターとして渡すことなく、すべてのクラスから一元的にオブジェクトにアクセスする方法は?

複数のテーブル、複数のヘッダー/フッター、および段落を追加する Apache POI ドキュメントを作成しています。アプリケーションに存在する単一のXWPFDocumentオブジェクトのみが必要です。

これを達成できる設計パターンはありますか?

4

2 に答える 2

6

シングルトンの設計パターンは機能しますが、それほどきれいではありません。追跡が難しく、テストが難しいグローバルな静的状態になってしまいます。最近では、アンチパターンと見なされることがよくあります。それでも意味のあるケースはほとんどありませんが、私はそれを避けようとしています.

より良いアプローチは、依存性注入を使用することです。これらのオブジェクトのいずれかを必要とする各クラスで、そのタイプのコンストラクターパラメーターを宣言します (または、設定可能なプロパティを持つ可能性があります)。各クラスは、オブジェクトがどのように共有されているか、またはオブジェクトが共有されているかどうかについてあまり気にする必要はありません (共有できることを認識している場合を除きます)。次に、アプリケーションを初期化して、どのオブジェクトを共有するかを決定するのはコード次第です。

GuiceやSpringなど、Java で使用できるさまざまな依存性注入フレームワークがあります。これらのフレームワークの考え方は、適切な構成が与えられれば、アプリケーション内のすべての依存関係を自動的に接続することです。

于 2013-07-26T05:54:21.440 に答える
3

これにはSingleton Patternがあり、アプリケーションの単一のインスタンスを作成し、受け渡しせずに共有します。

しかし、それは最善の選択肢ではありません。

なぜそれが悪い選択肢なのですか？

  • コードのテスト容易性が良くない
  • 設計の拡張性がない

シングルトン パターンよりも優れているのは、アプリケーション全体の単一インスタンスです。

アプリケーション用に単一のオブジェクトを作成し、何らかのコンテキスト オブジェクトを使用して共有します。これについての詳細は、 Misko のテスト可能なコードのガイドで説明されています。

単一インスタンスであり、シングルトン パターンではありません

これは、アプリケーション全体の単一インスタンスを表し 、静的インスタンス フィールドを通じてその単一性を強化しません。

シングルトンのテストが難しいのはなぜですか?

  • 静的アクセスは、別のクラスのサブクラスまたはラップされたバージョンとのコラボレーションを防ぎます。依存関係をハードコーディングすると、ポリモーフィズムの力と柔軟性が失われます。-グローバル状態を使用するすべてのテストは、期待される状態で開始する必要があります。そうしないと、テストは失敗します。しかし、以前のテストで別のオブジェクトがそのグローバル状態を変更した可能性があります。
  • グローバル状態は、多くの場合、テストを並行して実行できないため、テスト スイートの実行が遅くなります。
  • 新しいテスト (グローバル状態をクリーンアップしない) を追加し、スイートの途中で実行すると、その後に実行される別のテストが失敗する可能性があります。
  • 独自の「シングルトン性」を強制するシングルトンは、不正行為に終わります。テスト中にインスタンスを変更する必要があるため、いわゆるシングルトンでreset()やなどのミューテーター メソッドをよく見かけます。setForTest(…)テスト後に Singleton をリセットするのを忘れると、後で使用すると古い基になるインスタンスが使用され、デバッグが困難な方法で失敗する可能性があります。
于 2013-07-26T05:54:29.453 に答える