オブジェクト指向システムの設計 172 [無断転載禁止]©2ch.net

uy ◆e6.oHu1j.o · 2016/07/09(土) 00:35:13.95

前スレ
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/

**デフォルトの名無しさん** · 2017/07/23(日) 11:10:31.68

>>762
> assertでデバッグ時に飛んできてた例外は、リリース時には飛んでこなくなる
> だからこれに依存した分岐など、してはならない

という意味で、>>412は最悪のコードですな。

**デフォルトの名無しさん** · 2017/07/23(日) 11:15:15.03

>>768
> そもそも手続き型言語は状態や順番やタイミングによって、呼んで良かったり、ダメだったり
> 正しく動いたり、動かなかったり、正常だったりバグったり、するものだから

どういうプログラミングパラダイムだろうと、時間経過によって状態が変更しうるものの前には無力。
「事前にチェックして」「処理を実行する」が失敗するケースが発生しうる。

同時実効性や時間経過による変化、トランザクション分離レベルなどを考えないと、ベストな選択はできないだろう。

**デフォルトの名無しさん** · 2017/07/23(日) 11:28:38.08

>>763
> 呼び出せない状態の時は、初めからメソッドを呼び出せないように出来ないか、って話
> 初めから呼び出せない(例えばスコープ上見えなくなっている、など)のであれば
> 間違って呼び出されることもないし、そのことに関するエラー処理も要らなくなるから

以上の理由で、上記のような実装を行えるのは、ごく限られたケースであることがわかったと思う。
今回はOrderを例にして話が始まったが、Orderは上記実装とは相容れないもの。

**デフォルトの名無しさん** · 2017/07/23(日) 11:32:00.27

もしかして君らおじさんたち
契約プログラムを知らない無知蒙昧なるゴミ屑なのかな？

**デフォルトの名無しさん** · 2017/07/23(日) 11:37:23.87

２、3人しか会話してないしそうだろ

**デフォルトの名無しさん** · 2017/07/23(日) 11:41:56.66

契約プログラミングでも、「キャンセルしてはいけない注文をキャンセルしようとする」というタイミングは発生しうる。

**デフォルトの名無しさん** · 2017/07/23(日) 12:02:34.67

>>768
CanceledOrder
DecidedOrder
は例が悪かったかも知れない

こうならどうだ
/** 予約系(チケットとか実体のない)注文 */
TicketOrder
/** 配送系(モノであり実体がある)注文 */
DeliveryHealthOrder

両者で、持ってるデータが大きく異なる場合は、
型で分けないとその「組み合わせ爆発」で状態の判定ifがそれこそ爆発する
「組み合わせ爆発」が嫌で汎用性が高いクラスを作りたいというなら
全てHashMap<Object, Object>で作ればいい
になるぞ

程度問題だ

あ · 2017/07/23(日) 12:28:22.68

>>773
「経過時間」の本質は「自分以外が触るデータ」であるか否かかと。
なので、データの分類は
自分だけが作れて、他人も見れるデータ（このデータは誰も編集禁止）
自分だけが作れて、自分だけが編集出来て、自分だけが削除できる、他人からは見る事が出来ないデータ
誰にでも作れるが、自分だけが見れて自分だけが削除できるデータ
の3つに切ると、やりやすい。

メールボックスみたいな仕組みがある言語なら要らん定義だけど。
Erlangは凄いわ。

**デフォルトの名無しさん** · 2017/07/23(日) 13:14:07.92

>>779
アーアン言語ってたまに聞くね
その３つの仕組みをどういう仕組みで実現してるの？

あ · 2017/07/23(日) 14:17:16.20

>>780
プロセスかアトム ! メッセージ
の形でメッセージ送るだけ。
もらった方は
recieve
　{pattern,match} ->
　　処理
って感じで処理する。
返事が要るなら、
recieve
　{From,pattern,match} ->
　　処理
　　From ! 返事

みたいに返せる。
プロセス内の変数はもともと持ち出し不可。
自分が作れて云々は自分からのメッセージで、
誰にでも作れて云々は自分へのメッセージ。

**デフォルトの名無しさん** · 2017/07/23(日) 21:38:14.62

>>778
それは言ってることが全然おかしい
今言ってるのは状態依存で呼べる機能が変わるものに
それぞれ別々のIFを用意するかどうかだ

**デフォルトの名無しさん** · 2017/07/23(日) 21:51:23.25

例えばボタンクラスを定義するとして
EnableButtonClassとDisableButtonClassを用意しよう
で、ボタンが死ぬまで上記のどちらかで固定されるなら別に構わないが
実際にはボタンはEnableだったりDisableだったり動的に切り替わる
こうなってくるとディメリットがメリットを上回る

**デフォルトの名無しさん** · 2017/07/23(日) 21:54:27.39

まぁ例がちょっとアレかもしれんがね
そのようなこと

**デフォルトの名無しさん** · 2017/07/23(日) 22:01:50.55

例えが下手杉内
ボタンクラスをどこかの処理に渡したいことなんてあるか？
オーダーとは全然別物だろ

抽象化が下手なやつはゴミみたいなPG書くって相場が決まっているもんだが
こりゃお里が知れるね

**デフォルトの名無しさん** · 2017/07/23(日) 23:07:58.39

ん？ボタンクラス作るって言ってるんだから
GUIフレームワークも自分で作る前提だろ
ただ、そんなこと自分ですることあまりないから例がアレとは思うが

それでもボタンを例を挙げたのは、既存GUIプレームワークのボタンクラスは
そうはなってないでしょ？って例になるからだけど
じゃなきゃ、また「俺はこうする、俺はこうする」って話になって
無駄に300レス消費するのは嫌だなぁと

**デフォルトの名無しさん** · 2017/07/23(日) 23:58:40.42

？

**デフォルトの名無しさん** · 2017/07/24(月) 01:52:16.41

よほどのことが無い限り悪手だから心配するな
>>429

あ · 2017/07/24(月) 08:40:24.40

フォーム上の物に例えるならリッチテキストの中身のRTFDocumentとかかな？
リッチテキストとして成立しないものはリッチテキスト側で制御すべきだけど、
選択文字に打ち消し線を打つってのはリッチテキストのメソッドで、いつでも呼べる。

ただ、業務ロジックとして、この行には打ち消し線を打たせない、ってのをやりたいなら、フォームかラッパーにもたせるべきだけど、
そのラッパーを状態ごとに「無効:DisabledRText」とか「上長承認済の為スタンプのみ押せる:StampableRText」とか作るってんなら明らかに悪手。

最初から、コピー新規しかできなけりゃ何も問題は無いんだけど、編集って概念が出てくるととたんにSQLで言うSERIALIZABLEみたいなトランザクションにせざるを得なくなる。UIオブジェクトに。c#ならsynclockかなんかでできるんだっけ？

**デフォルトの名無しさん** · 2017/07/24(月) 13:14:09.75

>>779
> なので、データの分類は
> 自分だけが作れて、他人も見れるデータ（このデータは誰も編集禁止）
> 自分だけが作れて、自分だけが編集出来て、自分だけが削除できる、他人からは見る事が出来ないデータ
> 誰にでも作れるが、自分だけが見れて自分だけが削除できるデータ
> の3つに切ると、やりやすい。
ほんと筋が悪いわ
それこそが、上の方の認可とか権限とかの話だろ

あ · 2017/07/25(火) 01:45:37.04

>>790
全然違う。カプセル化そのもの。
メモリ共有をせずにメッセージの受け渡しで処理を勧めていく。

あのさぁ。認可と同じとか、くだらんことほざく前に
Erlangでのメッセージの渡し方は見てきた？
技術力もなければ知識もなく、そして論理的思考力も無く、ソースの探究心すら無いならプログラマ辞めたらいいのに。

**デフォルトの名無しさん** · 2017/07/25(火) 07:01:29.77

…と、このハズいコードをドヤ顔で出してくる厚顔無恥が言っています
http://ideone.com/yvttId

あ · 2017/07/25(火) 08:25:35.37

>>792
あー、書いたねこれ。

**デフォルトの名無しさん** · 2017/07/25(火) 10:09:39.54

>>791
> 技術力もなければ知識もなく、そして論理的思考力も無く、ソースの探究心すら無いならプログラマ辞めたらいいのに。
お前はそれに加えて文章力が壊滅的にない

あ · 2017/07/25(火) 13:06:11.86

>>794
うん、まぁ、これでちゃんと仕事して金もらえてるんだから、必要充分でしょ。
あんまり身の回りで通じなかったこと無いよ。文章。
よく読めば最初に言ってたりするのに、急いで斜め読みしてるように見えるが。

**デフォルトの名無しさん** · 2017/07/25(火) 13:28:14.85

話が伝わらないのは、自分の文章力のせいだとつゆほども思わないのかね

**デフォルトの名無しさん** · 2017/07/26(水) 09:50:10.66

やーいゴミ

**デフォルトの名無しさん** · 2017/07/26(水) 22:31:24.22

うるせーウンコ

**デフォルトの名無しさん** · 2017/07/27(木) 01:44:55.23

すげーなこのスレ。文章レベルが小学生だな。
プログラムレベルは、ただのコーダーよりはマシだけど、リーダーにするには経験も頭も足りない微妙な人ばっか。

仕事の憂さを晴らすために、議論ごっこしてるだけw

**デフォルトの名無しさん** · 2017/07/27(木) 06:50:02.93

と思う小学生だったとさ。

**デフォルトの名無しさん** · 2017/07/28(金) 07:32:41.72

オブシコきっしょ

あ · 2017/07/28(金) 07:42:36.79

小学生以上の文章レベルの議論はまだかね。

**デフォルトの名無しさん** · 2017/07/28(金) 09:35:35.04

注文のキャンセルの話は終わった？
終わってないね。

で結局キャンセルできるかどうかを判定する
メソッドはどこに作ることになったの？

まずキャンセルできるかどうかっていうのは
状態によってだけじゃなくて、権限によっても決まってくる。
でも状態の権限の２箇所で判定するのは面倒。

例えば、キャンセルボタンがenabledなのかdisabledなのかっていうのは
キャンセルできるかどうかで変わるわけだけど、
ビューに if (キャンセルできる？ && 権限がある？）などと書いてしまったら
こういうのがあちこちに散らばってしまう。ために権限の事忘れたりね。

だから if (キャンセルできる？) と条件一つにしないといけない。
このキャンセルできる？の中には権限のチェックなどすべてのチェックが入っている

**デフォルトの名無しさん** · 2017/07/28(金) 10:54:05.35

>>803
キャンセルの「可能/不可能」と「許可/不許可」をいっしょにしてはいけない。

あ · 2017/07/28(金) 14:51:46.75

終わりで良いと思ってたが。

不許可だから不可能なのか、不可能だから不許可なのかは組み合わせだすとキリがないよ。

可能不可能と許可不許可だけで4つ、それに、結果的に不可能だった、とか過去形や未来形、次承認あれば許可みたいな新しい状態に対応するときに、累乗に比例していってしまう。
しかも結果はできる、できないの二択。

なら、最初からそのオペレーション自体を切り分けて、例えばキャンセルなら権限ごとのできるできないを、
前工程で作ってしまって、単純にそれを取得するだけにした方が責任範囲がはっきりする。

**デフォルトの名無しさん** · 2017/07/28(金) 15:01:29.67

>>805
可能か不可能かは、注文のビジネスルールにより決定される。
許可か不許可は、権限管理のビジネスルールにより決定される。
（要件によっては、注文のビジネスルールとする場合もあるかもしれない）

最終結論は「{許可 or 不許可} & {可能 or 不可能}」だ。

なにをごちゃごちゃ言ってるのか理解不能。

**デフォルトの名無しさん** · 2017/07/28(金) 17:02:21.40

バーカバーカ

**デフォルトの名無しさん** · 2017/07/28(金) 23:19:41.57

>>804
例えばさ、ショップの管理者であれば、
すべての注文のキャンセルが可能でしょ？

一般の顧客は、通常は自分の注文しか
キャンセルできないよね？

これは権限？

**デフォルトの名無しさん** · 2017/07/29(土) 10:38:10.64

>>808
権限だろ

**デフォルトの名無しさん** · 2017/07/29(土) 10:46:36.37

>809
権限だとしてその権限の条件は？

自分のIDと注文のIDが一致しているか？っていう
条件を何処かでやらないといけないよね？

**デフォルトの名無しさん** · 2017/07/29(土) 10:47:10.63

× 条件を何処かでやらないといけないよね？
○ 条件判定を何処かでやらないといけないよね？

その条件判定はどのメソッドにあるの？

**デフォルトの名無しさん** · 2017/07/29(土) 10:47:36.61

orz

× その条件判定はどのメソッドにあるの？
○ その条件判定はどのオブジェクトのメソッドでやるの？

あ · 2017/07/29(土) 11:07:06.69

>>806
違うんじゃねえの？
権限管理のビジネスルールで可能で注文のビジネスルールで不可能、は、結局どのビジネスルールに縛られてるのか、もう少し種類増えたら優先順位が出てくるはずじゃん。
許可されてるから可能なのか、可能だから許可されてるのかって話。
今2つだから単純な話で済んでるけど。

○○の、と頭につけずに、ルールの積によって可能か不可能で判断するほうがいいんじゃないの？

**デフォルトの名無しさん** · 2017/07/29(土) 11:45:07.76

>>813
言い方を変えよう。
注文のビジネスルールによる可/不可を「可能/不可能」と呼び
権限管理のビジネスルールによる可/不可を「許可/不許可」と呼ぶとしたとき、
「可能/不可能」と「許可/不許可」をごっちゃにしてはいけない。

> ルールの積によって可能か不可能で判断する
そのように説明したつもり。

> 今2つだから単純な話で済んでるけど。
増えたとしても、「それまでの判定結果」×「新しいルールによる結果」でしかないので、
組み合わせ爆発のような問題は起こらない。

**デフォルトの名無しさん** · 2017/07/29(土) 11:47:54.33

>>812
> ○ その条件判定はどのオブジェクトのメソッドでやるの？
権限管理オブジェクト

**デフォルトの名無しさん** · 2017/07/29(土) 11:54:40.25

>>815
> 権限管理オブジェクト

権限管理オブジェクトが、注文の情報に依存するってこと？
具体的に言えば、権限管理オブジェクトが注文オブジェクトの
チェックメソッドを読んでいるってこと？

**デフォルトの名無しさん** · 2017/07/29(土) 11:56:51.52

>>813
> 今2つだから単純な話で済んでるけど。

そうなんだよね。

今は権限、特定のユーザーの情報だけで決まる話ばかりしてるけど、
他人の注文は取り消せないが、自分の注文だけは取り消せるみたいな
権限＋ビジネススールの組み合わせで判定することもあるわけだ

**デフォルトの名無しさん** · 2017/07/29(土) 12:08:18.12

>>817
> 今は権限、特定のユーザーの情報だけで決まる話ばかりしてるけど、
> 他人の注文は取り消せないが、自分の注文だけは取り消せるみたいな
> 権限＋ビジネススールの組み合わせで判定することもあるわけだ
だからこそ、「可能/不可能」と「許可/不許可」はごっちゃに考えてはいけないと何度言ったら。
「可能/不可能」の実装は注文オブジェクトに、「許可/不許可」の実装は権限管理オブジェクトに、だ。

**デフォルトの名無しさん** · 2017/07/29(土) 12:16:47.13

>>818
いや、カプセル化の考え方からすると、
権限管理オブジェクトの中で何やってるかは隠蔽されてるものなので
権限管理オブジェクトの中でビジネスロジックを呼んでいたとしても、
使う側からすれば、同じようにみえるわけですよ。

そもそも権限管理オブジェクトっていうのは名前が間違いで
一つの「権限＋ビジネスロジック」管理オブジェクトとするべきなのですよ。

そしてその中で権限管理オブジェクトやビジネスロジックオブジェクトによる
チェックをするべきでしょうね。場合によってはここでどちらとも関係ない
チェックが入るかもしれません。例えばメンテ中で閲覧しかできないみたいな。

話が見えてきましたね。
あなたは全てを「権限管理オブジェクト」にごっちゃにしてはいけないと言ってる。

私は「権限管理オブジェクト」にごっちゃにはしてない。
ただし「権限管理オブジェクト」やビジネスロジックやその他を扱うオブジェクトを
統括する別のオブジェクトを作って、そこでごっちゃにしろと言ってる。

**デフォルトの名無しさん** · 2017/07/29(土) 12:20:56.80

ちなみに、ごっちゃにするメリットは
何かの処理ができない時、その理由がなにであるかを
意識する必要が無いということです。

理由は関係なく、単純なできる？できない？で表せるので
条件を書くところが少なくなって、コードがシンプルになります。

**デフォルトの名無しさん** · 2017/07/29(土) 12:25:24.83

class Rule {
public Rule (Order o, Kengen, k) {/*いつもの*/}
public cancel(){}
}

これでドヤ？
ワイが一番頭良いと思った

あ · 2017/07/29(土) 12:42:22.90

>>814
違う、ごっちゃにしたくてしてる訳ではない。
考えるのがめんどくさいからでも、混同してる訳でもない。
逆に、同じものに対する力の強さを、言葉を変えて別定義するのがおかしい。本質的には同じ物なんだから。
列挙するとまるで別のように見えるし、実際そういうシステム見たことあるが、闇が深すぎて設定だけで何人日かかるんだよこれってシステム。

力の強さにするか、ビットマスクにするか、列挙としてたくさんの積や和が可能な型とするかはおいといて、
それらは全部同じ結論の「可能/不可能」を表していて当然だと思う。

増えたとして、って、おかしいよ。今までの判定結果が、今回の判定結果と優先順位が違えば、増えた分全部再テストだよ。

システム整合性　
在庫
オペレーター

みたいな3層のチェック条件に、負在庫を許すマネージャーなんて層を足したら、それは今までのシステム整合性→在庫→オペレーターの3層のチェックのどこにどう挟む気なの？

あ · 2017/07/29(土) 12:43:43.48

>>819
正しい。

**デフォルトの名無しさん** · 2017/07/29(土) 13:30:56.05

>>823
レス番間違えてない？
ワイだろ

あ · 2017/07/29(土) 13:45:51.87

>>824
うまく揶揄して笑えるコード書いてたらレスするが、そのネタ何回目やねん
天丼にわろたるほど暇ちゃうぞ。

**デフォルトの名無しさん** · 2017/07/29(土) 13:48:21.39

>>825
日本語でおｋ

あ · 2017/07/29(土) 13:52:27.31

>>819の折れない心は凄いが、ホントその通りで
>>421で最初に言って、>>647で重ねたように、俺もそいつがそいつだけで行えるチェックに関しては混ぜろとは言ってないんよね。

あ · 2017/07/29(土) 13:52:38.01

>>826
やかましわ

**デフォルトの名無しさん** · 2017/07/29(土) 14:18:53.75

>>819
> 権限管理オブジェクトの中で何やってるかは隠蔽されてるものなので
同じように、注文オブジェクトの内部のビジネスルールは隠蔽すべきではないですか？

> あなたは全てを「権限管理オブジェクト」にごっちゃにしてはいけないと言ってる。
違います。
注文そのものに対するビジネスルールと、それ以外（たとえば権限によるルール）をごっちゃに
してはいけないと言っています。

> ただし「権限管理オブジェクト」やビジネスロジックやその他を扱うオブジェクトを
> 統括する別のオブジェクトを作って、そこでごっちゃにしろと言ってる。
注文オブジェクトには、一切のビジネスルールの実装をしないということですか？
それには同意できませんね。

>>822
> 本質的には同じ物なんだから。
いえ、違います。オブジェクトの責務の話です。

**デフォルトの名無しさん** · 2017/07/29(土) 14:38:07.32

何が嫌いかよりコードで自分を語れよ!!!

**デフォルトの名無しさん** · 2017/07/29(土) 14:57:48.59

テストの話を少ししましょうか。
void foo() {
　　if (!check1()) {
　　　　return;
　　}
　　if (!check2()) {
　　　　return;
　　}
　　if (!check3()) {
　　　　return;
　　}
　　do_something();
}
というコードがあったとき、チェックが3つあるから2*2*2=8通りのテストをするのかという話です。

{check1, check2, check3, do_something}
{true, true, true, 実行される}
{true, true, false, -}
{true, false, -, -}
{false, -, -, -}
の4通りで済みます。

つまり、N個のcheckがあるとき、テストケースはN+1個でいいんです。
10個のチェックがあるとき、2~10=1024通りではなく11通りです。
組み合わせ爆発は起きません。

**デフォルトの名無しさん** · 2017/07/29(土) 15:05:20.10

人間が仕事をするのだから
プログラムもそのモデルを模倣すればよい
Ningenクラスを作ろう
Ningenクラスを継承して
EigyoやKeiriクラスを作ればよい

ドヤ？

**デフォルトの名無しさん** · 2017/07/29(土) 16:38:06.09

>>831
組合せ爆発はどうあっても起こります。

重要なのは、テストするコストと価値を比べて
コストをかけてまでテストする価値はないという
コードにしてしまうことです。

テストしなくていい（する価値がない）コードが増えれば
テスト数の組合せ爆発を減らすことができます。
テストをしないためにはどうするかという話です。

**デフォルトの名無しさん** · 2017/07/29(土) 16:40:53.77

>>831
> の4通りで済みます。

それはホワイトボックステストであることが前提となっています。
なぜなら、チェックしている順番が1,2,3の順であることを
知っているからです。

チェックしている順番が1,2,3であるならば、
4通りで済みますが、ブラックボックステストであれば
どの順番でチェックしているかわからないので、
そのテストの個数では足りません。

**デフォルトの名無しさん** · 2017/07/29(土) 16:53:18.88

>>834
check1, check2, check3が直交してたらの話だよ
ここにさらに直交するcheckが増えても、組み合わせ爆発は起こらないことの説明

**デフォルトの名無しさん** · 2017/07/29(土) 17:04:43.91

>>835
直行しているかどうかは
ブラックボックステストではわからない

**デフォルトの名無しさん** · 2017/07/29(土) 17:12:08.75

>>836
要件が直交しているかどうかだよ。
・自分の注文しかキャンセルできない
・発送済みならキャンセルできない
これは直交した条件。

だから、ホワイトボックス・ブラックボックス関係なく、チェックの順番も関係なしに
・自分の発送されていない注文をキャンセルする
・自分の発送済みの注文をキャンセルする
・他人の注文をキャンセルする
というテストをすればいい。「他人の発想済みの注文をキャンセルする」テストは不要。

これが組み合わせ爆発が起こらない理由。

**デフォルトの名無しさん** · 2017/07/29(土) 17:20:39.67

あほコーダーが別々で実装している場合もあるかもしれないよ

**デフォルトの名無しさん** · 2017/07/29(土) 17:23:04.30

>>838
10個の条件があるときに、11個のテストでカバーできないようなコードを書くチームは、
もう何をしても無駄だと思うよ。

**デフォルトの名無しさん** · 2017/07/29(土) 19:01:54.59

>>837
> というテストをすればいい。「他人の発想済みの注文をキャンセルする」テストは不要。

残念ながらそうとは限らないんだよね・・・

if (自分の注文か？) {
　　if (発送済みか？) {
　　　　return キャンセル可能
　　} else {
　　　　return キャンセル不可能
　　}
} else {
　if (発送済みか？) {
　　　　return キャンセル不可能
　} else {
　　　　return キャンセル可能 // バグ本来はキャンセル不可能
　}
}

これは「他人の発送済みの注文をキャンセルする」場合にバグが有るコード

**デフォルトの名無しさん** · 2017/07/29(土) 19:20:58.86

>>840
自分も同じツッコミをしようとしたんだけど、視点によっては>>837も正しいなと気づいた。
システムテスト視点だと>>837で良い。
単体テスト視点だと>>840だよね。

**デフォルトの名無しさん** · 2017/07/29(土) 19:25:34.13

単体テストとか言うよりも

「バグがないという前提において不要だと判断されたパターンはテストしなくて良い」
という考えは正しいかどうかって話だよな

**デフォルトの名無しさん** · 2017/07/29(土) 19:35:29.98

テストに前提を於いたらいけないのは、その通りだよね。

ただ、システムレベルだと、禁則にあたる項目が多いのも事実で、そもそもテスト出来なかったりするじゃん？
その事を指して、テスト数爆発は無い、って言ってるのなら、まあわからなくもないかなと。

**デフォルトの名無しさん** · 2017/07/29(土) 19:44:14.29

テスト数は爆発するんだよ。どうあっても。残念ながらね。
それは認識しないといけない。

爆発してしまうテストを現実時間でどう扱うかというと
テストしないという選択肢を選ぶしか無ない

重要なのはそのテストしないという理由で
「バグがないという前提において不要だと判断されたパターンだから」は
バグを見つけるのが目的のテストとしては、テストしない理由としては適切ではない。

俺の理由は「テストする価値がないぐらい単純なものだから」
テストしなくてもバグがないのは明らかなものを作る
だからそういうものはテストしない

あ · 2017/07/29(土) 19:47:19.90

>>831
途中returnして何が積なんだよ。
そうじゃなくて、この権限ならばできる、をあとから足せる構造にせなばって言ってる。

ちなみに、普通はそれは2*2*2のテストをする。
何故ならば、どちらも、影響しないという担保を行うために。
たまにあるからね。ポインタや参照先が同じとこ向いてる不具合とか。

要はテストケースはその四通りでは足りない。
お前実務経験無いんじゃねえの？

こういう思考で間違ったオブジェクト指向を流行らせようとしてる奴こそが、本来のオブジェクト指向をディスってるような気がするわ。

**デフォルトの名無しさん** · 2017/07/29(土) 19:50:59.46

テスト項目だけで考えたら、テスト爆発するのは間違いないよね。
横から入った自分にも、その点に異論反論は無いよ。

その上で、禁則を増やしてテスト爆発を小さく抑えるってのは有効だと思うけど、その点にも同意できないの？

**デフォルトの名無しさん** · 2017/07/29(土) 19:52:02.17

禁則を増やしてってなんだよｗ
その禁則をコードにする時にバグがでるんだろうが

**デフォルトの名無しさん** · 2017/07/29(土) 19:53:07.60

違う違う。
禁則ってのは、テスト不可能な条件のこと。

**デフォルトの名無しさん** · 2017/07/29(土) 19:56:58.62

具体的にその条件とは？

もちろんテスト不可能な条件とやらがバグってる
可能性も忘れずに答えてくれ

あ · 2017/07/29(土) 20:09:17.42

>>842
明らかに正しくないと思うよ。
思い込んで、そう動く事を意図して作ったものを、そう動くだろう、とテストする事は滅茶苦茶簡単だけど、
そう動く事を確認するなんて、そう動く事を意図して作ってるんだから当たり前の話。

意図せざる動きをしないかどうか、渡せるパラメータ全部渡して確認するのがテストだよ。

**デフォルトの名無しさん** · 2017/07/29(土) 20:11:18.96

>>849
じゃあ>>840の例でいいかな。

例えば、このシステムのUIが、web系のGUIだとしたら、システムレベルだとGUI部品分の要素しかテスト出来ないじゃん？
そうすると、他人の注文にアクセス出来るのか？ってなるよね？
要件としてアクセス可能ならもちろんテストしなければならないけど、アクセス不可能ならテストしようがないでしょ。
これが禁則。

この場合、アクセス出来ないことを真っ先にテストしておけば、他人に対するテストは全部端折れる。（というか、やりようがない）

って話なんだけど、おかしい？

あ · 2017/07/29(土) 20:11:28.57

>>848
テスト出来ない状態、であるというテストは要るだろ。
そういう意味ではテストケースは減らん。

**デフォルトの名無しさん** · 2017/07/29(土) 20:14:05.02

>>852
もちろん。
でも、テスト項目を消化する作業を一気に減らせる、って意味。

あ · 2017/07/29(土) 20:15:19.38

>>851
おかしい。
挙げたように、ポインタや参照が被ってるみたいな挙動を見つけられない。
ある事をするとあることが出来なくなる、という状態を持つのであれば、さらに、状態と入力条件を全てテストするしかない。

>>853
減らない。
波及範囲の推定はその方法では不可能。

**デフォルトの名無しさん** · 2017/07/29(土) 20:15:39.71

単体テストだと、禁則はほとんど無いので、爆発するよね。

**デフォルトの名無しさん** · 2017/07/29(土) 20:16:14.28

>>854
えっ？
だって、テスト出来ないんだよ？

あ · 2017/07/29(土) 20:17:45.39

>>855
むしろ、単体レベルで爆発してるものを使うべきではない。
モジュール化できてない事の証左でしかない。

あ · 2017/07/29(土) 20:18:09.27

>>856
なら、最初からクラス分けろ。

**デフォルトの名無しさん** · 2017/07/29(土) 20:19:21.81

>>858
いや、その話がすでに単体テストの話だよね？
話が噛み合ってない気がするんだけど。。。

あ · 2017/07/29(土) 20:20:53.20

>>859
いや、総合試験の話。
禁則とか言葉で誤魔化さんと、素直に、単なるルールの優先順位と気づけよ。
それはゴッドクラスでしかない。

**デフォルトの名無しさん** · 2017/07/29(土) 20:22:24.39

>>860
だから、クラスとか関係ないんだってば。
最終的なシステムレベルでのテストの話なんだけど。。。

あ · 2017/07/29(土) 20:27:25.89

>>861
うーん、噛み合ってないな。
総合試験を作るとき、網羅度はどうやって出すの？
それが本当にやらなくても、そのメソッド呼ばれようがない、という判定は誰がどうやるの？
そして、呼ばれなかった、という悪魔の証明をどう担保したいの？

**デフォルトの名無しさん** · 2017/07/29(土) 20:40:03.01

>>862
そうだよね。
ごめん、自分が間違ってたよ。

あ · 2017/07/29(土) 21:35:46.74

こんなレベルで総合試験どころか結合試験して提出した奴は出禁にするレベルの酷さ。

**デフォルトの名無しさん** · 2017/07/29(土) 22:32:12.89

なるほど、不具合がないことを保証するための試験ではなくて、
想定された使い方をしている限り動く
変な使い方をしなければ動く
ことを保証するテストなんだな。

想定外の操作をして問題が起きたら
それは間違った使い方をしたユーザーの責任

**デフォルトの名無しさん** · 2017/07/30(日) 01:31:32.32

当たり前だろ
バカで低脳で使われるだけのユーザごときが偉そうにするな
ゴマスリしか能の無い、ちょっとコミュ力がSEより高いだけでプログラム1行も書けない下級生物は
大人しくしてろゴミ

**デフォルトの名無しさん** · 2017/07/30(日) 02:54:09.22

ひどいコミュ障の自演を見てるようだ
ID:sarQXHNa
ID:8lDGGI0L
はトラブルメーカー
言ってることは正しい
しかし、そんなことは当たり前すぎるので、更にその上の議論をしようとしている人間に対して、全く話を理解せず頭ごなしに罵倒
狭い世界でお山の大将気取ってるコーダータイプ
多分、自分は悪くない、頭の悪い周りが悪いと思いこんでいる

**デフォルトの名無しさん** · 2017/07/30(日) 03:44:40.37

>>867
んで、お前の意見は？
人に難癖だけ付けて終わんなよ

**デフォルトの名無しさん** · 2017/07/30(日) 08:39:37.81

>>865
そのシステムは扱いたくないなぁ

**デフォルトの名無しさん** · 2017/07/30(日) 10:22:01.39

>>867こいつが一番コミュ障でFA

あ · 2017/07/30(日) 13:00:21.91

>>867
その上の議論を成り立たせるためには、その下の暗示されている条件を明示する必要がある。
そして事実、勘違いしてる奴が居た。
何かそれ以上あるの？