- - PR -
複数フォームで同じコードを書いてあるのですが。
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-06-13 12:58
一般論としては、かずくんさんが提示された Strategy のコードはスッキリしていて良いと思います。 >継承コントロール派の方へ どうでしょうね。例えば、あるフォーム（以下、対象フォーム）だけ"内容３"を持たせたい、なんて要求が出てきたときに 1.継承コンボボックスを修正して"内容3"を追加し、既存のコードに影響を与えないようにデフォルト値では"内容3"を表示しないようする。 2.対象フォームが使用している継承コンボボックスに Add("内容3") を追加。 3."内容3"がある新しい継承コンボボックスの作成。 4.対象フォームにはノーマルのコンボボックスを使用し、Add("指定しない")〜Add("内容3")を書く。 というように、非常に単純な事なのに選択肢が増えるのが邪魔くさいですね。そして、1、2、3 は良い作法とは思えないので、結局 4 になるわけで。 _________________ 囚人@わんくま同盟 囚人のジレンマな日々 [ メッセージ編集済み 編集者: 囚人 編集日時 2007-06-13 13:05 ] | ||||||||||||
|
投稿日時: 2007-06-13 13:28
継承コントロール派というわけではないですが、 既に継承コントロールの方針で実装してあり、"内容3"を追加することになったら、 私なら1か3のどちらかの対応を取ります。(たぶん1にします) 2、4はあまりお勧めできないパターンだと思います。 あるフォームに"内容3"を追加するような場合、 たいてい「指定なし〜内容2」の部分は基本的には同じ動作をすると思います。 (もちろん+/-αの変更もあるでしょう) 2では外部から勝手にAddすることで継承コントロールにどんな副作用を及ぼすかわかりません。 (継承コントロールのソースを見れば問題がないかはわかりますが、 共通部品の実装に依存するような記述方法は共通化の趣旨から論外でしょう) 4では動作上は問題ありませんが、類似コードが散在することになります。 しかも、「指定なし〜内容2」までの部分で継承コントロールとほぼ同じなのに あるフォームでは継承コントロールを使用(※1)、 あるフォームではコンボボックスに「指定なし〜内容3」をべたでセット(※2)と 複数のパターンが混在することになりますし、(※1)と(※2)が"内容3"以外は 基本同じということがソースコードの読み手にわからなくなります。 | ||||||||||||
|
投稿日時: 2007-06-13 14:08
じゃんぬねっと氏、囚人氏の意見に一票です。 今回の件がコントロールの継承をつかって対応する問題とは全く思えないです。 | ||||||||||||
|
投稿日時: 2007-06-13 14:36
私も 4 にしてしまいたい派です。 ケース バイ ケース、便利な言葉ですよね。業務でやる場合は工数や保守性のトレードオフを気にする場面も多いので、まさしくケース バイ ケースだと思います。3. は、がるがるさんの手法になるのかな。 このスレッドの件も、某氏の Blog で書かれているようにケース バイ ケースだとは思います。たとえば、(すごい極端なのですが) 都道府県を選択する類のものであれば、カスタム コントロールを考えます。実際には市区町村対応もしなければならないので、複合コントロールになるでしょう。 今回の件で私が批判的になっているのは、将来的な変更ありと考えていること (データとして一括管理されべき) また、コントロール外でデータを扱う場面が想定されるからです。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2007-06-13 15:03
全くその通りです。なので、データのみが追加された共通コントロールを端から作成しないという結論です。
3 なら、既に挙げられているようにコントロールがどんどん生産されていきます。しかも、そのそれぞれのカスタムコンボボックスは「一部」内容が重複しているわけですが、重複が嫌だという人は 3 はなしなのでしょうか。 1 のように「一部だけ」が共通化されていくとどんどん破綻していきます。つまり、"内容４"はどうするの？って話です。
その通りです。折角コントロールなのにカチカチ山なわけです。 なので 4 です。データの量が多ければ、最初にぽぴ王子さんが出された例ですね。 某所で、都道府県が選択できるコンボボックスが引き合いに出されていますが、性質が全く違うものである事を強調しておきたいです。つまり、都道府県はそう頻繁には増えたり減ったりしないので、カチカチに硬いコントロールでも別に構わないわけです。 共通化の恩恵として、「修正箇所が少なくて済む」と仰っている人もいますが、共通化の恩恵が最大限に受けられるのは「修正が全く、或いは殆どないクラスやコントロール」です。だから安心して使えるわけで、"内容3"や"内容4"に怯えながら使うコントロールってどうなんでしょう、と思ったわけです。 ロジックの共通化は？となると、勿論、話は別です。 _________________ 囚人のジレンマな日々 | ||||||||||||
|
投稿日時: 2007-06-13 16:04
>将来的な変更ありと考えていること (データとして一括管理されべき) また、コントロール外でデータを扱う場面が想定されるからです。
こういう状態であればビジネスロジックありのデータとみなして、 データのまとまりをクラス化したらどうでしょうか？ | ||||||||||||
|
投稿日時: 2007-06-13 16:06
3の選択肢を取ると"内容4"、"内容5"の追加については苦しくなるので、 (継承コントロール実装ありきの場合の)私の一押しは1なんです。
＞1.継承コンボボックスを修正して"内容3"を追加し、 ＞既存のコードに影響を与えないようにデフォルト値では"内容3"を表示しないようする。 先の投稿ではコメントしていないので後出しになりますが、 この対応を取る時点で、各項目が表示対象かどうか？ という情報を持たせることを想定しています。 コンボボックスを使う場合の典型的なパターンは、 「コード、名称」をデータとして持つと思いますが、 これに加えて「表示条件」を持つということです。 内容1、内容2はデフォルトで表示、 後から追加した内容3、内容4はデフォルトで非表示。 プロパティなどで表示パターンを明示的に指定すれば、 各項目の表示/非表示を切り替えるといった感じですね。 さらに項目が増えて、表示条件やそれに関連した処理が複雑になれば、 対処が苦しくなる可能性はありますが、 この方法であれば、その継承コントロールだけの修正で済みます。 ＃新しいフォーム側には"内容3"を出すための指示のソースコードはもちろん増えますが 元々の条件「指定なし、内容1、内容2」という状況からは、 増えても内容5くらいまでだろうという予想の元での発想です。 ＃先にも書いてますが継承コントロール派というわけではありませんので念のため。 ＃既に継承コントロールの方針で実装されているならこう対処するという話で。 | ||||||||||||
|
投稿日時: 2007-06-13 16:17
１〜４のどれでもない気がしますが。
データを持つクラスを作成して、 コンボボックスに流すメソッドを持つという意味ですね。 この場合はメソッドを要件の分だけ増やしていくことになります。 その場合はFormAでは内容１から３が必要で、 FormBでは内容１から４が必要なんていう意味がないものではなくて、 FormAではこういう属性のデータが必要だからという、 属性とコンボボックスの文字列の組で格納することになると思います。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。