CocoaにおけるMVCについてちょっと勉強してみた

CocoaにおけるMVCについてちょっと勉強してみたObjective-Cを書きながらMVCについて悩むことが多かったので、この機会に勉強してみることにしました。参考にしたのは、Appleのドキュメント(Objective-Cプログラミングの概念)です。MacアプリとiOSアプリを包含する資料ですが、iOSに焦点をあてて自分なりに簡単にまとめてみようと思います。

モデル

=> モデルオブジェクトはデータや基本的な振る舞いをカプセル化する

  • アプリケーションの永続的な状態を構成するデータは、ファイルに保存するか、データベースに格納するかにかかわらず、アプリケーションに読み込んだ後はモデルオブジェクトの管理下に置かなければならない。
  • モデルオブジェクトには、自身を目に見える形に表現し編集できるようにするユーザインターフェイスとの間に、明示的な接続はない。書式文字列、日付の表現方法等に関する情報は別の場所で管理すべき
  • 現実的にはある程度柔軟に対応する必要はあるが、一般にはモデルオブジェクトはインターフェイスや表現の問題に関与すべきではない。
  • 例外として、図形オブジェクトがある。図形オブジェクトの存在意義は目に見える(描画される)「もの」だからである。

ビュー

=> ビューオブジェクトは情報をユーザ向けに表現する

  • ビューオブジェクトはモデルが表すデータをどのように表示し、どのようにすればユーザが編集できるかその方法を知っている。
  • データを保存する方法については責任を負わない(データのキャッシュなどは例外)。
  • ビューオブジェクトは一般に再利用性が高く、様々な設定が可能。
  • ビューはモデルを正しく表示しなければならない。したがって、通常、モデルに変化があればそれを認識する必要がある。モデルオブジェクトは特定のビューオブジェクトに結びついていないので、変化した旨を伝える汎用的な手段が必要。

コントローラ

=> コントローラオブジェクトはモデルをビューに結びつける

  • コントローラオブジェクトは、ビューオブジェクトとモデルオブジェクトの仲介役として振る舞う。
  • Cocoaの典型的なMVC設計では、ユーザがビューオブジェクトを介して値の入力の選択を行うと、その内容がコントローラオブジェクトに伝わる。コントローラオブジェクトは、ユーザ入力をアプリケーション特有のやり方で解釈する。そしてモデルオブジェクトに、この入力を使って実行すべきことを指示する。
  • コントローラオブジェクトは種類によって再利用性が高いものと低いものがある。

役割の兼務

  • モデルコントローラ
    • コントローラでありながら、モデル層にも関与するオブジェクト。
    • モデルを「所有」している。
    • 主な責務はモデルを管理し、ビューオブジェクトと通信すること。
    • 総じて、モデルに適用されるアクションメソッドも、一般にモデルコトンとローラに実装する。
  • ビューコントローラ
    • コントローラでありながら、ビュー層にも関与するオブジェクト。
    • インターフェイス(ビュー)を「所有」している。
    • 主な責務は、インターフェイスを管理し、モデルと通信をすること。
    • ビューに表示されるデータに関わるアクションメソッドは、一般にビューコントローラに実装する。

Cocoaの各種のコントローラオブジェクト

  • Cocoaには大きく分けて、仲介型(mediating)調整型(coordinating)という2種類のコントローラがある(iOSには仲介型はない)。
  • 調整型コントローラの役割
    • デリゲートメッセージに応答し、通知を監視する
    • アクションメッセージに応答する
    • 所有するオブジェクトのライフサイクルを管理する(適切な時点で解放するなど)
    • オブジェクト間の接続を確立するなどのセットアップタスクを実行する

MVCのデザインパターン

当初の(smaltalk流)考え方

MVC = Composite、Strategy、Observer

  • Composite: アプリケーションのビューオブジェクトは、実際には入れ子になったビューの複合体(composite)。ビュー群が協調して動作する。ウィンドウを頂点として、その下にテーブルビューなどの複合ビュー、ボタンなどのがある。
  • Strategy: コントローラオブジェクトは、いくつかのビューオブジェクトに関する戦略(strategy)を実装している。インターフェイスの振る舞いが当該アプリケーションにおいてはどのような意味を持つかの判断は全てコントローラに移譲する。
  • Observer: モデルオブジェクトは、自身と直接的なかかわり合いがあるオブジェクト(一般的にはビューオブジェクト)の状態が変化するとその通知を受取る。

Mvc smalltalk

モデルオブジェクトは状態が変化するとオブザーバとして登録されているオブジェクト全てにその旨を通知する。オブザーバがビューオブジェクトである場合は、通知を受けて外観を変えることも考えられる。

理論上の問題点がある。ビューやモデルは、アプリケーションでも特に再利用性の高いオブジェクトでなければならない。ビューオブジェクトは、オペレーティングシステムやその上で動作するアプリケーションの「look and feel(外観)」を表す。外観や振る舞いの一貫性が重要であり、再利用性が高いことが求められる。一方、モデルオブジェクトは性質上、問題領域に対応するデータをカプセル化し、そのデータに対する処理を行う。設計の観点から、再利用性を高めるためにも、モデルとビューを完全に分離することが重要。

Cocoaの考え方

MVC = Command/Composite、Madiator/Strategy、Observer

Mvc cocoa

Cocoaアプリケーションでは、モデルオブジェクトの状態が変化すると、その通知はコントローラオブジェクトを経由して、ビューオブジェクトに伝わる。

MVCアプリケーションの設計ガイドライン

  • MVCアプリケーションの設計においては、(少なくとも理論的には)再利用が可能なオブジェクトを、できるだけ多くすることを目標とする。特にビューオブジェクトやモデルオブジェクトは再利用性が高いものでなければならない。アプリケーション固有の振る舞いは、できるだけコントローラオブジェクトに集約する。
  • ビューがモデルを直接監視して状態変化を検出することも可能ではあるが、できるだけそのような構成にはしない。ビューオブジェクトは、常に仲介型コントローラを経由して、モデルオブジェクトの状態変化を知るようにするべき。
  • アプリケーションを構成するクラス間のコード依存性を出来るだけ制限する。他のクラスに対する依存性が大きいほど、再利用性が損なわれる。
    • ビュークラスは、モデルクラスに依存するべきではない。
    • モデルクラスは、他のモデルクラス以外に依存するべきではない。
    • 調整型コントローラクラスは、MVCにおけるあらゆる役割のクラスに依存する。

感想など

概念的なことばかりですが、重要な事が多かったので結構元のドキュメントを書き写すことになってしまいました。シンプルな概念ですが、書き出してみることで以前より理解が深まった気がします。特に、当初の(smalltalk流)考え方と比較してCocoaのMVCが優れている点などがわかりやつく伝わってきました。また、それによりMVCそれぞれの要素の分離が大事だということが実感出来ました。

冒頭にも書きましたが、仲介型コントローラなどのiOSに関係のないものは省いています。一部、理解ができかった部分も省いています。

Pocket
LINEで送る

You may also like...