今日はModel View Controllerアーキテクチャパターン（以下、MVC）とデザインパターンのObserverパターンについて調査してみた。
まず、MVCについて。最近よく聞くがこれはそれほど難しいものではない。Viewは出力、Controllerは入力、Modelはそれ以外の正味の処理のことだ。（POSA本より）ようするにViewやControllerの変更にModelが耐えられるようにしたり、複数の異なるViewやControllerに対応できるModelを作成することを目的としている。JavaのSwingもこれを採用しているので、何も知らない人はなぜこんな回りくどいことをしているのか不思議だろう。
さて、昨日の疑問だが、ようするにControllerが複数ある時は有効らしい。ようするにViewと同じだということだ。例えば、モードの変更でControllerを使用不可にしたり、何かの接続機器が接続されているときだけControllerを有効にしたりということが動的に可能になる。こういう場合は、Controllerのクラスを作り実装することに意味があるようだ。がしかし、そんなことってそんなに頻繁にあるのだろうか？この本でも欠点として指摘しているようにこのアーキテクチャを採用すると、複雑度が増す。過度の柔軟性はよくないような気がする。
例えば、更新伝播の仕組みにControllerが含まれているという点である。確かにModelにControllerをattachさせることにより、ControllerにModelの変更を伝播させることでControllerはViewに対し依存しなくなる。だが、ViewとControllerは一体になっていることのほうが多くはないだろうか。
Modelの変更によりボタンを使用不可にすることを例にとると、ボタンを使用不可にするということはControllerがModelへ通知をしないようにするのと同様に、ボタンを非表示にしたりグレイアウトする必要がある。どちらか一方のみ有効というのは考えにくい。SwingではJButtonに対してsetEnabledにすると表示だけでなく通知もされない。したがってControllerをわざわざattachする必要や、ControllerはViewの内部クラスまたは無名クラスで十分な事の方が多いのではないか。そういういみでいえばDocument-Viewアーキテクチャを採用した方が複雑度が少ないだけ、現実的なように思う。
