インタープリタ デザインパターンの特徴
  インタープリタ デザインパターンの特徴を以下に示す。

  特徴 | 詳細 | 関連する概念
  --- | --- | ---
  処理の部品化 | 取り替え可能な部品(Expression 役実装)として処理を実装することによりカプセル化を維持する。 | Command
  処理の共通化 | 共通の処理を委譲元 Expression 役実装で定義し個別の処理を委譲先 Expression 役実装で定義する。 | Template Method
  処理の構造化/組み立て/宣言 | Expression 役実装を組み立てることにより処理を構造的に宣言する。 | Composite
  処理の選択 | 結合する Expression 役実装を、処理を構造化する段階でユーザが選択する。 | Strategy
  処理の分岐 | Context 役または Expression 役の状態により委譲先を分岐する Expression 役実装を定義することが可能。 | フィルタ
  処理の省略 | Context 役または Expression 役の状態により委譲先への委譲をスキップする Expression 役実装を定義することが可能。 | Balking
  処理の代理 | 委譲先 Expression 役実装の処理を代理する Expression 役実装を定義することが可能。 | Proxy
  オブジェクトの共有 | 委譲先で生成したオブジェクトを保持し、次のアクセスから保持したオブジェクトを再利用する Expression 役を実装することができる。 | Flyweight
  処理の追加と制限 | Expression 役実装の前後に処理を追加したり処理を制限したりする Expression 役実装を定義することが可能。 | Decorator
  横断的な処理の定義 | スレッドや業務をまたがった Expression 役実装を定義し、全てのリクエストに一組のコンストラクタツリーを通過させる。 | AOP
  資源の生成から破棄までの部品化 | 資源を生成し委譲先に委譲し、最後に資源を破棄する Expression 役実装を定義することが可能。 | Before After
  前処理と後処理の連携 | 前処理委譲先 Expression 役実装と後処理委譲先 Expression 役実装を生成するクラスを定義することが可能。 | Hook Operation
  スレッド別のデータ保持 | Expression 役実装のコンストラクタの引数で ThreadLocal を受け取ることにより Expression 役実装の不変性を維持しつつスレッド別でデータを扱うことが可能。 | Thread - Specific Storage
  複雑な処理の隠蔽 | Expression 役実装の構造を隠蔽する Expression 役実装を定義することが可能。 | Facade
  コンテキストの分離 | Expression 役と Context 役を分離する。 Expression 役で揮発性のない(ロック/セマフォなどの継続的な状態や固定値)データを定義し Context 役で揮発性のある(処理終了後に破棄されるリクエストなど)データを管理することにより データの生存と破棄の管理を容易にする。 | 調査中

  図:インタープリタ デザインパターンの構造

  インタープリタ デザインパターンを適用する際の注意点と考慮点を以下に示す。

  注意点と考慮点 | 詳細 | 関連する概念
  --- | --- | ---
  依存性の注入 | Expression 役実装にデータを取得する処理を記述することにより再利用性が低減してしまう。 | DI/IoC
  揮発性のないデータの注入 | データを取得する処理を排除しその変わりにコンストラクタの引数に揮発性のないデータを指定することにより、再利用性を維持することが可能。 | DI/IoC
  高凝集度 | 処理の凝集度が高くなる単位で Expression 役実装を定義することにより、再利用性を維持することが可能。 | 調査中
  低結合度 | 処理の結合度が低くなる単位で Expression 役実装を定義することにより、再利用性を維持することが可能。 | 調査中
  インスタンスの不変性の維持 | コンストラクタの引数が参照型の場合、オブジェクトのコピーをとることにより Expression 役実装のインスタンスの不変性を維持することが可能。 | Immutable
  処理を行わない Expression 役実装 | 処理を行わない Expression 役実装を定義することにより Expression 役実装の複雑化を抑止することが可能。 | Null Object
  目的別 Expression 定義と Expression 役間接続 | ラベリングによるアイデア創発のため、目的別に Expression 役をインターフェイス宣言する。異なる Expression 役を接続するために Adapter パターンを適用する。 | Adapter
  処理枠組の選択 | オブジェクト構造と別にユーザが操作を選択するために Visitor パターンを適用することが可能。 Java の言語機構を使用する場合は Expression 役実装の追加の際に Visitor 役に対しオーバロードメソッドを追加する必要がある。 | Visitor, Annotation
  揮発性のあるリソースの生成 | 揮発性のあるリソースを生成する不変な実態を Expression 役のコンストラクタ引数で受け取ることにより、Expression 役実装の不変性を維持することが可能。 | Abstract Factory, Factory Method, Prototype
  Expression 役インスタンスの静的宣言 | Null Object など、業務としてのみでなくフレームワークとして一意な Expression 役インスタンスを静的変数として宣言することにより、設計の可視性を維持することが可能。 | Singleton
  参照キーの乱用抑止 | 参照キーが設計に表れた場合はフレームワークの都合によるファンクションポイントが発生している可能性がある。 Thread Specific Strage, Interpreter の適用を検討することにより、フレームワークの都合によるファンクションポイントを低減し実装の可視性を維持することが可能。 (例：Struts-config.xml の form-bean/@name、web.xml の servlet-nameなど) | データモデリング
  静的型検証/動的型検証の使い分け | フレームワークの設計にはラベリングによるアイデアの創発のため静的型検証機構を適用するのが有効である。 逆にフレームワークと個別業務を接続するためには静的型検証機構を適用せずに動的型検証のみを適用するのが有効。 (静的型検証機構の有効性は Woolpack におけるサーバ側値検証とクライアント値検証の比較で確認した。 また動的型検証のみの有効性は Woolpack テストにおけるToELTargetExceptionELインナークラスによる業務呼び出しとOGNLによる業務呼び出しの比較で確認した。) | 調査中
  プラグインの構造化 | プラグインによるフレームワーク拡張機構が設計に表れた場合は、インタープリタ パターン適用を検討することにより拡張機構の構造化を発見することが可能。(メタファ:USBカスケード接続) | Strategy
  Factory の構造化 | Factory パターンが設計に表れた場合は、インタープリタ パターンの適用を検討することによりオブジェクト生成の構造化を発見することが可能。(例:woolpack.utils.InputStreamFactory) | Factory

  インタープリタ デザインパターンとその他のオブジェクト指向の用語との関係を以下に示す。

  用語 | 関係
  --- | ---
  Chain of Responsibility | チェイン オブ レスポンシビリティ デザインパターンが木構造の葉から根に向かって処理を委譲するのに対し、 インタープリタ デザインパターンは木構造の根から葉に向かって処理を委譲する。