Index: [Article Count Order] [Thread]

Date:  Fri, 24 Dec 2004 00:37:28 +0900
From:  Nakamura Akifumi <********@*****.**.**>
Subject:  [oosquare-ml:04442] Re: GUI  操作のためにだらだら長い  Main は嫌だ(求助)
To:  ***********@***.***.*******.**.**
Message-Id:  <***********.****.********@*****.**.**>
In-Reply-To:  <005101c4e174$710c3d60$********@******.**.**>
References:  <**************.****.***********@***.*****.***> <005101c4e174$710c3d60$********@******.**.**>
X-Mail-Count: 04442


お世話になっております。 A.中村です。

On Tue, 14 Dec 2004 09:32:49 +0900
Masato Tange様 *****@******.**.** wrote:

> ・そもそも内部状態の変更/更新が頻繁な場合や、より高いユーザビリ
> ティーを追求する場合は、既製のWidegetなど使[わ|え]ない。さっさとあき
> らめて新規の開発を踏み切り、スケジュールと予定工数を組みなおす。

自分でやったことが有るわけでもないんで
単なる勘なんですが、

	Model(の種類)の数だけ、Viewも有る

っていう感じが理想なんじゃないか?と思ってます。
だから、四角には四角の、円には円の、Viewが有るべきだろうと。

そういう意味では、既存の定番なWidget(View&Controler)は
その種類があまりにも少なすぎる
(データ入力系のWidgetって、ほんの数種類ですよね)
でしょうから、
結果として「既製のWidegetなど使[わ|え]ない」
ということになるんだろうと思います。

もちろん、作り出したらキリが無いんでしょうけど、
それにしても定番はもう少し多くあって欲しいと思っています。

たとえば、上記で挙げた四角とかを扱い易くするために、
「点」や「線」を見たまんまにView&ControlするWidgetとか、
SliderWidgetみたいに上限下限値が固定な奴じゃなく
マウスのホイールみたいに際限なく回せるWidgetとか(これは
Qtには有るそうですね)、
そういう、基礎(部品)となりそうなものが
定番としてもう少し増えて欲しいです。

#そういう意味では、いろんな自作Widgetを大勢の人が
#(えてしてFREEかつソース公開で)公開してくれた、
#Delphi文化圏が、私は好きでした。



なお、上記のように、Modelの中の小さい単位で
対応するViewを用意すべきだろう、と俺は思っています。
なので、MicrosoftのDocument&Viewとか、
最近のWebアプリでいうところのMVC(2?)とかは、
どうにもこうにも「これのどこがMVCだ?」という疑問を感じてます。

あれらが言うMVCの単位は、1画面単位ですよね。
それって粒度が粗すぎるのではないか?と首を傾げてます。
(もちろんWebアプリとかでは粒度を下げることは困難ですが、
 だったらMVCと呼ばないでくれよ、と思ってます。
 呼称が気に食わないんです。)



閑話休題(?)。
そんなわけで、Modelクラスをリファクタリングしたら、
それと「一対一対応」しているはず(^^;のWidgetクラスも
それと歩調を合わせてリファクタリングすればいい、
のではないかと想像しています。

WYSIWYGって、
本当(Model)は違うものなんだけど
一見(View)同じものに見えてしまうような
そんなViewを作る、という間違った選択をしてしまわない限り、
便利なものだと思うんです。

#もっとも、誤った選択をしてるソフトは巷に多いですが。
#よく言われるワープロの問題は、
#つまり上記の誤った選択をしてしまってるために起こる悲劇。
#違うModelなら出来るだけ違う見た目になるように設計しましょうぜ。



> ・直接ダイアログにWidegetを配置しない。すなわち、ユーザビリティーを
> 考慮して乗せるWidegetを分類し、親を複数の配置マネージャに分ける。
> 配置マネージャをダイアログに配置して、Widgetの親に対するメッ
> セージはその配置マネージャにて処理する。

ちょっとMVC話題とは逸れますが、
配置マネージャがほんとにユーザビリティに寄与するのか?って
ちょっと疑問に思ってます。

だって、人って、触れる道具(ここではWidget)の「配置」でもって
操作体系を記憶しませんか?

で、配置を機械の都合(表示面積とか)で勝手に加減しちゃうと、
人の道具に対する記憶を蔑ろにしてしまうことになるのではないか?と。

たかがWindowが変形した程度(!)のことで
Widgetの配置を変えちゃったら、
あかんのではないかと。

むしろ、Widgetを固定配置にしたうえで、
仮想窓を物理窓の上のScrollablePaneとして貼り付けてしまうほうが
まだマシじゃないかと…

配置マネージャは、面白いし、涙ぐましいなぁとも思うんですが、
いざ実際に使う段になると、
ツールの分際で、勝手にふにゃふにゃ変形するなよ!という怒りが
先行するのは俺だけでしょうか?(^^;

で、
どちらかというと、
「ユーザ定義配置マネージャ」とでもいうべきもののほうが
ユーザにとっても幸せなんじゃないかな?
配置はユーザが決める。
決めた配置を(ファイルとかに)セーブでき、
それを好きなときに(他所の環境に持っていっても、
そのファイルをロードするだけで)再現できる、
っていう。
この自分用の配置定義こそが、
その人(の小脳?)にとっての「ツール」となる
んじゃないか?と。

#既出技術だったら御免なさい。
#というか、この程度のものが既出でないほうが悲しいですが。

#ちなみに実装は恐らく簡単ですよね(^^;
#抽象配置マネージャを継承して
#設定の編集とロードとセーブの機能をつける「だけ」。

ファイルにするってのは、
逆に一人の人でも、場合によって違う配置を
(つまり違うツールとして)使い分けたい、ということが
有るかも知れないから、それを簡単に切り替えられるようにしたい
ってことです。

少なくとも、Widgetの「分類」と配置とは
何の関係もない問題だろうと思っています。



> とのことですが、「ドメイン層のオブジェクト」と「関係データベース」の
> マッピングで、私はいつも苦労しています。データベースは、
> Table1 v.s. Table2 ですけど。。。オブジェクトは、 Oblect1 -> Object2
> なところが悩ましい(意味不明)。

俺としては、
RDBとメモリ上のObjectとの関係は、
ModelとViewの関係と、
多少は似てるんだろうな、と思っています。

ただ、全く同じというわけではないですが。
(たとえば、MVCにはO/Rで有名なインピーダンスミスマッチ問題は無い、とか。)