- - PR -
別フォームを利用した処理について
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-05-30 22:47
ご返答ありがとうございます。
show()に関しての理解は間違っておりませんので疑っていただかなくて大丈夫です。 (別スレッドになっていいない?なども含めて) 囚人様、Azulean様 つまり、何らかの意図がないとこういった設計にする必要がないではないか?とのご指摘でよいのでしょうか。 詳細は勘弁願いますが、そうせざる得ない理由はあったといえると思います(過去の遺産との兼ね合いも含めて) しかしながら、主題としては、 実装上でもっとも簡潔な実装があったとして(Close系イベントの処理)、 それよりも、意味合い的に適切な実装(Click系のイベント処理)があるが、その実装が「もっとも簡潔」ではない場合に、どういった選択をするべきか? というものなので、よろしくお願いします。 | ||||||||||||
|
投稿日時: 2008-05-30 23:22
子フォームを別スレッドで表示しないので、「皆さんならどうしますか?」と聞かれると、「そういう設計はしない」という返事になるかと。 で、「皆さんならどうしますか?」と尋ねておきながら、「イベントに紐づける」という返答にたいして、「ただ、イベントやらデリゲートを使用するほどのことなのかなぁという気にさせられるわけですが。。」というのは、失礼かと思います。 それなら最初から、「こういう方法と、こういう方法があると思う。それぞれ、こういう事について、何とかならないかと考えている。これらの方法について、他にメリット、デメリットがあるなら聞かせていただきたい」とすればいいのでは? 「〜と思う」だけで終わると「なぜ?」と返ってくるのだから、「〜と思う。それは、〜だから。」と書いておけば、1往復分の時間が節約できると思います。
何を主眼にコードを設計するか、によるのでは? それ(オブジェクト)を適切に表すように、名前を付けたり、メソッドを実装するのがオブジェクト指向だと認識しています。 それこそ、最初に書かれているとおり、「「設定」をクリックしたから設定するのであって、フォームが閉じたから設定するわけではない」だと思いますが、何がそれを阻んでいるのでしょう? 世の中、2つの中からどちらかを選ばなければならないときがあるもので。そのときに、何を基準に選択するかを決めておけば、困らないと思います。 今回は、「実装の簡潔さ」と、「実装の表現性」で、どちらを選ぶかという問題・・・という認識でよろしいでしょうか。 私なら、「3ヶ月後の自分は他人」なので、表現性をとります。 簡潔故に「読まなければわからない」では、なんのための簡潔な記述か、わからなくなります。 | ||||||||||||
|
投稿日時: 2008-05-31 01:05
いまいち何を聞きたいのかがつかめないんですが…
モーダル表示するならともかく、モードレスや別スレッドなどとにかく 呼び出し側とは非同期でやるなら、CloseだろうがClickだろうが 実装自体にもほとんど差が出ないと思いますが… 実装もCallback用のデリゲートを渡すかイベントを定義するかくらいで、 それもどっちも大して変わらないですしね… それ以外にはそもそも方法があまり思いつかないんですが… Close系がシンプルってのはどういうのを想定してるんでしょうか? ※これがまったくわからない | ||||||||||||
|
投稿日時: 2008-05-31 05:12
この問いに対する一般的回答は 「時と場合による」 しかないことは自明ですが。 今回の件に関して、今までに出た情報だけから判断するなら、
これがよいと私は思います。
子フォームのCloseイベントを親で拾う場合、 「設定」ボタンが押されたのか「キャンセル」ボタンが押されたのか、調べる必要があります。 それは私には「簡潔」だとは思えません。 子フォームが「設定イベント」を公開していれば、 設定イベントに応じて設定すればいいだけです。 こちらのほうが「簡潔」に思えます。 特に別スレッドということですから、 Control.Invoke/BeginInvokeを使うことになるかもしれません。 その場合、Windowの廃棄とInvokeの順番などをちゃんと考えないと危険です。 私はそういったややこしい問題を考えるのは嫌いなので、 CloseなどのイベントでInvokeを使うのはなるべく避けます。 |