オブジェクト指向システムの設計 170

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 11/04 03:18 / Filesize : 386 KB / Number-of Response : 1023
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

オブジェクト指向システムの設計 170

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net]: オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ
オブジェクト指向は役割でオブジェクトに分割するものであって
処理で分割するものではない。
101 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 23:49:54.85 ID:4qIp1aFV.net]: >>91
そもそも 1000 や 10000 に分岐する時点で
仮想にするとか switch にするとか以前の問題があるだろうに。。
設計をしっかりするって別にオブジェクト指向がどうのこうの言う事じゃなく、
こういう分類をうまくやって、あほみたいな数の分岐をなくしたり整理することなんじゃないのかね。
102 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 23:53:29.29 ID:HPDljpqn.net]: このスレってスレタイのオブジェクト指向設計について語る人は少ないよな
オブジェクト指向設計は初心者には無理だからだろうか
失敗する奴は理解できていないのが原因
103 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:08:57.03 ID:DVl/WGs1.net]: >>101
お前が言うか
人の批判に終始してるだけじゃねーかよ
知識豊富な君は何か語りたいことがあるのかよ？

以下の用語を使い100字以内でどうぞ。

オブジェクト趣向分析
オブジェクト嗜好設計
オブジェクト施工プログラミング
104 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:23:11.27 ID:iqAUu6wp.net]: >>102
あと30字程度しかないじゃないかｗｗｗ
105 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:31:30.60 ID:m3KkndXk.net]: ↑算数も出来ない
プログラミング以前だね
106 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:33:43.37 ID:iqAUu6wp.net]: >>104
たしかに……SJISバイト数で数えてしまった
107 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:35:54.30 ID:XVpspPb0.net]: >>26
> 一つのswitch文にcaseが10個あったら？20個だったら？100個だったら？

それだったら関数テーブルに置き換えるな。

var f = {
　　case1: func1,
　　case2: func2,
　　case3: func3,
　　case4: func4,
　　：
　　：
}

switch文なんて簡単になくせるよ。
108 名前：デフォルトの名無しさん [2016/06/01(水) 02:54:32.51 ID:RDQRhO1c.net]: >>103
わろたｗ
109 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 07:17:52.51 ID:3uAWtRHV.net]: >>94
それはブラックボックステストでしょ
俺がコード見てテストケース作るって言ってるのはホワイトボックステストだよ
110 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 07:49:26.90 ID:eXE7t88x.net]: >>95
なんだこいつただの馬鹿じゃん
111 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 09:09:11.45 ID:MqC7NAR1.net]: 将棋の合法手については駒自体の動きと盤面の両方を考慮して決まる。
クラス構成はどうする？
112 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 09:49:07.08 ID:OaTzWyfO.net]: OOにすることって事前に決めるようなナンセンスな話題にしたいなら将棋の話でいいんだけど、違うでしょ？
自動車とか鳥をクラスでとかいう入門書でよくやる例が、実際にOOで設計する例と乖離しているんじゃないかって話でしょ？
どうしてOOで設計するのかをはっきりさせないと、何をどういうクラスにするかも不明瞭になるよ。

お遊びで将棋を例にするなら、自分なら駒をクラスにして階層構造を作ったりはしない。
駒はプレイヤーが動かすものであり、ルールで動かし方が決まっている、どこまでも受動的なものだから、
あたかも主体にするような勝手な解釈を作ることになる。
つまりルール上に無い階層構造を作ることになり、設計段階で指し方のアルゴリズムに制限がかかる。
駒クラスにメソッドを定義しても、現在の棋譜が必要になるから、盤面を常に引数で受け取るか状態として保持しないといけないので、旨味も少ない。
駒はsum type相当でコンパクトに表現して、ルールをクラス化する方がいい。
113 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 09:58:23.00 ID:5B+GU3AB.net]: なんかよく分からんけど
盤クラス、駒クラス、ルールクラスではイカンのか？
114 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:00:59.02 ID:MqC7NAR1.net]: >>111
駒をクラスにしろなんて言ってない。
115 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:10:44.41 ID:MqC7NAR1.net]: >>112
明確な正解はなさそうだから、意見交換するにはいい話題だと思って。

駒の動きを駒に持たせるのは自然だけど
局面による制約はあるから盤、駒、ルールの割り振りがはっきりしない。
王手放置、二歩、打ち歩詰めの禁止は盤に紐づいてるように思える。
どちらもルールって考えもありそう。 []; [ここ壊れてます]
117 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:19:46.05 ID:MqC7NAR1.net]: >>111
受動的なものだからクラスにならないってのは違うだろ。
MVCもMは受動的なクラスの典型。

駒をクラスにするって制約を勝手に想定して反発してる感じだから
それがないと認識した上で意見を書いて欲しい。
118 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:20:56.38 ID:370Huk/V.net]: >>84
お前それ@t_wadaに対して言えんの？
119 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:23:44.00 ID:5B+GU3AB.net]: >>114
>王手放置、二歩、打ち歩詰めの禁止は盤に紐づいてるように思える。

個人的にはそれがルールかな

駒は動ける方向を持つ、
盤は駒の位置を保持する
（存在しない位置に駒が動こうとしたらエラーを返す）、
ルールが禁じ手かどうか判定する、
って感じだろうか
120 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:29:02.31 ID:HJuydxx6.net]: 確かにロジック面では意義が薄いかもしれんが、表示面ではクラス化が有効だと思う。

設計の仕方はいろいろあるけど、一般論として柔軟性を確保しつつ短くてシンプルなコード
になることが一番大事だわな。

で、何をもってシンプルというかが知識量や技術力によって違うだけだと思う。

例えば、ある性質を伝えてもらうとして、普通のエンジニアには微分方程式で示されたほうが
シンプルで使いやすいと思うけど、文系の人はExcelの計算シートで示されたほうが分かりやすい
と思うのかもしれない。
121 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:30:10.54 ID:MqC7NAR1.net]: >>117
駒の動きを表現する方法はどう考える？
金の動きは概念的には分かるけど、金クラスに問い合わせたときにどうやって返すんだろ？
配置が決まっていないならマスとして返すことはできない。
金オブジェクトは配置されたマスの情報まで持っているとするのか？
122 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:39:44.99 ID:KWV9l2rU.net]: 駒は相対的に移動できる箇所を返して
はみ出た部分とかを判定・表示するのはUIの責任かなと
123 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:49:52.11 ID:MqC7NAR1.net]: 電王戦に参加する将棋ソフトという想定。
>>8-9
124 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 11:04:15.23 ID:3Uom60Ul.net]: >>114
盤にひも付いてない
盤は駒の位置しか知らない
どちらもルール
125 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 11:05:23.92 ID:RnjmzRnq.net]: 将棋を知ってるやつなら飛角香と合駒まで考えが及ぶはず
126 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 12:00:09.01 ID:MqC7NAR1.net]: >>122
>>123
とすると、どうなる？
127 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 12:18:23.72 ID:3Uom60Ul.net]: 駒は自分がいるマス目と
動ける範囲を知っている
128 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 12:53:57.88 ID:63gTfooz.net]: 駒は条件判断の材料なだけでその後の処理は駒の担当ではないから、条件判断しやすい型にする
Javaならenumにしてメソッド追加するならgetDisplayName()程度

将棋盤は9*9のマトリクス情報と手数、棋譜情報(
駒、FromPos , ToPos、時間のリスト)を保持するデータクラス

Playerは持ち駒と評価情報とか。この辺は思考ロジックが分からないから適当だけど打ち筋の傾向とか情報があれば保持って感じでデータクラス
129 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 13:12:22.20 ID:3Uom60Ul.net]: 棋譜と時計は独自クラスを持つ
持ち駒は持ち駒台があるし
盤の一部だと考える
130 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 14:06:20.72 ID:MqC7NAR1.net]: なんとなくは分かるんだが、明確には分からない。
以下のケースのそれぞれの場合に、どのクラスのメソッドを呼び出して、
そのメソッドはどのクラスのどんな情報を参照するのか説明して欲しい。
①盤上のすべての合法手を列挙する。王手放置などはしないようにする。
②ある駒が移動できるマスを列挙する。
③あるマスに移動できる手を列挙する。大駒を取れる手があるなら優先的に考慮するとかあるだろう。
131 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 14:21:18.72 ID:MqC7NAR1.net]: >>128の例を書こうと思って書き始めたけど、文章で書くよりUMLを書いたほうが早そう…。

①合法手をどのクラスに問い合わせるのか？
②盤、駒、ルールはクラスとするのか？駒には金は合計4枚とか複数枚あるけど
それぞれごとにオブジェクトがあるのか？、
③盤、駒、ルールの間の参照は？
といった点について考えを聞きたい。
132 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 14:28:22.36 ID:MqC7NAR1.net]: 合法手のルールとして

駒ごとの動き。
縁にあれば動きが制約される。
他の駒によって動きが制約される。
二歩による制約。
王手放置は禁止。
打ち歩詰めの禁止。

とかいろいろあって、駒だけに関係するものから盤全体に関するものまで
レベルがいろいろあるのをそれぞれどのクラスに担当させるんだろう？

>>125とするなら
駒ごとの動き。
縁にあれば動きが制約される。
は駒オブジェクトが返せるけど、他を考慮するには盤の情報が必要。
上の2つは駒クラスに担当させるのか、それともルールクラスが担当するのか、などなど。
133 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 16:55:28.98 ID:9b+rCIOV.net]: どういう方向性で組むか次第だろうが…

実際の将棋であればルールを知っているのは棋士であって、駒台を含む盤や駒はすべて表示のためのものに過ぎないんじゃない？
目隠し将棋の例がある様に、盤や駒などは将棋というゲームを成立させる必須条件ではないよな

情報を分散して持つのは将棋の様な評価すべき選択肢が多い場合には多くのオーバーヘッドを生むため処理速度的にも好ましくないと思う
134 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 17:07:40.64 ID:3Uom60Ul.net]: >>128
合法手は「手」クラスのメソッドに問い合わせる
2. は手が駒クラスのメソッドに問う
1. は2を全駒に問い合わせた後、ルールでフィルタして完了
3. も1の後、マス目でフィルタすれば完了

＞大駒を取れる手があるなら優先的に考慮する
のは駒でなく手や形勢判断とか上位クラスの責務
135 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 17:08:56.70 ID:3Uom60Ul.net]: >>129
1. 「手」に問い合わせる。手は盤、駒、ルールに問い合わせる
2. クラスにする。1枚1つで、40枚の駒は40個のオブジェクト
3. 盤と駒は相互に参照。手はその2つとルールを参照。
136 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 17:09:22.17 ID:3Uom60Ul.net]: >>130
＞合法手のルールとして
前半3つは駒と盤
後半3つはルールと手が判断
137 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 17:10:02.02 ID:3Uom60Ul.net]: >>131
目隠し将棋はプレイヤーへの表示を
UIでカットしてるだけで
内部処理的には盤と駒（の概念）が必要

なお処理速度は考慮せず
スレタイに沿って純粋にOOだけ考えている
138 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 20:47:21.69 ID:9b+rCIOV.net]: >>135
>>1にはそういうアホな事すんなって書いてあるぞ？w
駒や盤面なんかUI部分を除けばビットフラグの集合で事足りる、内部処理をリアルの構造と同じにする必要なんかないだろう
だいたい>>132-134を忠実に実行したら1手指すまでに何回の移譲が入るのよ？

内部処理に関して言えば効きテーブルや過去の棋譜データの探索等の棋士の脳内の思考の動きを分析してオブジェクト化してコンポジットした方がなんぼかまし

OOP自体は否定しないが、ダメ設計は迷惑だ
139 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 20:51:02.12 ID:cinc5ABC.net]: >>108
自分の意見を正当化するために必死すぎるだろ
if文の条件1つとっても仕様が無いのにどうやってソースだけで判断するんだ?
死ねよ
140 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 22:33:58.92 ID:KWV9l2rU.net]: >>136
委譲の数についてはそこまで気にすることはないのでは？
もちろ�
141 名前：fメテルの法則なんかは意識しないとだけど パフォーマンスの話をすると早すぎる最適化の議論が絡んでくるからややこしい 必要なら全部出来たあとにロファイルとってやろうねってことになる []: [ここ壊れてます]
142 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 22:44:47.80 ID:3uAWtRHV.net]: >>137
正当化もなにも、もともと
>>73
>コーディングの仕方でテスト項目は変わらない

この発言に対する反論としてホワイトボックステストを挙げただけだよ

かなり脱線してOOと関係無くなってるからこの話題はもういいよ
143 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 23:32:23.85 ID:cinc5ABC.net]: >>139
でも変わらないんだぜ
ちゃんと仕様に基づいた意味のある条件分岐であるなら
どう組んでもチェック項目は絶対同じ数と内容になる
増えたりも減ったりもしない
記述する場所が違うだけ
だから反論にはなっていない

もし違うのであればそれは違う仕様のものを作っているんだよ
144 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 23:57:23.45 ID:MqC7NAR1.net]: う～ん。よく分からん。
しっかりした設計者なら自分の理解をUMLでモデリングするんだろうなと思った…。
145 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 23:58:26.59 ID:Q91V44dw.net]: 同じ「駒」でもロジック部分とUI 部分じゃ持ち方が異なって当然でしょ。
てかそのためのモジュール分けだと思うんだが。
UI とは独立に最適化できるっつーのがこういうモジュール分けの良いところな訳で。
146 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:02:22.14 ID:qX3K4vQy.net]: >>140
> どう組んでもチェック項目は絶対同じ数と内容になる
そうでもないというか、その発想は抜けがあるよ。
たとえば数値が偶数か奇数かを文字列で返す関数があったとしよう。

function foo(value) {
　　return (value % 2 == 0) ? 'even' : odd';
}
これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。

だけどさ、関数の中身がこうなっていたらどうする？
（1レスに収めるためにわざと改行せずに一行にしたけどそこは無視して）

function foo(value) {
　　var i = value % 10;
　　if (i == 0) return 'even'; if (i == 1) return 'odd';
　　if (i == 2) return 'even'; if (i == 3) return 'odd';
　　if (i == 4) return 'even'; if (i == 5) return 'odd';
　　if (i == 6) return 'odd'; if (i == 7) return 'odd';
　　if (i == 8) return 'even'; if (i == 9) return 'odd';
}

わざとバグを入れたけど、バグが無ければこの関数は仕様どおりに動くしfoo(0)とfoo(1)のテストにも通る。
だけどこの関数にはバグがあるし、だからチェック項目は2つでは十分ではないということになる。

コーディングの仕方でチェック項目数は変わらないっていうのは、半分は正しい。
もし2つあるコードのどちらも同じぐらい正しい品質であればその通り。
だけどこの例の場合は違う。2つのテストでは足りないということになっている。

この例のあるべき姿はチェック項目数を増やすのではなくて、コードをリファクタリングしてシンプルにすること。
そうすることでチェック項目は2つになるわけだが、ここまでの話で明らかなように
「コーディングの仕方でテスト項目は変わる」というか「悪いコードだとバグがないことを担保するためのテスト項目は増える」
147 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:06:33.20 ID:IPFd2Mdr.net]: >>143
これはコードがアホだとテストも必要って言ってるだけのような。
一般論としてここまでアホなコードに対応することを要求するのは違う気がする。
148 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:11:25.02 ID:qX3K4vQy.net]: >>144
これはわかりやすい例にしたからアホに見えるけど似たようなことはある。
もう一つの例が関数やコードのコピペ。

関数やコードがコピペされていると本来一箇所でいいテストを
何箇所でもやらないといけないはめになる。

テスト項目っていうのは無駄なコードがないという前提で仕様書から起こされている。
だから無駄なコードがあれば仕様書から起こしたテスト項目をテストしてもテスト項目が足りない。
正確に言えば理論上テスト項目は足りるはずなのだが、それでは品質を担保できないという現実に直面する。

だからテストする前にコードに無駄がないかを見ないといけない。
コードが想定通りでないとテストしても想定どおりの品質を保つことが出来ない。
149 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:15:44.44 ID:NmrKPHaw.net]: >>136
盤や駒をクラスにするのは
責務の分散協調の結果だが
OOの設計を知らないのは分かった

まあ将棋のように仕様が固定しているなら
高速化を重視するのはいいが
RPGのように仕様変更が想定できる場合
構造化で済ましてると書き直しで汚くなる
150 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:16:54.66 ID:IPFd2Mdr.net]: >>145
これあるいはこのようなバグによりテストができていないことが判明した場合、
テストが漏れていると判定するか、コードがおかしいと判定するかということ。
条件の境界のテストが漏れているのはテスト漏れだと思うけど、コード固有の境界線のテストが不十分だった場合
本来の仕様とは違うことを境界線にしているコードがおかしいと判断すると思う。
151 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:22:21.92 ID:NDe+tfkH.net]: >>143
> function foo(value) {
> 　　return (value % 2 == 0) ? 'even' : odd';
> }
> これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。

テストは仕様を満たすかどうかを確認するのが目的だから想定される入力を出力を
出来れば全部それが無理なら適当に間引いてテスト項目を作る必要がある
仕様が良く分からないけど入力は正の整数なのか自然数なのかあるいはもっと別か
きちんと仕様を確認した上でないとfoo(0)とfoo(1)の2つで十分とは言えない
152 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:23:27.91 ID:qX3K4vQy.net]: >>144
逆に無駄なテストっていうのもある。

たとえば、入力画面に数値入力項目が複数ある。

たとえば「原価」「定価価格」「値引価格」みたいに。
で仕様書では、それぞれの入力項目は数字しか入力できないこと。
という仕様だったとする。

このテストに「原価」「定価価格」「値引価格」の三箇所を
それぞれ数字しか入力できないことをチェックするのか？ということ。
同じ画面ならば省こうと思うかもしれないが、
これが違う画面にある「年齢」だったらどうするか？

仕様書から起こせば、それぞれの項目でチェックしようってなりそうだろう？
だけど開発者がこれらを、数値入力項目用の汎用コンポーネントで実装すれば
数字しか入力できないというテストは無駄でしかない。
・・・が、開発者が馬鹿で、一箇所だけ普通の入力項目を使って
独自で数字のみ有効なんてコードを書いていたら？
153 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:27:08.04 ID:IPFd2Mdr.net]: >>149
テストスクリプトとしては数字以外が入力されたらエラー処理がなされることを確認する以外の対応がむしろないな。
154 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:27:39.75 ID:qX3K4vQy.net]: >>147
> これあるいはこのようなバグによりテストができていないことが判明した場合、
いや、だからテストは通ったって書いたじゃんｗ

テストは通るけど、バグがある場合があるんだよ。
そして、テスト仕様書自体は正しく、コードが間違っている。

だから正確に言えばコードによってチェック項目が変わるのではなくて、
そのチェック項目では、コードに問題がないことを担保できない。

チェック項目が十分かつコードにも問題がないことを担保するには
あらかじめコードのチェックが必要って話。

もし「コードの方を直さない」ならば、コーディングによって
問題がないことを担保するための、チェック項目は変わってしまう。
155 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:31:00.69 ID:IPFd2Mdr.net]: >>151
概念的にはテスターとコーダーは違う人。
テスターは仕様の境界でテストするのであって、コードの境界でテストすることをようきゅうするのはおかしい。
テスターとコーダーが同一人物であったとしたらコーダーがアホだとテストが漏れるのはどうしようもない。
156 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:35:08.33 ID:qX3K4vQy.net]: >>152
担当範囲がおかしいかどうかは議論するべき所じゃないよ。
問題が起きた時に誰に責任があるかの話なんかするつもりはない。

今話しているのは、こういう問題をどうやって解決するか

現実の話として、コードのコピペ等によって
仕様書から起こされたテスト項目では、バグがないことを担保できない場合がある。
（逆にコードが汎用化されていたりで、無駄なテストをしている場合もある）

バグがないことを担保するにはどうするか？
コードのレビューを行って、コードに問題がないことを
確認するしかないだろうね。

それをしないならば（つまり開発者の書いたコードを信用するならば）
コードにバグがないことを担保するためのテスト項目数は変わってしまう。
（ついでに言えば、どういうテストをすればいいかはコードを見ないとわからないので、やっぱりコードのレビューが必要）
157 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:37:15.86 ID:IPFd2Mdr.net]: >>153
コードの条件がおかしい場合にテストで検知できるかって話。
要件にしたがってテストしていれば分かる。
要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。
どうやって検知すんだ？って話。
158 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:40:13.45 ID:IPFd2Mdr.net]: コードレビューで問題が見つかったらコードを直すだけ。
テスト漏れだとは思わない。
もちろんテスト項目として追加するなら追加して。
でも、テストが漏れていたとは思えない。
159 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:42:01.42 ID:9Sgsnltg.net]: 後で拡張することが無い部分をswitchで書くのは全然問題無いと思うが。
どこにOOによる拡張性を持たせるかが問題になるから、要件とか設計からの要請で判断するべき。

Expression Problemで明確になることだけど、
OOPは子クラスを新たに追加するのは簡単な一方、新しいメソッドを追加するには既存のソースを変更しないといけない。
親クラスに共通の処理を書いたとしても、他と違うことをしたい子クラスの数だけ変更箇所が散らばる。
どの子クラスがオーバーライドしてるのかを把握するのに手間がかかるし、
追加するメソッドによってはクラス階層を更に分けてコピペを減らすべきかもしれない。

enumとswitchを使っている場合は逆になって、メソッドの追加や変更部分は一箇所にまとまっていて把握と追加が楽。
新しい種類のデータを追加するのは面倒。

ちなみにHaskellの型クラスやOCamlのvariant typeを使うとデータの種類も処理の種類も楽に増やせる。
Javaだとジェネリクスを使えばできないことはないけど、汚くなる。
160 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:42:37.96 ID:qX3K4vQy.net]: >>154
> 要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。

だからそのどうしようもないことが、現実として起きてるんだよ。

開発者の言う「このコードは汚い」というのはそういうこと。
コードの無駄やコピペがあって、本来十分であるはずのテスト項目では
バグがないことを担保できない。

言い換えると、コードに問題がある場合のバグは、仕様書から起こしたテストでは検出できない。
バグが検出できない（問題ないと判断される）のだから、当然コードの問題もテストでは検出できない

> どうやって検知すんだ？って話。
コードレビュー以外にも検知する方法はあるぞ。
コードメトリクス（複雑度）の測定や
コードの重複の検出ツールなどを使えば良い。
161 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:45:18.72 ID:IPFd2Mdr.net]: >>157
コーダーがアホ過ぎたらそういうことも起きるって言ってるじゃん。
そこまでアホなコーダを想定してテストしろって要求するのはおかしいって話。
コーダーが犯すあらゆる過ち対応したテストを作成するのは不可能。
162 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:46:19.41 ID:IPFd2Mdr.net]: >>157
ツールがあるならコードを直そうね。
テストが漏れていると思うのはおかしい。
>コードレビュー以外にも検知する方法はあるぞ。
>コードメトリクス（複雑度）の測定や
>コードの重複の検出ツールなどを使えば良い。
163 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:48:15.80 ID:55Jnw5v7.net]: >>143
関係無いよね
チェック項目は増えてない
仕様書から起こす入力に対する正しい出力をチェックするだけ
164 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:50:43.52 ID:qX3K4vQy.net]: >>155
> コードレビューで問題が見つかったらコードを直すだけ。
> テスト漏れだとは思わない。
> もちろんテスト項目として追加するなら追加して。
> でも、テストが漏れていたとは思えない。

だからそういったじゃんｗ

正確にはテスト漏れじゃないが、開発者の書いたコードを素直に受け入れるならば、
コードによって問題がないことを担保するためのテスト項目は変わる。

コーディングによってテスト項目は変わるか？質問に対していうと、
「コードレビューで問題が見つかったらコードを直すだけ。」というならば
直さないならばテスト項目は変わるってことでしょう？

テスト項目を変えないためにコーディングを直すっていうのは、
テスト項目が変わる原因の一つがコーディングであると言ってるのと
微妙にニュアンスは違うけど、結果として殆ど変わらないよ。
165 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:53:04.14 ID:qX3K4vQy.net]: >>160
> 仕様書から起こす入力に対する正しい出力をチェックするだけ

それはなんのためにやっているの？

テストはバグを検出するためにやっていると思ったが、
コードに問題があると、バグを検出できないってことだよね？
166 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:53:06.73 ID:IPFd2Mdr.net]: >>161
コーディングによってテスト項目は変わるか？云々は知らない。
お前が言ってることがおかしいってだけ。
テスターは要件の境界線をテストする。
コードが異常な境界線を基準としていたためにバグを見逃していたとしてもテスターの責任ではない。
どうしようもない。
167 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:58:20.11 ID:55Jnw5v7.net]: >>163
それも違う
境界なんてものは存在しない
本来は取り得る値すべてをチェックしなければならない
でも客とテスターの間の取引で暗黙に間引いてるってだけの話
168 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:59:05.09 ID:qX3K4vQy.net]: >>163
だから責任問題の話なんかするつもり無いってばｗ

どんなコードであっても、同じテストをすれば
同じ品質（バグがない）を担保できるような話をしてるから、
同じテストをしたとしても（そのテストに漏れがなかったとしても）
コードにバグがないことを担保できないし、
コードの品質も同じにはならないよって話をしてるんだよ。

コードが悪ければ、品質を保つために必要なテスト項目は増えるし、
コードを直すことで、必要なテスト項目は減る。
（正確に言えば仕様書から起こした本来の最低限のテスト項目だけで済む）
169 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:01:46.10 ID:IPFd2Mdr.net]: >>165
責任だけの話じゃない。対応のしようがないって話。
要件上引数は正の数でなければならないとする。
ところがコードがアホで引数が100だとバグが発生するとする。
テストではそれが分からなかった。
どうすんの？って話。
170 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:03:06.15 ID:55Jnw5v7.net]: >>165
何度も言うけどソースコードからテスト項目は増えない

ソースからテスト仕様書作ってる会社なんてないだろうよｗ
171 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:07:07.95 ID:T7FoO03Y.net]: だんだん
ID:qX3K4vQy
ID:IPFd2Mdr
の主張がこんがらがってきた……
172 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:08:17.44 ID:qX3K4vQy.net]: >>166
だからテストとは別にコードレビューをテスト前に行い、
悪いコードをあらかじめ直すしかないだろ？

俺が品質ベースで考えてるから話がずれてるのか？
俺はバグがないようにすることを目標として
どんなテストが必要か？を考えてる。

だからバグを無くすためには、コードによって必要なテスト項目が変わってくる。
そしてコードを良くすることで、必要なテスト項目が減るという話をしてるんだよ。

仕様書からテストを起こすっていうのは、当然コードは見てないから
必要な（最低限の）テストは何か？だけを考えてる。
テストの効果（バグを見落とすかどうか）は考えておらず、
その効果はコードによってばらばらで、テストしてもバグを検出できるとは限らない。
この場合のテストの目的は何なんだろうかねｗ
173 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:08:59.38 ID:IPFd2Mdr.net]: >>169
うん。だからコードを直そうね。
テスト漏れじゃないね。
174 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:12:05.80 ID:qX3K4vQy.net]: >>167
> 何度も言うけどソースコードからテスト項目は増えない

それはテストの効果（バグがないことの担保）
を無視すればそうなるよね。

ソースコードからテスト項目は増えないが
ソースコードが悪ければ、その増えないテスト項目では
バグを見逃す可能性が高くなる。

テストの効果を低くしていいならば、
テスト項目は増やさなくていいよ。

そしてソースコードが汚いならばソースコードの方を直すんだろう？
なぜなら、ソースコードが汚ければテスト項目を
増やさなければならなくなるから（アレ？ｗ）
175 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:12:26.96 ID:T7FoO03Y.net]: 俺の理解
ID:qX3K4vQyの主張はコードからテストケース作る
ID:IPFd2Mdrの主張は設計書からテストケース作る

コードが設計書に書かれてることを満たしてるかどうかって
コードから作ってたらわからないのでは……って疑問が……

なぜかコードだけ、設計書だけの0か100かに見えてしまってるので
勘違いしてたらごめん
176 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:13:23.53 ID:qX3K4vQy.net]: >>170
> うん。だからコードを直そうね。
> テスト漏れじゃないね。

コードを直さないとどうなる？
同じ品質を保つにはテストを増やす必要があるよね？

えーと、それがコーディングによってテスト項目は
変わるってことだよねｗ

コーディングによってテスト項目が増えるから
コーディングを直すんだよね？ｗ
177 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:14:50.74 ID:55Jnw5v7.net]: >>169
どうにでも好きなように組んだらいいよ
チェック項目は変わらない
オブジェクト指向でも関数型でも

これが設計の本質だ
単にソースコードに書く場所が違うだけ
それがオブジェクト指向

こんなもんにマジになっちゃってどうするの?
っていうIT業界の黒歴史
178 名前：デフォルトの名無しさん [2016/06/02(木) 01:16:20.73 ID:IPFd2Mdr.net]: >>173
>>166

そりゃバグがあることが判明したらテストを追加すべきだろうね。
でも、そもそもテストが不足していたということじゃないね。
179 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:18:59.63 ID:qX3K4vQy.net]: >>172
俺の意見としては、テストとは別にコードレビューが必須であるということ。

仕様書からテストをおこすのは問題ないんだが、
そのテストで品質が保てるかどうかは
コードで左右される。

コードが汚ければいくらまともなテスト行ったとしても
それで品質を保つことは出来ない。

俺は品質を保つことを第一に考えてるので
コードを直さずに品質を保つならばテスト項目�
180 名前：ｪ増えてしまうという話をしてる。 だからテスト項目を増やさずに品質を保つために、コードを直しましょうという話をしている。 で、最初の疑問「コーディングによってテスト項目は変わるか？」の 答えは、（品質を保つことを前提にすると）コーディングによってテスト項目は変わる。 悪いコードだと（品質を保つために）テスト項目が増えてしまう。だからコーディングを直しましょう。 []: [ここ壊れてます]
181 名前：デフォルトの名無しさん [2016/06/02(木) 01:21:24.41 ID:IPFd2Mdr.net]: >>176
コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。
そんなのテスト作成とは関係ない。
182 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:23:15.23 ID:qX3K4vQy.net]: >>175
> そりゃバグがあることが判明したらテストを追加すべきだろうね。

リリースした後で、バグが有りました。すいません。ですむ会社なら
それでもいいけどさぁｗ

「ちゃんとテストしたの？」の答えに

テストは不足していません！ちゃんとテストしました！
ちゃんとテストしたのに、コードが悪かったんです！

ですむなら、それでもいいけどさぁｗ

理想の世界であれば、テストが不足してないのは事実だろうが、
そのテストで十分であるためには、コードが綺麗でなければならず、
コードが汚ければ、多くのテストが必要になるから
コードレビューをして綺麗なコードにしましょうや。
それができて初めて、テストする意味が生まれる。
183 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:24:18.99 ID:qX3K4vQy.net]: >>177
> コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。

だから何度もそう言ってるだろうが。
人の話聞けよｗ
184 名前：デフォルトの名無しさん [2016/06/02(木) 01:24:53.24 ID:IPFd2Mdr.net]: >>178
だからさ、要件の境界とは違うところでコードがアホ過ぎるせいでバグがあったとして見つける手段は？
見つける手段がないのに直そうと言っても意味ない。
185 名前：デフォルトの名無しさん [2016/06/02(木) 01:25:55.40 ID:IPFd2Mdr.net]: >>179
？？
だったらいちいち反論すんなよ。
186 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:26:39.31 ID:qX3K4vQy.net]: 俺がはテストが足りないって言ってるんじゃないんだぜ？

品質を保つことを前提にするならば、
コードが汚ければ、品質を保つために必要なテストが増えてしまうから、
まずコードレビューしてコードを綺麗にしましょうって話。

コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。
187 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:29:14.56 ID:qX3K4vQy.net]: >>181
> だったらいちいち反論すんなよ。
お前が反論してるんだろｗ
っていうかお前のは反論じゃない。
俺が言っていることと違うことをぶつけているだけ。

俺が言ってるのは、コードが汚いならば（品質を保つために）
必要なテストは増えるって話。

コードが汚くても、テストは増やさないで品質が保てるような
話をしているから、その発想は抜けがあるよってこと。
188 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:29:26.96 ID:soSMk704.net]: そんなときこそユニットテスト
コード改変の前後でエンバグしたかどうかがすぐわかります
なおユニットテストそのものの品質を保つかが課題
189 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:30:23.03 ID:T7FoO03Y.net]: >>176
了解
回答ありがとう
190 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:30:30.71 ID:qX3K4vQy.net]: >>180
> 見つける手段は？
それもテスト前にコードレビューするって何度も言ったはずだが？

汚いコードは直さないと、テストした所で効果は低い
191 名前：デフォルトの名無しさん [2016/06/02(木) 01:31:11.16 ID:IPFd2Mdr.net]: >>183
本来的にはテストは要件にしたがって動作することを確認するためのもの。
コードがきれいか汚いかとか関係ない。
192 名前：デフォルトの名無しさん [2016/06/02(木) 01:32:06.67 ID:IPFd2Mdr.net]: >>186
コードレビューで見つかったなら直せ。以上。
テストとの直接の関係はない。
193 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:33:09.51 ID:qX3K4vQy.net]: >>187
> 本来的にはテストは要件にしたがって動作することを確認するためのもの。

その確認の手間がコードによって変わってしまうんだよ。
すでにコードで例示したけど？
194 名前：デフォルトの名無しさん [2016/06/02(木) 01:33:30.12 ID:dD1ozz1q.net]: Haskellならテスト要らないですよ？
コンパイルできた時点でバグが無いことが保証されるから。
195 名前：デフォルトの名無しさん [2016/06/02(木) 01:34:23.43 ID:IPFd2Mdr.net]: >>189
コードがアホなだけ。テストではどうしようもない。
と結論が出てる。
196 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:34:39.66 ID:55Jnw5v7.net]: >>189
だから変わらないって
本来は取りうる値の範囲をすべてチェックするんだから
197 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:34:52.13 ID:qX3K4vQy.net]: >>188
「直接の関係はない」ってことは
やっぱり間接的に関係があるって認めるんだｗ

そりゃコードによって品質を保つための
テストは変わりますからねｗ

バグが有るかどうか知ったこっちゃない。
俺はテストをちゃんとやった。
テストしたのに漏れたのはコードが悪いんだ！
ですむなら良い世界だねｗ
198 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:35:31.60 ID:55Jnw5v7.net]: 勝手に間引いてるのはテスターの責任
199 名前：デフォルトの名無しさん [2016/06/02(木) 01:36:12.80 ID:IPFd2Mdr.net]: >>193
コードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。
200 名前：デフォルトの名無しさん [2016/06/02(木) 01:36:59.90 ID:dD1ozz1q.net]: これからは関数型ですよ。
Haskell以外淘汰されます。
201 名前：デフォルトの名無しさん [2016/06/02(木) 01:37:36.91 ID:IPFd2Mdr.net]: >>196
Haskellとか既に淘汰されてるんだが。

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef