Webアプリケーションの話でも、ワークフローの話でもありません。
あるアプリケーションでボタンを押したりする毎にテキストボックスの一部が有効になったり、一部のテキストボックスが無効になったりします。
ラジオボタン1クリック
テキスト1無効
テキスト2有効
テキスト3有効
ラジオボタン2クリック
テキスト1有効
テキスト2無効
テキスト3無効
これは非常に簡単な例で、有効/無効がひっくり返る例です。
ただしあるチェックボックスがチェックされている場合には常にテキスト3は無効だとします。
ラジオボタン1クリック
テキスト1無効
テキスト2有効
if チェック == true
テキスト3有効
else
テキスト3無効
ラジオボタン2クリック
テキスト1有効
テキスト2無効
テキスト3無効
ラジオボタン2の処理は常に無効なために変化がありません。
このように例外条件などがいろいろ入ってくることにより、このような差分の設定などは容易に破綻します。
switch(条件)
1: //ラジオボタン1クリック時で、チェック=trueの時
テキスト1無効
テキスト2有効
テキスト3有効
2: //ラジオボタン1クリック時で、チェック=falseの時
テキスト1無効
テキスト2有効
テキスト3無効
3: //ラジオボタン2クリック時
テキスト1有効
テキスト2無効
テキスト3無効
このようにあえてべた書きをすることのメリットも検討してみましょう。
仕様書で書く場合にはこのように書いたりしていませんか？
| 項目 |
ラジオボタン1クリック時で、
チェック=trueの時 |
ラジオボタン1クリック時で、
チェック=falseの時 |
ラジオボタン2クリック時 |
| テキスト1 |
× |
○ |
○ |
| テキスト2 |
× |
○ |
× |
| テキスト3 |
○ |
× |
× |
リファクタリングで重複コードを削っていくということだけではなく、コードの読みやすさが業務アプリケーションや、長いバージョンを保守していくソフトの場合には必要になります。
アドホックな対応も必要ですし、冗長な対応も必要です。
適材適所