監視コントローラー

動作方法

監視コントローラーは、プレゼンテーション機能をコントローラー（プレゼンターと呼ばれることが多い）とビューの2つの部分に分解します。表示する必要があるドメインデータは別個のものであり、大まかなMVC用語に従ってモデルと呼びますが、ドメインモデルである必要はありません。責任のこの基本的な分割は、バウアーとマクグラスハンによって記述されている、そのドルフィン形式のModel-View-Presenterアーキテクチャを反映しています。

監視コントローラーには、入力応答と部分的なビュー/モデルの同期という2つの主要な役割があります。

入力応答に関しては、コントローラーはプレゼンタースタイルで動作します。ユーザーの操作は最初は画面ウィジェットによって処理されますが、それらが応答として行うのは、これらのイベントをプレゼンターに渡すだけであり、プレゼンターはそれ以降のすべてのロジックを処理します。

ビュー/モデルの同期に関しては、コントローラーは可能な限りビューに任せます。ビューは通常、何らかのデータバインディングを使用して、フィールドの情報の多くを生成します。 データバインディングがより複雑なインタラクションに対応できない場合、コントローラーが介入します。

図1：評価例に関するクラス図。

図2：低い実際値を入力した場合の応答を示すシーケンス図。

評価ウィンドウでは、最初のテキスト変更はビュー内のテキストフィールドウィジェットによって処理されます。このウィジェットはコントローラーによって監視されているため、テキストが変更されると、ウィジェットはイベントを発行し、コントローラーの`actualFieldChanged`メソッドが呼び出されます。このメソッドは、イベントへの完全な応答を処理します。まず、readingモデルオブジェクトの実際値を更新します。ウィンドウはreadingオブジェクトを監視しているため、readingの値の変更によって更新がトリガーされます。実際値と差異テキストフィールドのテキストをreadingの適切なプロパティにマッピングするのは非常に簡単なので、それらの値を更新します。この例では、色の変更はもう少し複雑です。readingオブジェクトは、readingがどのカテゴリに分類されるべきかを判断できますし、そうすべきです。洗練されたウィジェットであれば、このようにテキストの色をカテゴリにバインドできるかもしれませんが、そのような賢いものは持っていないと仮定しましょう。この場合、コントローラーは差異フィールドのテキストの色を直接設定します。

例が示すように、優れた監視コントローラーの本質は、できるだけ少ない作業を行うことです。ビューができるだけ多くの処理を行い、より複雑なロジックが必要な場合にのみ介入します。

監視コントローラーを使用する主な理由の1つは、テスト容易性です。ビューがテストしにくいと仮定すると、複雑なロジックをコントローラーに移動することで、テストしやすい場所にロジックを配置できます。ただし、コントローラーのテストを実行するには、何らかの形式のビューが必要なので、テストダブルが必要になることがよくあります。ダブルがあれば、UI動作のより厄介な部分をテストするために、UIフレームワークオブジェクトは必要ありません。

このテスト容易性の問題は、コントローラーがビューとそのウィジェットに直接アクセスするのか、仲介者を通じてアクセスするのかという別の決定にも影響します。仲介者を使用すると、コントローラーを操作するためのゲートウェイを構築します。次に、ゲートウェイの1つの実装はウィンドウのインターフェースに適応し、もう1つはテスト用のスタブを提供します（モックを使用することもできます）。これは、パッシブビューに必要なのと同じアプローチです。

図3：コントローラーとウィンドウ間の仲介者を使用。

これまでの議論では、監視コントローラーでフロー同期を使用することを示唆していますが、そうする必要はありません。 オブザーバー同期を使用することもできますが、ビューではなくコントローラーがモデルを監視するように変更する必要があります。