ウェブの世界ではMVC(Model, View, Controller)とクラスを分けて書くことが多い。
しかし、Java, PythonなどでGUI(Graphic User Interface)を伴うアプリケーションを書く時にはこのとおりにやるとうまくいかないようだ。
今、Pythonでプログラムを書いている。
GUIはTkinterで書いている。
最初、MVCのようにコントローラーをメインにして、Tkinterの画面をクラスにしてみた。
これをやると、ユーザーがGUI操作をした途端に書けなくなる。
例えば、リストボックスに眼、鼻、口と並んでいたとしよう。
ユーザーが鼻をクリックしたら、鼻にかんするデータを別リストボックスに出したい。
当然、データベースにクエリーをかけ、結果をリストボックスに書き出したい。
しかし、画面がクラスだとコントローラーにイベント(リストボックスの「鼻」が押されたよ）をコールバック関数で返すしかなくなる。
クラスのコールバック関数の設定はやっかいで、GUIのクラスからデータベースクラスを呼んだほうが簡単だよね、となる。
それならばコントローラーってなんの意味があるの？となってしまう。ひとつのクラスのコールバックを羅列していてコントローラーといえるだろうか？画面遷移を伴うからコントローラーが有効なんだと思う。
ウェブアプリケーションは一回、サーバー側に制御を渡すとサーバー側は画面を再送する。
対話型アプリケーションは画面の一部を書き換えることが多い。画面全体を入れ替えることはあまりない。ダイアログやらなんやら出して、全体はユーザーに見せておきたい。
この違いで、デスクトップアプリはGUIがメインの流れを作ることになる。
（ちなみにウェブアプリでも,データをJSONなどで送受する場合があるけれども、やはりMVCはうまくいかない。）
記憶をたどるとJavaでSwing使った時もVisual BasicもBorlandのDelphiもGUIがすべてのトリガーで処理を書いていた。
MVCアーキテクチャは万能ではない、と思った。
もちろんGUIのパーツにユニークな動きをさせたいと思えば、そのクラスを書いたほうがいいのだろうけれども。
