GRASPパターン［コントローラーパターン］

設計 GRASP

コントローラーパターン（Controller）

概要

UIレイヤーからシステム操作を最初に受け取り調整する（外部システムからの要求を受ける）オブジェクトは何かを決定するパターン

  • 「保存」ボタンをクリックすると保存処理を行うクラスに処理を委譲する
  • 「スペルチェック」ボタンをクリックするとスペルチェックするクラスに処理を委譲する
    • 上記の責任を持つオブジェクトを「コントローラー（controller）」と呼ぶ

詳細

以下のどれかに該当するクラスをコントローラーとする（責任を与える）

  • システム全体・ルートを表すクラス
    • 掲示板システムでいうと「BBS」
    • またはサブシステムを表すクラス
      • 営業支援システムの「受注管理システム」といった役割のクラス
  • ユースケースを表すクラス
    • この場合、このユースケースにて起きるシステムイベントをすべてこのクラスに割り当てる
    • 命名規則として「***Handler」「***Coordinator（コーディネーター）」「***Session」といったものがしばしばつけられる（らしい）

メリット

  • アプリケーションロジックがインターフェースロジックで処理されないようになる
    • 将来アプリケーションが拡張した際など、アプリケーションロジックを再利用しやすくなる
    • 別のインターフェースで差し替えることができるようになる
  • ユースケース全体の状態を管理して、システム全体の整合性や処理順序を管理できるようになる
    • たとえばPOSレジシステムなどで「売り上げ処理」を完了させないと「お釣り支払い処理」が実行できない、とか制御しなければならない場合に、これらの関連するユースケースを1つのコントローラーに集約することで状態などの管理ができるようになる

Strutsで考えると

Actionクラスから、システム全体、またはサブシステム、またはユースケースを表すクラスに処理を委譲する

  • Actionクラスにロジックを記述すると、別Actionで同様のロジックが必要になった場合にコードが重複することになる
  • やり方は以下の感じ
    • コントローラークラスを生成（取得）する
    • ActionFormからリクエスト情報を取得し、コントローラークラスのメソッドのパラメータとして引き渡し、処理を実行する
  • .Netアプリケーションに対しても、上記の設計が良質とされる
    • イベントハンドラ（buttonClickメソッドなど）ではコントローラーに処理を委譲するだけにとどめる

気をつけること

  • コントローラーの凝集性んが低くならないようにすること（低くなってきた場合は設計を見直すこと）
    • システムに多数のイベントがあり、これらのすべてを1つのコントローラーで受け付けている
    • コントローラー自体がシステムイベント遂行のための処理の多くを実行している（仕事を委譲していない）
    • コントローラー自体に多くの属性があり、システム全体に関わる重要な情報を管理していたり、他の場所にある情報を複製している
  • 上記の場合、以下のように設計を見直すこと
    • コントローラーを追加し、分散する
    • コントローラーから他のオブジェクトに責任を分散させる
      • コントローラーに仕事させないようにする