web-dev-qa-db-ja.com

コンテキストデザインパターンを説明できますか？

Context design pattern について読み始めました。これは私がテキストから理解したことです：

  • すべての変数を含むマップがあります

  • 必要な人に渡すので、すべての変数をメソッドパラメーターとして送信する必要はありません。

私はそれを「取得」しましたか？

design-patternslanguage-agnostic
47
Geo

私はそれを「取得」しましたか？

申し訳ありませんが、まったくそうではありません。

Context Objectの目標は、強力な型指定とカプセル化をバイパスする手段として、多くのパラメータをメソッドに暗黙的に渡すことですnotです。目標は、プロトコルとプレゼンテーションテクノロジーに依存せず、一般的な管理された方法でスコープデータを保存することです。スコープ内に保存されたデータは、本質的に共有され、構造化することができ、メソッドに渡される一時パラメータとは本質的に異なります。

コンテキストオブジェクトパターンは、最初に Core J2EE Patterns 2nd Ed で導入されました。 「コンテキスト」部分は、オブジェクトがscopeのコンテキストでデータを保持しているという事実を指します。
（といった application/session/request/conversation/flash）。

その目的は、アプリケーションデータとロジックを、HttpSessionやHttpRequestなどのプロトコル/プレゼンテーションテクノロジー固有のクラスから可能な限り分離することです。

パターン実装

コンテキストオブジェクトの下では、application/session/request/otherスコープを対象とするデータは、ServletContext/HttpSession/HttpRequest/otherプロトコル固有のクラスに直接配置されません。代わりに、データはPOJOラッパークラスに格納され、ServletRequest/HttpSession/HttpRequest/otherに格納されます。

コンテキストオブジェクトmayデータをマップに保存しますが、その必要はありません-プログラムに関連する任意の構造/形式でデータを保存できます。

アプリケーションは、スコープごとに1つのContext Objectクラスを使用するか、データを規則正しい方法で分割し、過剰なクラスの膨張を回避し、懸念の分離を促進する複数のクラスを使用できます。

コンテキストオブジェクトは、最前面のプレゼンテーションクラス（ビュー、フロントコントローラー、ディスパッチャー）によって使用されます。これらのプレゼンテーションクライアントオブジェクトは、contextObject.getを呼び出して保存されたスコープデータを取得し、contextObject.putを呼び出してスコープコンテキストデータを保存します。

ビジネス/統合ロジックには渡されません。強力な型指定をバイパスして、多数のパラメーターをビジネスオブジェクトに渡す手段としては使用されません。ビジネス層および統合層の前には、厳密に型指定された特定のパラメーターを使用するビジネスデリゲート、アプリケーションサービス、および/またはセッションファサードがあります。

パターンの利点

  • テスト容易性：単体テストでは、ServletContextやHttpRequestなどのプロトコル固有の複雑なサーバークラスではなく、単純なPOJOをモックするだけで済みます。
  • 柔軟性と再利用性：アプリケーションのコアは、クラスのシンプロトコル固有の「プレゼンテーション」レイヤーとは独立して機能します。これは、アプリケーションがプロトコルまたはプレゼンテーションテクノロジー（HTML/HTTP/ServletおよびWAP/ServletおよびXML/SOAP/HTTP/EJBおよびHTML/HTTP/JSFなど）をより簡単に変更または追加できることを意味します。

コメント

  • 歴史的なパターンです
  • CDI、Guice、Spring、Seamなどの依存性注入フレームワークは、プロトコルに依存しない方法で既に実装されているスコープストレージを提供すると主張することができます。つまり、すべてのスコープが既にコンテキストオブジェクトとして実装されていること、つまり、開発者が追加のコンテキストオブジェクトを作成することを余儀なくされていることを意味します。それはパターンを否定しません-それはCDIフレームワークがすでにパターンをサポートしていることを意味します。
  • 正しく実装されていない場合、「アプリケーション全体でパススルーの巨大なコンテキストオブジェクト」アンチパターンが発生する可能性があります。

KaptajnKoldの引用：あなたはそれを得たと思います。ただし、避けるべきアンチパターンの方が多いと思います。理由をご覧ください こちら 。

あなたのコメントは、Context Objectの誤実装バージョンを参照しています。コンテキストオブジェクト自体はアンチパターンではありません。

71
Glen Best

コンテキストオブジェクトは、共有データと機能へのアクセスを提供します。

これは、次のエレガントで柔軟な代替品になります。

  • グローバル
  • シングルトン
  • 長いパラメーターリスト

ACCUはより詳細な説明を提供します。

Javaのコンテキストパターンの実世界の例が必要な場合は、 Google Android API's を確認してください。

コンテキストパターンを使用するときは、 ディペンデンシーグラフ に注意する必要があります。 （これがKaptajnKoldがアンチパターンと呼ぶ理由です。）

不要な依存関係を制限するには、目的ごとに異なるコンテキストを使用します。コンテキストをできるだけシンプルにし、必要に応じて構成または継承を使用して複雑さを追加します。

20
SharkAlley

コンテキストを使用して初期化するクラス。このコードを検討してください

public class BuildTagHandler extends TagHandler {

      public BuildTagHandler(ServiceContext context) {  // constructor
            this.tagDAO = context.getTagDAO();
            this.buildDAO = context.getBuildDAO();
      }

コンテキストを使用して、クラスを構築します。 contextファイルでは、実装はありませんが、代わりにこれらのDAOオブジェクトがたくさんあります

ファサードパターンとして解釈することも、巨大なインターフェイスですべてのエントリをカバーすることもできます。

0
Richard Luo

コンテキストはアンチパターンです。これは、アプリオリに未知のもののコンテナとして使用されるためです。

0
user1593165