# こういうときにプログラミングタグを作っていないのはとても困る．
http://d.hatena.ne.jp/ir9/20061021/1161383537
何が嫌かって、ある項目に変化があった場合、別のコントロールに変化を入れなきゃいけないとかですね………はぁ…マジ面倒。orz
そうそう，そうなんだよね．
最近は delegate とかを使えるようになって，イベントとロジックを分けて書けるようになった．
これは，頻繁に変更されるGUIと，そうそう変更されないロジックの変化頻度の差に注目して，イベントの発生とそれに励起されるロジックを分解したモデルだといえよう．
それでも，widget が変更になったりしたら大幅に書き換えなきゃいけなくなったりする．
こないだもリストボックスからリストビューに変更する用件があって，なんで同じようなインタフェースなのにこんなにコードを書き換えないといけないんだと小一時間（ｒｙ
これはまあ最初から変更されることがわかってた事例なんで，文句を言う相手はいない．
あえて言えば後で変更することを知ってた上で，使い方をまだ知らないリストボックスを使うために調べるのを面倒がって，リストボックスを使った自分自身だめぽなわけですが．
そんなわけでどんなわけか知らんけどその辺どうにかならんもんかなーと考えてみる．
とにかく，イベントとロジックの分離だけじゃあ，widget の変更には耐えられんのです．
偉い人にはそれがわか・・・ほんとに偉い人にはわかってると思いますけど．
それなら，widget とイベントの発生も分離してしまえばいいんじゃないの？
ひとたびイベントが発生したら誰かにイベントを通知するところまで，モデルでカバーしてあげられないの？
中には，widget から widget へとイベントを通知するだけでいいこともあるんじゃないの？
例えばボタンを押した後に実行される処理と，ボタンを押したイベントに伴って発生するイベントは分離できるんじゃないの？
リストボックスとリストビューの基本的なプログラミングインタフェースは同じでもいいんじゃないの？
データソースは一カ所に集めて，同じものを表示するときはそれを参照するのがよいGUIなのだとしたら，データソースの変更通知を受けた widget が他の widget と連携してくれてもいいんじゃないの？
分離したいもの：
- イベントの発生とロジックの励起
- イベントの通知とそれに伴うイベントの発生
- widgetと発生するイベント
うーん，欲張りすぎか．
これだけ動的にやろうとしたらコードが膨張する？ 余計に面倒？
ただ，3つ目について．
- widgetと発生するイベント
今，widget が発生させるイベントって widget に固有のものと考えられているけど，そうでもないんじゃないか？
もう一段階，抽象レベルを高めてもいいんじゃなかろうか．
それが，
リストボックスとリストビューの基本的なプログラミングインタフェースは同じでもいいんじゃないの？
に繋がってくるわけだけども．
どんなもんなんだろうなー．
