GUIアプリケーションを書く時のオブジェクトの設計

プログラミング

ウェブの世界では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のパーツにユニークな動きをさせたいと思えば、そのクラスを書いたほうがいいのだろうけれども。

コメント