前回は、Cocoaの実装におけるMediatorパターンの例として、MVCアーキテクチャの中のコントローラを取り上げた。

今回は、このMVCアーキテクチャがさらに発展した形体について紹介しよう。

進化したMVC

MVCアーキテクチャは、Cocoaが登場したときから含まれていた、最も基本的なアーキテクチャだ。だが、その最初の構造に甘んじることなく、さらなる発展を遂げている。

最初に訪れた大きい変革は、PantherことMac OS X 10.3で登場した、Cocoaバインディングだ。Cocoaバインディングは、MVCの「C」であるコントローラを強化するものになる。コントローラの役割を担うクラスとして、NSControllerとそのサブクラスが提供された。そらに、基礎技術として、キー値コーディング、キー値監視、キー値バインディングといったものも登場する。これらを利用することで、コーディングなしに、Interface Builderだけでビューとモデルの設定を行えるようになった。

そして次に行われたのは、MVCの「M」であるモデルの強化だ。これは、TigerことMac OS X 10.4で登場したCore Dataによって実現された。Core Dataでは、データ構造の設計を行えるモデリングツールを導入することで、モデルの設計と運用をほぼ自動化することに成功したのだ。Core Dataは、LeopardことMac OS X 10.5ではCore Data 2.0として、さらなる機能強化を行っている。

このような、MVCアーキテクチャの強化で共通しているのは、ソースコードの記述量を減らし、メンテナンスを容易にするという点だ。このあたりは、「TigerのCocoaにみるMVCの完成」などを参考にしてほしい。

汎用的なMediatorとしてのNSController

さて、今度はこの強化されたMVCを、Mediatorパターンの視点から眺めてみよう。すると、コントローラがMediatorの役割を果たしていることに気づく。

Core Data以降のCocoaプログラミングでは、モデルの設計とビューのデザインは、これ以上ないくらい完全に分離された。モデルの設計は、Xocdeに付属するモデリングツールで行う。ビューのデザインは、従来通りInterface Builderだ。互いに相手のことは全く知らないし、使用するツールすら完全に別物なのだ。

これらをつなぐのが、コントローラの役割になる。つまり、Mediatorパターンの言葉を借りれば、コントローラがMediatorになり、モデルとビューがColleagueとなる。コントローラが仲介者となることで、互いに独立したモデルとビューをつなぐのだ。

ここまでであれば、前回紹介した旧来のコントローラと変わりはない。だが、強化されたMVCでは、決定的な違いがあるのだ。旧来のMVCでは、コントローラはアプリケーションごとのカスタムクラスになっていた。アプリケーション独自のビューとモデルに対応するため、カスタムクラスを作成する必要があったのだ。

だが、Cocoaバインディングから導入された、コントローラのためのNSControllerでは事情が異なってくる。NSControllerは、汎用的なコントローラなのだ。独自のサブクラスを作ることなく、様々なアプリケーションに対応することが可能なのだ。一応、モデルの種類に応じて、NSObjectController、NSArrayController、NSTreeControllerといった複数のクラスが用意されてはいる。だが、これらを使い分ければ、自分でカスタマイズする必要はまったくないのだ。

つまり、NSControllerは汎用的なMediatorと言うことが出来るだろう。

究極のMediatorパターン

これで、MVCの形は完成した。汎用的なビューと汎用的なモデルがあり、それらをつなぐ汎用的なコントローラがあるのだ。Mediatorパターンの言葉を使えば、MediatorもColleagueも、汎用的な形で提供されていると言うことが出来るだろう。

これらの間の接続は、Cocoaバインディングで行われている。Cocoaバインディングは、キー値をベースとして接続を行っているので、結びつきは非常に弱い。さらに、その設定はInterface Builderで行えるというおまけ付きだ。

CocoaバインディングとCore Dataによって実現されたMVCの形は、ある意味、究極のMediatorパターンと言うことも出来るだろう。