- - PR -
イベントの伝播
1|2|3|4
次のページへ»
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-05-15 20:02
(いつも悩むことがあるんですが)
.NET、Windows画面で以下の構成の場合 (Exploerをイメージしてもらったら結構です) ・UserControlAはTreeViewなどから構成されています。 ・UserControl1,2,3はUserControlAで選択されたものが表示されます
この場合にUserControlAの情報をUserControl1,2,3に 投げたい。実際はUserControl1,2,3の中にもUserControl orControlが存在し、かつUserControl1,2,3で削除された 場合、逆にUserControlAにも伝える。 この時にいくつか組合せがあると思いますが。。。 @UserControlA→(Event)→Form→(Call)→UserControl1,2,3(ポリモフィズムLike) AUserControlA→(Event)→Form→(Event)→UserControl1,2,3(逆イベントキャッチ) BUserControlA→Observer→UserControl1,2,3(オブザーバーLike) と@ABの逆方向 (この他もあるとは思いますが) いつも悩んでしまうんです。こんなパターンの場合 みなさんはどうされているのでしょうか? | ||||||||||||||||
|
投稿日時: 2008-05-15 20:51
> この場合にUserControlAの情報をUserControl1,2,3に
投げたい。 FormがUserControlAのイベントにUserControl1,2,3のイベントハンドラを追加する。 > 実際はUserControl1,2,3の中にもUserControl orControlが存在し、かつUserControl1,2,3で削除された 場合、逆にUserControlAにも伝える。 FormがUserControl1,2,3のイベントにUserControlAのイベントハンドラを追加する。 こんな感じかな? | ||||||||||||||||
|
投稿日時: 2008-05-16 06:49
ありがとうございます。
なるほど、 本人知らずで、いつのまにかイベント参加 しいて言えば「親の強制結婚」型(別名:いいなづけ型)ですかね。 | ||||||||||||||||
|
投稿日時: 2008-05-16 10:12
ちょっと説明がよくわかりませんが…
> 実際はUserControl1,2,3の中にもUserControl > orControlが存在し、かつUserControl1,2,3で削除された > 場合、逆にUserControlAにも伝える。 UserControl1,2,3「が」削除された場合? UserControl1,2,3「で」UserControlorControl「が」削除された場合? ここでindigo-xさんが言っている通り、 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=44751&forum=7&7 ロジックとUIは密接に関わっています。 もし、ControlとControlControllerが密接に関わっているなら、 普通は親子や兄弟の関係になるでしょう。 親子であればGUI的に「親子」に、 兄弟であれば「親を作ってその子」とすればいいわけです。 もし、GUI的に入れ子関係にできないのであれば、 それは密接ではあるが間接的であるということです。 間接的な場合は文字通り間に「介在物」を入れたり、 「参照」を保持することで適切なオブジェクト間通信ができるはずです。 たぶん複雑に考えすぎてるのであろうと思います。 説明がよくわからないのでたぶんに勘が含まれますが、 この件ではUserControlAの親であるFormが状態の整合性を保てばよいと思います。 | ||||||||||||||||
|
投稿日時: 2008-05-16 10:35
すいません説明不足で、UserControlAでは代表のNodeが表示されていて UserControl1,2,3では詳細Nodeが表示されている状態で UserControl1,2,3のすべての詳細Nodeが削除されると自然とUserControlA のツリーから代表Nodeも削除されるて感じです。
そうですね。 悩む理由は Controlの親子関係=データの親子関係 Controlの親子関係!=データの親子関係 Controlの階層を一挙に飛びたい場合 動的に入れ替わる 見たいなのがが混在している ところでしょうかね。。。。。 | ||||||||||||||||
|
投稿日時: 2008-05-16 11:10
どうオブジェクトの階層構造を考えるのかが肝だと思いますが、 私なら…。 全体でひとつのコントロールであって、 左の一覧と右の詳細で包含関係は無いですよね。 右の詳細側で削除されるなどして左が更新せねばならないなら、 「全体」が「更新するべきである」という通達をだします。 つまり、内部コントロールがFormに変化を通達し、 その通達を受けてFormが左の一覧を再描画します。 左の変化を通達するのも同様。 イベントはコンポーネントを再利用したい場合に使います。 ですので、切り離せないオブジェクト間の通信用に 新たにイベント定義することしません。 つまり、 UserControlAでイベントを新たに作り、 FormやUserControl1にイベントハンドラを設けるというのはやりません。 件のFormを再利用したいという要望が将来あるでしょうから、 Formにイベントを定義します。 まぁ私はそんな感じです。 | ||||||||||||||||
|
投稿日時: 2008-05-16 12:52
コントロール上は包含関係はないですが、データ上は包含関係なので 悩むんでしょうかね。。。
UserControl1からのEventですよね。。。
FormからCall UserControlA.再描画ですよね。。。。
ちょっとここがわからなかったんですが。。。(上と矛盾するようなしないような) 子コントロールが親コントロールのEventに参加するって事ですか? (「自己イベント参加、不参加決定」型(←なんじゃそれ)) | ||||||||||||||||
|
投稿日時: 2008-05-16 13:40
UserControlAにイベントを定義しないということは 変更を他のインスタンスに通知する際 UserControlAからUserControl1,2,3またはFormに直接依存することになりますね それがFormにだったら循環依存になってしまうし、 UserControl1,2,3へだったら三つのクラスに依存することになるので それは避けたいはずです。 以上の理由から 明らかにUserControlAにイベントを定義するべきところだと思います。
ここでいう再利用というシチュエーションがよくわかりません。 Formにイベントを定義するということはFormが何らかの通知をすることになりますが 「誰」がFormの「何」の通知を受けたいと思うんでしょうか? |
1|2|3|4
次のページへ»