C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[8]: チェックボックスについて


(過去ログ 55 を表示中)

[トピック内 15 記事 (1 - 15 表示)]  << 0 >>

■31132 / inTopicNo.1)  チェックボックスについて
  
□投稿者/ ゆうたん (16回)-(2009/01/15(Thu) 16:26:20)

分類:[.NET 全般] 

はじめまして。

早速ですが、チェックボックスにおいて、複数選択したか、してないかの判定はどのような
処理を行なえば良いのか、知っている方がいましたら教えてください。

例えば:

 A□  B□  C□

今回複数選択可能なのですが、Aにチェックを入れたか、入れてないかの判定や、
AとCにチェックを入れたかの判定を拡張性がもてるように処理を作成したらいいのか、
ヒントなど持っている方がいましたら、教えてください。今の私のロジックでは、
1パターンごとに処理を作成しています。拡張性がもてないようなロジックなので考え直し
と言われました。

@パターン1
 AとBにチェック → 処理1を行なう
Aパターン2
 AとCにチェック → 処理2を行なう
Bパターン3
 BとCにチェック → 処理3を行なう
Cパターン4
 Cにチェック   → 処理4を行なう

引用返信 編集キー/
■31133 / inTopicNo.2)  Re[1]: チェックボックスについて
□投稿者/ .SHO (532回)-(2009/01/15(Thu) 16:43:52)
> 拡張性がもてないようなロジックなので考え直し
> と言われました。

何を問題としてるのか良くわかりません。

引用返信 編集キー/
■31135 / inTopicNo.3)  Re[2]: チェックボックスについて
□投稿者/ ゆうたん (17回)-(2009/01/15(Thu) 16:50:51)
パターン@〜Cを個別で処理を作成すると、今後、仕様上チェックボックスに項目Dがもし追加された時、再度、プログラムを作成しないといけないという事になります。
項目Dが新たに追加されても、プログラムを修正しなくてもいいような拡張性のある
ロジックがもしもあれば、ヒントでもかまわないのでお教えください。


No31133 (.SHO さん) に返信
>>拡張性がもてないようなロジックなので考え直し
>>と言われました。
>
> 何を問題としてるのか良くわかりません。
>


引用返信 編集キー/
■31137 / inTopicNo.4)  Re[1]: チェックボックスについて
□投稿者/ よねKEN (253回)-(2009/01/15(Thu) 16:52:45)
>  A□  B□  C□>
> 今回複数選択可能なのですが、Aにチェックを入れたか、入れてないかの判定や、
> AとCにチェックを入れたかの判定を拡張性がもてるように処理を作成したらいいのか、
> ヒントなど持っている方がいましたら、教えてください。

状態  ABC 処理
-----------------
状態1 000 処理1
状態2 001 処理2
状態3 010 処理3
状態4 011 処理4
状態5 100 処理5
状態6 101 処理6
状態7 110 処理7
状態8 111 処理8

のようにチェックの状態とそれに対する処理の対応表を持つようにすればいいのでは?
(例えば、上記の状態3に対する010はBがチェックあり(A、Cはチェックなし)、という意味。
010は例なので、true,false,trueのようなBooleanの配列などでももちろん可)
上でABCと書いた項目のデータを作成するときにCheckBoxが増えてもよいように作りこんでおきます。

> @パターン1
>  AとBにチェック → 処理1を行なう

上との対応で言うとこれは状態7で、処理8をすればよいですね。

@〜C以外の場合の処理Nについては、エラー処理用のメソッドと対応させておけばよいでしょう。
引用返信 編集キー/
■31138 / inTopicNo.5)  Re[2]: チェックボックスについて
□投稿者/ やじゅ (908回)-(2009/01/15(Thu) 16:56:46)
やじゅ さんの Web サイト
>拡張性がもてないようなロジックなので考え直し
>と言われました。
>

チェックボックスの数が増えることも考慮して
Dictionary でジャンプテーブルでやれっとことなんでしょうかねー。
引用返信 編集キー/
■31140 / inTopicNo.6)  Re[3]: チェックボックスについて
□投稿者/ まいか (54回)-(2009/01/15(Thu) 17:00:19)
2009/01/15(Thu) 17:05:10 編集(投稿者)
2009/01/15(Thu) 17:04:59 編集(投稿者)

よねKENさんと同じになってしまいますが
Integer型の変数を4つ作って、Aがチェックされたら1、Bがチェックされたら10、Cがチェックされたら100を代入して
もう1つの変数にそれらを足して判別してみては如何ですか
引用返信 編集キー/
■31141 / inTopicNo.7)  Re[2]: チェックボックスについて
□投稿者/ επιστημη (1526回)-(2009/01/15(Thu) 17:00:31)
επιστημη さんの Web サイト
ABCそれぞれのチェックON/OFFで組み合わせは8通りあるので、
処理の配列(大きさ8)を用意しましょうか。
ABCのチェックにそれぞれ1,2,4の重みを与えて総和を求めれば、
処理配列のインデックスになります。

delegate void Proc();
Proc[] table = new Proc[] { null, null, null, 処理1, 処理4, 処理2, 処理3, null };
int n = 0;
if ( A.Checked ) n += 1;
if ( B.Checked ) n += 2;
if ( C.Checked ) n += 4;
if ( table[n] != null ) table[n](); // 処理を行う!

引用返信 編集キー/
■31142 / inTopicNo.8)  Re[3]: チェックボックスについて
□投稿者/ よねKEN (254回)-(2009/01/15(Thu) 17:04:33)
> 項目Dが新たに追加されても、プログラムを修正しなくてもいいような拡張性のある
> ロジックがもしもあれば、ヒントでもかまわないのでお教えください。

No31137 で私が書いたような方法でもプログラムの修正そのものは発生しますが、
修正箇所は局所化できるかもしれません。

「状態  ABC 処理」といった管理情報まで設定ファイルなどプログラムの外に追い出せば、
設定ファイルの変更だけで対応できるようにすることは可能かもしれませんが、
そこまでやるのはオーバースペックだと思います。
(ついでに言えば、そこまでやったところで、想定の範囲外の仕様変更が入ると修正なしで対応できないので、
変に作りこんでいる分、余計に修正工数がかかる可能性もあります)
引用返信 編集キー/
■31143 / inTopicNo.9)  Re[4]: チェックボックスについて
□投稿者/ επιστημη (1527回)-(2009/01/15(Thu) 17:08:52)
επιστημη さんの Web サイト
> 今後、仕様上チェックボックスに項目Dがもし追加された時、再度、プログラムを作成しないといけないという事になります。

その変更によってコードのあちこちに変更が及ぶとか
数百行/数千行の追加となるならともかくも、
その例では if 文をたったひとつ追加すればいいじゃないですか。
拡張性としては十分ですよ。

# などとスレた意見を言ってみる♪

引用返信 編集キー/
■31144 / inTopicNo.10)  Re[5]: チェックボックスについて
□投稿者/ ゆうたん (18回)-(2009/01/15(Thu) 17:13:23)
if パターン1 THEN
  処理1
ELSE
  IF パターン2 THEN
    処理2
  ELSE
    IF パターン3 THEN
     処理3
    ELSE
      IF パターン4 THEN
       処理4
      END IF
END IF
END IF
END IF

上記の処理だと問題でしょうか?





No31143 (επιστημη さん) に返信
>>今後、仕様上チェックボックスに項目Dがもし追加された時、再度、プログラムを作成しないといけないという事になります。
>
> その変更によってコードのあちこちに変更が及ぶとか
> 数百行/数千行の追加となるならともかくも、
> その例では if 文をたったひとつ追加すればいいじゃないですか。
> 拡張性としては十分ですよ。
>
> # などとスレた意見を言ってみる♪
>
引用返信 編集キー/
■31145 / inTopicNo.11)  Re[5]: チェックボックスについて
□投稿者/ .SHO (533回)-(2009/01/15(Thu) 17:14:05)
A□  B□  C□

とかじゃなくて

肉まん□  あんまん□  カレーまん□

とか、もっと具体的な質問にならないですか?

いまいち、どーしたいのかわかりません。。

引用返信 編集キー/
■31149 / inTopicNo.12)  Re[6]: チェックボックスについて
□投稿者/ επιστημη (1528回)-(2009/01/15(Thu) 17:20:35)
επιστημη さんの Web サイト
2009/01/15(Thu) 18:16:37 編集(投稿者)
No31144 (ゆうたん さん) に返信
> if パターン1 THEN
>   処理1
> ELSE
>   IF パターン2 THEN
>     処理2
>   ELSE
>     IF パターン3 THEN
>      処理3
>     ELSE
>       IF パターン4 THEN
>        処理4
>       END IF
>        END IF
>     END IF
> END IF
> 
> 上記の処理だと問題でしょうか?

↓は「これ↑のどこが拡張性に欠ける? 十分じゃない!」と主張しています。

>>その変更によってコードのあちこちに変更が及ぶとか
>>数百行/数千行の追加となるならともかくも、
>>その例では if 文をたったひとつ追加すればいいじゃないですか。
>>拡張性としては十分ですよ。

チェック項目の増減によって確かに上記 パターン× すべてを修正しなけりゃなりません。
が、処理をテーブル(配列)に格納する方式でも(どっちみち)そのテーブルの変更が必要です。

この程度の規模であれば変更量は正直「五十歩百歩」って感触です。

[追記]

とはいえ、

if パターン1 then ...
if パターン2 then ...

これに項目Dが追加されることによって

if パターン1 and     D then ...
if パターン1 and NOT D then ...
if パターン2 and     D then ...
if パターン2 and NOT D then ...

のように、if文の総数が「二倍」に膨れ上がります。
問題は「そこ」でしょう。

配列方式だと配列のサイズは二倍になりますが、コード行の増加は微々たる物。

項目(チェックボックス)数は変わらず、組み合わせによる処理の数/内容が変化する
のであれば「どっちもどっち」でしょうねぇ。

引用返信 編集キー/
■31150 / inTopicNo.13)  Re[6]: チェックボックスについて
□投稿者/ 魔界の仮面弁士 (963回)-(2009/01/15(Thu) 17:26:47)
No31144 (ゆうたん さん) に返信
> 上記の処理だと問題でしょうか?

インデントが深すぎるので、「ElseIf」も併用しましょう。
引用返信 編集キー/
■31154 / inTopicNo.14)  Re[7]: チェックボックスについて
□投稿者/ ぱると (10回)-(2009/01/15(Thu) 17:44:36)
Case文じゃだめですか?
引用返信 編集キー/
■31155 / inTopicNo.15)  Re[8]: チェックボックスについて
□投稿者/ επιστημη (1529回)-(2009/01/15(Thu) 17:47:26)
επιστημη さんの Web サイト
No31154 (ぱると さん) に返信
> Case文じゃだめですか?

if 文 と等価ならもちろんOKでしょう。訊くまでもなし。


引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -