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にチェックを入れたかの判定を拡張性がもてるように処理を作成したらいいのか、
ヒントなど持っている方がいましたら、教えてください。今の私のロジックでは、
１パターンごとに処理を作成しています。拡張性がもてないようなロジックなので考え直し
と言われました。

①パターン１
　AとBにチェック　→　処理１を行なう
②パターン２
　AとCにチェック　→　処理２を行なう
③パターン３
　BとCにチェック　→　処理３を行なう
④パターン４
　Cにチェック　　　→　処理４を行なう

引用返信 編集キー/

■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)

パターン①～④を個別で処理を作成すると、今後、仕様上チェックボックスに項目Dがもし追加された時、再度、プログラムを作成しないといけないという事になります。
項目Dが新たに追加されても、プログラムを修正しなくてもいいような拡張性のある
ロジックがもしもあれば、ヒントでもかまわないのでお教えください。

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

引用返信 編集キー/

■31137 / inTopicNo.4)

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

▲▼■

□投稿者/ よねＫＥＮ (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が増えてもよいように作りこんでおきます。

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

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

①～④以外の場合の処理Nについては、エラー処理用のメソッドと対応させておけばよいでしょう。

引用返信 編集キー/

■31138 / inTopicNo.5)

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

▲▼■

□投稿者/ やじゅ (908回)-(2009/01/15(Thu) 16:56:46)

>拡張性がもてないようなロジックなので考え直し
>と言われました。
>

チェックボックスの数が増えることも考慮して
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 編集(投稿者)

よねＫＥＮさんと同じになってしまいますが
Integer型の変数を4つ作って、Aがチェックされたら1、Bがチェックされたら10、Cがチェックされたら100を代入して
もう1つの変数にそれらを足して判別してみては如何ですか

引用返信 編集キー/

■31141 / inTopicNo.7)

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

▲▼■

□投稿者/ επιστημη (1526回)-(2009/01/15(Thu) 17:00:31)

ABCそれぞれのチェックON/OFFで組み合わせは8通りあるので、
処理の配列(大きさ８）を用意しましょうか。
ABCのチェックにそれぞれ1,2,4の重みを与えて総和を求めれば、
処理配列のインデックスになります。

delegate void Proc();
Proc[] table = new Proc[] { null, null, null, 処理１, 処理４, 処理２, 処理３, 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]: チェックボックスについて

▲▼■

□投稿者/ よねＫＥＮ (254回)-(2009/01/15(Thu) 17:04:33)

> 項目Dが新たに追加されても、プログラムを修正しなくてもいいような拡張性のある
> ロジックがもしもあれば、ヒントでもかまわないのでお教えください。

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

「状態　ABC　処理」といった管理情報まで設定ファイルなどプログラムの外に追い出せば、
設定ファイルの変更だけで対応できるようにすることは可能かもしれませんが、
そこまでやるのはオーバースペックだと思います。
(ついでに言えば、そこまでやったところで、想定の範囲外の仕様変更が入ると修正なしで対応できないので、
変に作りこんでいる分、余計に修正工数がかかる可能性もあります）

引用返信 編集キー/

■31143 / inTopicNo.9)

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

▲▼■

□投稿者/ επιστημη (1527回)-(2009/01/15(Thu) 17:08:52)

> 今後、仕様上チェックボックスに項目Dがもし追加された時、再度、プログラムを作成しないといけないという事になります。

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

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

引用返信 編集キー/

■31144 / inTopicNo.10)

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

▲▼■

□投稿者/ ゆうたん (18回)-(2009/01/15(Thu) 17:13:23)

if パターン１　THEN
　　処理１
ELSE
　　IF　パターン２　THEN
　　　　処理２
　　ELSE
　　　　IF　パターン３　THEN
　　　　　処理３
　　　　ELSE
　　　　　　IF　パターン４　THEN
　　　　　　　処理４
　　　　　　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)

2009/01/15(Thu) 18:16:37 編集(投稿者)

■No31144 (ゆうたん さん) に返信
> if パターン１　THEN
> 　　処理１
> ELSE
> 　　IF　パターン２　THEN
> 　　　　処理２
> 　　ELSE
> 　　　　IF　パターン３　THEN
> 　　　　　処理３
> 　　　　ELSE
> 　　　　　　IF　パターン４　THEN
> 　　　　　　　処理４
> 　　　　　　END IF
>        END IF
>     END IF
> END IF
> 
> 上記の処理だと問題でしょうか？

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

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

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

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

[追記]

とはいえ、

if パターン１ then ...
if パターン２ then ...

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

if パターン１ and     D then ...
if パターン１ and NOT D then ...
if パターン２ and     D then ...
if パターン２ and NOT D then ...

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

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

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