- - PR -
複数フォームで同じコードを書いてあるのですが。
投稿者 | 投稿内容 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-06-13 17:07
だったら、そのデータのまとまりから、アイテムのかたまりを作れば良いのではないでしょうか? カスタム コントロールである必要はありません。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||||||
|
投稿日時: 2007-06-13 21:19
今、継承コンボボックスが"内容5"まで表示できる能力を持っているとします。 新たにフォームを作成して、そのフォームには"内容3"まで表示できるコンボボックスを作成したいとします。
確かに楽ですね。 更に、新しいフォームを作成して、そのフォームには"内容5"まで表示できるコンボボックスを作成したいとします。
プロパティにするか列挙体にするかといった細かい違いはおいておいて、こんなコントロールは不自然すぎて私は使いにくいです。
逆に言えば、継承コントロールを修正したおかげで、既に継承コントロールを使っているフォームに影響がでるわけです。そして影響を出ないように無理して、コード例2 のような不自然なクラスになります。 先にも述べましたが、このようなコントロールは硬すぎて変更に耐えれません。よってデータが固まることが保証できるなら(都道府県のように)有意義しょうが、今回の例では不適切です。
はい。なので最初に言ったように、データはコンボボックスに内包せずに、外から設定すればよいと思っています。 [ メッセージ編集済み 編集者: 囚人 編集日時 2007-06-13 23:19 ] | ||||||||||||||||||||
|
投稿日時: 2007-06-13 21:20
…むむむ?
私は「後ろのロジックありき」で考えていたので、自分のブログに持って行った訳なのですがorz 基本的に、object や string を返すコントロールのままで置いておきたくない、です。 データは、できるならバインドしたいです。 しかし、今回注目したのは、一番最初にある「指定しない」です。 これから、「指定しないを選択してあるときは、何かのコントロールが Disable になるなど、何らかの処理が起こるに違いない」と考えました。 なので、「そういうデータで初期化する、ComboBox を継承したコントロールを作る。」というのは、ちと極端すぎました。 普通にデータ バインドすると、データを選ぶことしかできません。…null を選択することができません。選択していない状態に戻すことができません。 バニラミントさんが、データをコードに書いたのは、実はそういう理由かもしれないし、「はい/いいえ/無回答」みたいな選択肢だったのかもしれません。 もし、データがどう変わるかわからない。というようなものであるなら、「無回答」状態を挿入できるコントロールをつくるっていうのは、どうでしょう? もし、「はい/いいえ」や「ある/なし」のような変わることのない選択肢で、それがたくさんあって、あちこちに object から変更するロジックやデータを追加するコードが散らばっているというのなら、true/false/null を返すコントロールにしてしまうのもありだと考えます。 何にしても、限られた情報の中で、各自が自分の背景を元に、自分の判断だけでああだ、こうだというのは、危険ではないでしょうか。 _________________ | ||||||||||||||||||||
|
投稿日時: 2007-06-13 23:39
じゃんぬさん。
直前の返信を見てもらえばわかるように、この@IT掲示板でのケースの場合カスタムコントロールとは言っていません。 ビジネスロジックありのデータとみなす。 データのまとまりをクラス化する。 コンボボックスに流すメソッドを持つ。 属性とコンボボックスの文字列の組(コードとか必要なものも入れて)で格納する。 データのまとまりがクラス化された後、カスタムコントロールかするかどうかは、 それこそケースバイケースだとは思っています。 | ||||||||||||||||||||
|
投稿日時: 2007-06-14 00:15
ん? え? あれ? 反論されているように感じたものですから、カスタム コントロールの話だと思っていました。ごめんなさい。何だかうまく読み取れていないようです。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||||||
|
投稿日時: 2007-06-14 01:07
上記の実装例だと不自然で使いにくいと思います。 なぜなら、選択肢を意味づけに無関係にただ機械的に表示/非表示を 切り替えられるようにしているからです。 あくまで例として「内容2、内容3、内容4」のような意味のない選択肢群だから、 不自然だと思うのではないでしょうか? スレ主の実際の選択肢群については不明ですので言及できませんが、 別で上がっている「都道府県」のような(ようなと書いているのは市町村とか地域でもよいので)選択肢の例であれば、 表示/非表示を切り替えるプロパティは、 myComboBox.関東Visible = True だったり、 myComboBox.離島地域Visible = False だったりするかもしれません。 あるいは列挙型で実装するのであれば、 myComboBox.表示タイプ = 表示タイプ.全部の地域 ' デフォルトはこれ だったり myComboBox.表示タイプ = 表示タイプ.関東 Or 表示タイプ.離島地域 だったりするかもしれません。 何を表示し、何を表示しないのかは特にわかりにくくなりませんし、 むしろ業務的な意味づけで切り替えられてわかりやすくもなると思います。
はい。設計次第でそうなる可能性は否定できません。 あくまで継承したコントロールを作成するべき!という派ではないですが、 ただ業務的な意味づけが同じものであれば共通化はしたいと考えています。 データとしての共通化はそれ単独で共通化します。 さらにもう一歩進めて、これらのデータをセットして使うコントロールは 共通の動作パターンがあるのが通例なので、同じものは一箇所で扱いたいですね。 そういった意味で、継承したコントロールを作成する案も 十分に検討の余地があると思っています。 #業務上の仕様次第なのでここでは答えはでないでしょう。 [ メッセージ編集済み 編集者: よねKEN 編集日時 2007-06-14 01:15 ] | ||||||||||||||||||||
|
投稿日時: 2007-06-14 10:02
楽しく読ませてもらってます。
ここでみんなで仕様を決めてるわけではなし、締め切りもないですし、 この案件で、答えは必要ない、のではないでしょうか?
ここの書込みを鵜呑みにして、業務アプリを作る人もいないでしょう。 いたとしてもJittaさんに責任はないですし、命の危険もない、と思います。 保証はできませんが。 むしろ私には 「各自が自分の背景を元に、自分の判断だけでああだ、こうだという」 のが、非常に参考になります。 最終的には「結局ケースbyケースです」って結論で終わるのは 論理的に間違ってないとは思うのですが、それでは議論がもったいないですし、 質問者の為にも(むしろ私のために)よくない。 なにより、世界の平和の為によくない、気がします。 「こういう問題を考える場合、何を考えたらいいか」 というのがまとまると質問者にとって有益であるかと思います。 私が読んだところでは じゃんぬさん:コントロール・データの本来の役割・意味を考えれば、データはデータソースから。 囚人さん:フォームごとでもいい。 Jittaさん:継承コントロールにしておけばロジックまでまとめられる NAL-6295さん:継承コントロールが増えると大変なのでStaticから貼り付け かずくんさん:イニシャライザを別にしておけば便利。 よねKENさん:? えムナウさん:? という感じで、どうも、重要な点は 「データの存在する場所」 「データの更新頻度」 「データとロジックの関連の大きさ」 「プログラムの更新の大変さ」 「プログラムの分かりやすさ」 「政治的事情」 の6点という感じに理解したのですが、 解釈はあっていますか? 他になにか考慮すべきことがあるでしょうか? まとめてみると、じゃんぬさん話はすごく王道に聞こえますが データを完全に分離できないきもしますし、 囚人さんの方法は際限なくコードが増えていきそうな。 継承コントロールがたくさんになったら大変そうだし、 かずくんさんの方法だとイニシャライザの数が増えたり ロジックの追加が大変そう。 どれも一長一短で選べません。 初心者は何を優先するべきでしょうか? 指針はないでしょうか? それもケースbyケースと言われちゃうとこまっちゃうんだけど… でも、みなさん最初になにかを考えて、設計するでしょう? 最初になにを考えているのか教えていただけないでしょうか? | ||||||||||||||||||||
|
投稿日時: 2007-06-14 10:13
"データを完全に分離できない" の部分に纏わる事情をもう少し詳しくお聞かせ願えないでしょうか? 私は決まりきったかのように意見を書いていますが、正直なところこの手の問題 (メンテナンス性・実装者の分かりやすさ・工数の短縮・切り分け) に悩むコトが多いです。是非参考にしたいと考えていますので、差し支えなければお願い致します。(個人的なお話ですが、実は最近の他のスレッドでのれいさんの発言が勉強になっています) _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 |