オブジェクト指向システムの設計 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/22(土) 16:49:30.28

あと、故意にか無意識にか理解できなくてかわからんが、「あることが実行できるかどうか」は
実行するそのタイミングまでわからない場合が多々あるってことを無視すんじゃねぇ。
だから、「実行できるときだけQueueに入れる」なんてことはできない。

**デフォルトの名無しさん** · 2017/07/22(土) 16:54:42.27

例外に関していびつな考え方をするのは、Javaしか知らんプログラマなのかね。

あ · 2017/07/22(土) 17:03:51.73

>>744
それは場合によりけりかと。
ちょっと特殊例だけど、担保できないなら止まってるほうがマシってやつ。

Javaじゃないけど意味わからん死に方してるの見たことあるよ。
最終的にわからんから立ち会ったら、近くですっごいモーター回った時にメモリ化けてた。

>>749
モデルに持ったら、業務ロジックの改修は全部モデルがやんの？

>>750
根本的に理解してない。
実行できるときにキューに入れるんじゃない。
実行したいとキューに入れる。
それができるかどうかは、本当にOrderを処理するロジックが考えるべき事。

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

ごめん、Javaでも普通にアプリケーション/サービス/ビジネスロジック層でも例外使うの普通みたいだったわ。
http://education.yachinco.net/tips/java/08/3.html

**デフォルトの名無しさん** · 2017/07/22(土) 17:05:52.30

>>752
> モデルに持ったら、業務ロジックの改修は全部モデルがやんの？
お前の表現でいえば「Orderを処理するロジック」がやんだよ。

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

ところで、>>412ってJavaなの？俺Javaよくしらないんだけど。
俺の感覚だとassertでエラーチェックするのはゴミコードなんだが、Javaだと普通なのか？

**デフォルトの名無しさん** · 2017/07/22(土) 17:27:46.68

>>727
> 元のプログラムはassertで投げている
> これをキャッチして
こんな話初めて聞いたんだが、何の言語だとこんなことできんの？

**デフォルトの名無しさん** · 2017/07/22(土) 17:38:08.35

もし>>412が
class order {
public void decide() {
if (_state == order_state::pending) { throw invalid_state_exception; }
}
public void cancel() {
if (_state != order_state::ordered) { throw invalid_state_exception; }
_state = order_state::canceled;
}
}
という意味なら、>>577と同じコードだよね。
なんか、>>577ありえん的な流れになってる気がするが、それなら>>412もありえんってことだな。

**デフォルトの名無しさん** · 2017/07/22(土) 19:48:01.13

僕の質問に答えれば自然に答えわかるじゃろ
俺の質問優秀だからね

あ · 2017/07/22(土) 20:11:11.41

>>754
Orderを処理するロジック、が、Orderのメソッドに依存してたら、全部改修だね。
って話。
いい加減バカなの？

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

そりゃ注文IDの桁が増えたり
注文の通貨がビットコに変わったり
伝票にユーザの証明写真電子透かしで入れる仕様になったり
したら、広範囲改修だろ

てゅか、改修の範囲も依存の仕方によるだろ
依存依存ってバカの一つ覚えのように言ってるが
おまえOrderクラスimportしたら依存だとでも思ってるのか
おまえのゆう「依存がない」って南南だよ
システムのためにナカ全部json stringでやり取りする気かバカなの茶？死ぬの茶？

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

南南西北！！ポンカンチー！

**デフォルトの名無しさん** · 2017/07/22(土) 23:46:08.33

>>728
>>726でも書いたが
元のコード>>412は「assert」で例外を飛ばしている
これが何を意味しているかすら理解できないのではどうしようもない

>お前が使ってるライブラリは例外飛ばしてくるだろ？
>それはバグなのか？

当たり前だが確認として、例外を飛ばしてきたライブラリがバグってるとか、そういう話ではない
ライブラリを使っていて、ライブラリ内でassertが発生したなら
ライブラリを使っている側のコードにバグがある、ということになる
当然ソースコードを修正する、ライブラリ内でassertが発生したら、呼び出し元のコードを修正する
当たり前のこと、そのためのassert、assertはデバッグ用
assertは通常、デバッグ時にのみ有効で、リリース時には消えてなくなる
assertでデバッグ時に飛んできてた例外は、リリース時には飛んでこなくなる
だからこれに依存した分岐など、してはならない

**デフォルトの名無しさん** · 2017/07/22(土) 23:46:45.87

(つづき)
>>728
踏まえて、>>412のコードの例外は、プログラマがクラスの使い方を誤ったときに
assertを発生させて、ミスってるよ、直してね、って知らせるのが目的
これに依存してトラップして分岐とか、もともとそんな話ではない

呼び出せない状態の時は、初めからメソッドを呼び出せないように出来ないか、って話
初めから呼び出せない(例えばスコープ上見えなくなっている、など)のであれば
間違って呼び出されることもないし、そのことに関するエラー処理も要らなくなるから
>>412
> Stateパターン使うのかなとも考えたけど結局空のメソッドから
> not supported exceptionを投げるようになるだけで本質的な解決策にならない
>>417
> ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
という風なことを質問者は言っており

そんで>>425では
> せっかく静的な言語を使っているのだから動的言語のようなことはできるだけ避けたい
とも言っているので、静的型の型機能を使って、なんとかならないか？という質問なわけだ
コンパイラにチェックさせることは出来ないか？ということだ
Null許容型とかと同じようなことは出来ないか？と

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

非常に問題があって
>>762-763
は>>728へのレスじゃなくて
>>729へのレスであった
レス番を間違えてしまった申し訳ない

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

>>763
とっくにワイが答え出しとるゆうとるやろ>>429

おまえら、300レスも何しとったんや？カスか？

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

DDDかDCIを意識しつつ型クラスを使えばできる

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

そのうえで俺は>>429のようなことを否定したいのだ

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

何故なら組み合わせ爆発が起こって訳の分からんクラスが山のように出来る可能性が高いからだ
普通に考えても、状態チェックして例外投げるなりエラー返すなりassertするなりするより、手間がかかるからだ

ある状態の時、あるメソッドを無効化することを考える
状態をチェックして無効であることをプログラマに教えるコードを仕込む・・・①
状態に対応するインターフェースを定義して実装する・・・②
この時、ただでさえ①より②の方が手間がかかりそうなのに
これに加えて状態の組み合わせ爆発で訳の分からんクラスを大量生産する羽目になったら
何をしているのかもはやよくわからない

また、状態が変化してインターフェースAからインターフェースBへはどのように移行するのか
ここで、誰が移行させるのかは問わないが
今まさにインターフェースAからインターフェースBへ移行したとして
B b = nanika( a );
まだインターフェースAの変数aは生きているので
(しかも、どこでだれが、どれだけ握っているかは分からない)
状態にそぐわないメソッドを呼ぼうと思えば呼べるわけで
結局エラー処理は(するなら)必要だ、意味がない

もしくは、B b = nanika( a );を呼び出した瞬間から、aのオブジェクトを無効にしてしまう
aのコピーを作ってそれをBを満たす状態で返し、aは無効フラグを立てて、意味のないオブジェクトとする
以降aのメソッド呼び出しは全部無効
しかし、あちこちでaが握られていた場合、aが無効になってbになったことをどうやって各所に通達する？

このようなことを考えていくと、とても現実的じゃないんだわ
まぁうまくいく場合もあるかもだが、かなり限定的だ
そもそも手続き型言語は状態や順番やタイミングによって、呼んで良かったり、ダメだったり
正しく動いたり、動かなかったり、正常だったりバグったり、するものだから
根本的に解決したければ関数型言語でも使ってもらうしかないんだろう
手続き型言語で手続きそのものの誤りをコンパイラに検出させようってのは、かなり、なんというか
プログラムの並びが正しいかどうかコンパイラに調べさせる話だから、それ出来るならすごいよね～

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

誤爆を繰り返す人

数学板２つの封筒問題 Part.3 [無断転載禁止]©2ch.net
http://rio2016.2ch.net/test/read.cgi/math/1489358280/948-950

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

なぜばれたし
しかし、そっちの俺の書き込みの長文の方が、面白いと思うよ

あ · 2017/07/23(日) 10:24:24.21

>>768
なるほど。そりゃそうね。
B b= した時にはもうAは死んでる、を実現する(しても良い)ならば、Rustで書けば割と簡単。

ただ、俺はそういう扱いで色々書いてたから「お、賢いね。ありがとさん」と感心しながらRustかけたけど、
そう考えられない人にはRustはチェッカーがパラノイアじみてて使いづらいって印象を受けるとのこと。
なので、手続き型でも言語次第、書き方次第の問題ではあるよ。
あれには列挙型もあるから、カスみたいなマスク定数持たなくても良いしね。
misraに準拠してるかをよーわからんベンダのチェッカで確認しながらCで作るより余程使いやすいと思う。

**デフォルトの名無しさん** · 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
明らかに正しくないと思うよ。
思い込んで、そう動く事を意図して作ったものを、そう動くだろう、とテストする事は滅茶苦茶簡単だけど、
そう動く事を確認するなんて、そう動く事を意図して作ってるんだから当たり前の話。

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