- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
156 ：デフォルトの名無しさん[sage]：2016/06/02(木) 00:42:01.42 ID:9Sgsnltg - 後で拡張することが無い部分をswitchで書くのは全然問題無いと思うが。
どこにOOによる拡張性を持たせるかが問題になるから、要件とか設計からの要請で判断するべき。
Expression Problemで明確になることだけど、
OOPは子クラスを新たに追加するのは簡単な一方、新しいメソッドを追加するには既存のソースを変更しないといけない。
親クラスに共通の処理を書いたとしても、他と違うことをしたい子クラスの数だけ変更箇所が散らばる。
どの子クラスがオーバーライドしてるのかを把握するのに手間がかかるし、
追加するメソッドによってはクラス階層を更に分けてコピペを減らすべきかもしれない。
enumとswitchを使っている場合は逆になって、メソッドの追加や変更部分は一箇所にまとまっていて把握と追加が楽。
新しい種類のデータを追加するのは面倒。
ちなみにHaskellの型クラスやOCamlのvariant typeを使うとデータの種類も処理の種類も楽に増やせる。
Javaだとジェネリクスを使えばできないことはないけど、汚くなる。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
223 ：デフォルトの名無しさん[sage]：2016/06/02(木) 09:59:19.16 ID:9Sgsnltg - 設計=仕様書から書けるテストはブラックボックステストで、
コードから書けるテストはホワイトボックステスト。
ブラックボックステストで全ての取りうる値を入力するなんて非現実的だから、境界条件を考慮してテストセットを作る。
ホワイトボックステストはどれだけ網羅するかにもよるけど、条件分岐があったらその全てを通るテストセットを作る。
テストで得られる保証の度合いで言うならホワイトボックス>ブラックボックスなのは確かだけど、
中身まで見れる状態になっていないとホワイトボックステストは書けない。
開発プロセスがトップダウン方式だったりテスト駆動開発だと、書けるテストはブラックボックステストにならざるを得ない、という現実的な話。
そこで満足するか、更なる品質保証のためのホワイトボックステストを書くかはコストと相談しましょう。
Haskellでも同じ。テストを書く必要が無いのは依存型やRefinment typesを使える言語だけ。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
237 ：デフォルトの名無しさん[sage]：2016/06/02(木) 16:51:41.22 ID:9Sgsnltg - >>228
コードだけ見て判断できるものもあるし、仕様書読まないと判断できないものもあるとしか言えない。
どっちを参照しても分からないなら作った人に聞くべきだけど、それはテストじゃなくてレビューになる。
それとも仕様書無しでソースあり、さあテストを書けって場合を考えている？
そんな苦役を振られたら、仕様書を作って欲しいのか確実に動かないバグを潰して欲しいのか確認するところから始めましょう。
|