オブジェクト指向システムの設計 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/21(金) 15:22:03.43

>>697
> 例外をスローってのは、もうどうしようもない場合だろ。
トランザクションをコミットできないような事象は全て例外でハンドリングするというポリシーもありえる

> ServiceExceptionに新しい小クラス作ったなら、それは元のServiceExceptionではないんだから、テスト範囲膨大になんじゃん？って話。
だから基底クラスでcatchしろって話なんだが

**デフォルトの名無しさん** · 2017/07/21(金) 15:35:40.87

>>701
> 「呼び出し元のプログラムがバグってて誤ったタイミングや順番でメソッドが呼ばれた場合
> 　どう対処すべきか」
そんなこと話してた奴いたか？

**デフォルトの名無しさん** · 2017/07/21(金) 15:38:37.36

>>697
> 前提として変わってるよ。....NotAllowed....で拾ってたなら、具体的にはNotAllowedのうちのあれとこれとそれを拾ってた訳なんだから。
> 大きくCatchして、その中で各サブクラスごとの処理してた時に、新しいサブクラスのハンドリングはすべきか否か、ってのが、仕様として考え直しだろって話。
全く意味がわからん
コードで説明して

**デフォルトの名無しさん** · 2017/07/21(金) 15:52:10.73

>>697
> 大きくCatchして、その中で各サブクラスごとの処理してた時に、
ちょっと待てよ、そんなこと誰もしないぞ

つか、君、SOLIDのことはわかってるんだろうな？
まさかとは思うが、ポリモフィズムすら知らないなんてことはないよな？

**デフォルトの名無しさん** · 2017/07/21(金) 16:01:34.64

ずいぶん前から何度も訊いてる>>422,434,455,527んだが、なぜ答えてくれなんだ出題者よ

**デフォルトの名無しさん** · 2017/07/21(金) 16:14:55.54

手続きおじさんに触れるとめんどくさいよ

**デフォルトの名無しさん** · 2017/07/21(金) 16:41:22.90

>>703
>>412を100回読めばわかるが
もともとは
「実行できない状況でメソッドが呼ばれたら、どう対処すべき？」
って話だろ
で、実行できない、処理を続行できないので、例外投げてますよ、というだけの

実際彼は
> ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
> ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
とも言っているわけで、呼ばれてはいけないタイミングで呼ばれたら、どう対処すべき？って話なんだよ
呼んではいけない状況で呼ぶな、バグるから呼ぶな、は手続き型の基本であるが
まぁ安全のために例外でも飛ばしておこうと

それを>>416が
> 値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
と余計なことを言うから話がややこしくなって脱線したわけだが
実際には cancel() がどこに実装されていても関係ないわけよ
本質は、キャンセル出来ない状況で cancel() 呼ばれたらどうすんの？例外飛ばすの？
例外であふれかえるんだけど？
って質問なんだから、どこに実装されていても関係ない
そしてこんなことは手続き型プログラミングではありふれている一般的な話題であって
(手続き型なんだから手続きを守ってもらわないと困る)
ジョブとか認可とか、以降の話は、まるで脱線

**デフォルトの名無しさん** · 2017/07/21(金) 16:45:33.11

いうなれば
「初期化メソッドが呼び忘れられている状態でオブジェクトの他のメソッドが呼ばれたら
　どう対処すべき？例外飛ばしとくべき？例外であふれかえるんだけど？」
っていう質問と同義なんだよ

**デフォルトの名無しさん** · 2017/07/21(金) 16:54:46.20

>>708
> もともとは
> 「実行できない状況でメソッドが呼ばれたら、どう対処すべき？」
> って話だろ
そうだが、バグってそうなったらという話じゃないと思ったが

> って質問なんだから、どこに実装されていても関係ない
そんなことないって延々話が続いてたわけだが

あ · 2017/07/21(金) 16:57:09.68

脱線も何も一番大事だと思うけど。

まー、理解できないなら仕方ないわ。
DTOオブジェクトにメソッド持たせたりとか、過去やった事として悪手だと言ってるんだが、
多分使いたくて仕方ないんだろ。

**デフォルトの名無しさん** · 2017/07/21(金) 16:58:59.38

>>709
> っていう質問と同義なんだよ
俺は全然違うと思うけど、OOに詳しくないと同じに見えるのかもね

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

大体からしてキャンセルできない状態であれば
画面上のキャンセルボタンは無効になっているか表示されてないか
ともかくキャンセルのオペレーションは実行できなくなってるはずなんだよ
もし無理やり飛んできても、どこかの段階で弾く
それなのに cancel() が呼ばれるってのは基本的にプログラムがバグってるんだよ
だからキャンセルできない状態なのにcancel()呼ぶな、バグるから呼ぶなって事になるが
それでもプログラマの不注意で呼んでしまうかもしれないので
安全のために例外でも飛ばしておきましょう
そうすれば早期に気づくでしょ、ってこと
だからassert()みたいなものだな

**デフォルトの名無しさん** · 2017/07/21(金) 17:13:00.06

>>710
>そうだが、バグってそうなったらという話じゃないと思ったが

バグらずにそうなるってどういう状況だよ
実際にcancel()呼んでみて例外が飛んできてから
「あぁ今キャンセルできない状態みたいだからゴメンって画面に表示しとくか」
ってプログラムあり得るか？
キャンセルできる状態かどうかは事前にチェックしてて
それに合った画面表示になってるだろ
それでもcancel()で例外が飛ぶことはあるだろうが
それは本当の実行時エラーだ
少なくともキャンセルできない状況というのが事前に判明しているにもかかわらず
実際にcancel()呼んでみて例外が飛んでくるかどうかで判断とかあり得ないだろ
だからキャンセルできない状態でcancel()が呼ばれるってのは単純にバグってるんだよ
その辺をケアするかどうかの話だろ

**デフォルトの名無しさん** · 2017/07/21(金) 17:15:35.17

>>713
> 画面上のキャンセルボタンは無効になっているか表示されてないか
> ともかくキャンセルのオペレーションは実行できなくなってるはずなんだよ
そんなことないから、どこで/誰がキャンセル可能かどうかを判断すべきかって話になってるんだが

・ブラウザで注文一覧を見る
・見ている間に発送処理が完了する
・注文キャンセルを行う
・サーバが注文キャンセルリクエストを受け取る
みたいなときとか

厳密に言えば、
if (isCancelable()) {
　　doCancel();
}
がアトミックでなければ、「発送」が途中に滑り込む可能性もある

**デフォルトの名無しさん** · 2017/07/21(金) 17:46:44.99

手続きの主張は「例外出させるプログラムを組む人が悪い」なので話は通じないよ

ここはできるだけヒューマンエラーを排除するための考え方を話す場所なのにね

**デフォルトの名無しさん** · 2017/07/21(金) 20:12:55.82

>>715
それは本当に防ぎようのないことだから例外投げるなりなんなりすればよいが
もともと質問者はそんな質問はしていないだろ？
そんなことをどうにかしてくれって言ってるわけじゃないだろ？

>>412のコードを見てもそうだし
>>417でも
> ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
> ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
って言ってるだろ
「呼んではいけない処理を容易に呼べてしまう」
って書いてあるだろ？
これは要するに、「呼んではいけない状態の時に呼んではいけないメソッドを呼べなくする方法はないものかね？」
って質問しているわけだよ
それが出来ればプログラマが呼び出しミスすることを原理上なくすことが出来て
ここが大事だが、「その類のエラー処理を書かないで済むので」
> ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
のを防げるんだけども？っていう質問をしているんだよ
呼んじゃならない状態ってわかりきってる時でも、呼んじゃならないメソッドが呼び出せちゃうから
それに対するエラー処理書かなきゃなんねーメンドクセーなんか良い方法ない？って質問なんだよ
だがそれは手続き型言語に対する挑戦でもあるから程々にって俺は思うが、そのことはまぁどうでもよい

それで>>453なんかは質問者の意図を理解してスレの流れを元に戻そうとしているし
>>706なんかも質問者の意図を理解しつつ、探っているだろ

とろこが若干約二名は全然質問の意図と関係ないことを延々と長時間ものすごいレス数で
いったい何やってんだ？
こんなのがプロジェクトに交じってたら会議がいつまでたっても終わらないし
これがもし顧客の質問だったのなら、もうあいつは連れてくるなってなるだろ
全然違うこと言いだして知識をひけらかしあって何がしたいんだ？

**デフォルトの名無しさん** · 2017/07/21(金) 20:15:16.81

> 何がしたいんだ？

そんなもん自覚できてるわけねえだろｗ
もししててもさすがに発表できないだろｗ

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

引っ込みどころを見失った手続きおじさん

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

>>717
> 全然違うこと言いだして知識をひけらかしあって何がしたいんだ？
知識ひけらかしあってって、すげー低レベルな話しかされてないんだけど。
嫌なら飛ばせよ。

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

>>717
> それに対するエラー処理書かなきゃなんねーメンドクセーなんか良い方法ない？って質問なんだよ
結論としては、オブジェクトのメソッド内部でチェックをして、例外で（エラーコードでいいけど）
返せってことでしょ。

手続き型だって、正常時が戻り値0、異常時がマイナスの値だったら、
if (hoge() < 0) {
some_error_process();
return;
}
some_process();
と書いて、hoge()のエラーの種類が増えても大丈夫なコードにするだろ？
それと同じだよ。

あ · 2017/07/22(土) 10:53:36.41

>>716
そんな事言ってないぞ。
正常にキャンセルに失敗したならば、そりゃ例外じゃなくて結果だって。

あ · 2017/07/22(土) 10:56:40.54

>>719
引っこむ必要もわからん。
とりあえず、手続き型ではないオブジェクト指向であれば、ロジックは例外ありきで作るべきなのかってのは気になる。
例外ではなく、メッセージパッシングに使ってるなら、それは例外の濫用では？と。

あ · 2017/07/22(土) 11:02:24.71

>>721
やらんだろそれは。
if(hoge()==0){
　some_process();
}else{
　some_error_process();
}
return;
じゃねえの？
正常値があってのエラーなんだから。正常時は0なら、今も未来も正常値は0であるんだから、そっちを判断基準にすべきじゃん、って話。

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

0以外も正常値の場合はどうするの？

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

まだやるのかよ
もともとの>>412のコードよく見てみろよ
「assert」って書いてあるだろ
assertで投げた例外をトラップしてフローを切り替えるとか、あり得ないだろ
だから元々からして例外をトラップして処理を切り替えるって話じゃない
エラーコードが良いか、例外が良いか、も関係ないし
もしC言語だったならassertに引っかかったらabortして終わりの話
その後の後処理のことなんかまったく関係ないし、むしろ関係させてはいけない
assertに依存してその後の流れが変わるプログラムとかあり得ない、バグったことが分かればそれでよい
だから>>721も>>724も関係ない　(しかも言ってることがどうでもよい)

assertで投げてるからにはこれはデバッグ用のコード
プログラマがクラスの使い方を誤ったときにassertで引っ掛けて知らせるのが趣旨
これを書くのが面倒だから、そもそも、呼ばれても困るときに、呼べないように出来ないか、と言っている
俺じゃなくて本人が>>417で言ってる
>　ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う

呼べてしまうから対応が必要になるので、呼べないように出来ないか、という話
呼ぶべきじゃない状態の時は、呼べなくしてしまってもかまわない、ということは、実行時エラーの話ではない
トライしてエラー捕まえる、そんな話ではない、元から呼べなくしてしまって構わないと、本人が言っている
Null 許容型とかそっち系の話
君らがしているのはNullチェックの仕方の話であって、質問者が言ってるのは
Nullを許可しないにはどうしたらよいか？のような話

話がおかしな方向に行ったのは>>416の
>値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
からで、その考えに賛同しないわけじゃないし、むしろ好みであるが
だが今は関係が無い、ここでおかしくなった
そして無駄に300レスを消費したわけだが、話している内容はOOPでは何時もの事だが
「何をどこに書くか」であるが、このような宗教的話題は、ひとまず今は関係無かった、趣旨ではなかった
レイヤーが全然違った、もっとプリミティブな質問だったわけだ

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

>>721
↑がまずまだ間違っている
問題の趣旨を全く理解していない
元のプログラムはassertで投げている
これをキャッチして分岐する処理を制御フローに組み込んで出荷するのはあり得ない
if (hoge() < 0) {
some_error_process();
return;
}
some_process();
↑こんな話ではない
例外が飛んで来たら、ああ、バグ仕込んだな、コードを修正しなきゃ、って話であって
キャッチして対処する話ではない、エラーコードで分岐する話でもない
assertレベルの話だ

それに対して>>724がまた本当にどうでもよいことを言い出す
会話を長引かせることしか考えてないのか？

あ · 2017/07/22(土) 13:50:17.99

>>725
要件に無い。無いことをむしろ書くな。

>>726
ああ、これは読み損ねてた。すまん。
assert出したら死ぬってことだな。そりゃそっちが正しい。

いや、呼べてしまうから、呼べないようにしたい、に対してをずっと言ってるんよ。
呼ぶんじゃなくて、呼びたいとキューなりなんなりしろ、と。
そしたら、呼びたいというのは自由になる。
そのタスクは、「呼ぶ人」一人がさばいて、呼べませんでしたよと端的に残す、と。それは呼ぶことのエラーじゃなくて、呼ぶ人の、呼びたいキューに対する結果だよ、と。

だから、データに生やしたメソッドでやるのは、そのデータ一人が対応できる処理に限ろうね、って話に行き着くから、データ自体でロジック書かないでおこうね、って話だよ。

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

> 例外が飛んで来たら、ああ、バグ仕込んだな、コードを修正しなきゃ、って話であって

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

お前が使うライブラリは例外を飛ばすのに
なんでお前が作るライブラリは例外を飛ばさないんだ？

例外の使い方間違ってるだろ

あ · 2017/07/22(土) 13:52:41.06

オブジェクトができる事なんか知れてんだから。
無理と言うかどっかで歪んでくる。
最初からそんなデータと処理を分割できなくなるような書き方するな。と。
結論「無謀」なの。

OrderRunnerとか、OrderQueueを作ることに何が問題なのかわからん。

あ · 2017/07/22(土) 13:56:18.40

>>729
横からだが、ライブラリが例外を飛ばすなら、ロジックではそれはトラップしてるべきかと。
どーしよーもないやつはトラップすべきでないので、最初からトラップしない。リスローもしない。では？
DiskFullやらOOMやらハンドルしても無駄でしょ。今現時点のスナップショットが正しく落とせるかすら不安な状態で無理に生き残っても意味ない。
ランタイムまで飛ばしてランタイムごと落ちるべきだと思う。
まさか21世紀になってABENDを見るとは思わなかったが、割と業種によってはあると思う。

あ · 2017/07/22(土) 13:58:25.52

そう言う意味では当たり前みたいな、このライブラリではかならず○○Exceptionのサブクラスをスローします、みたいなライブラリはゴミだと思う。

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

>>731
お前がどれだけライブラリの例外を知っているのか知らんが、
例えばデータベースに接続できないとか
ファイルが無くてオープンできないとか、
そういうのも例外だからな

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

>>731
> DiskFullやらOOMやらハンドルしても無駄でしょ。

え？ DiskFullだったら「ファイルを消して再実行してください」
って表示するべきじゃないの？ｗ

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

OOMは例外じゃないから的はずれなｗ

あ · 2017/07/22(土) 14:01:38.79

>>733
だから、そんなのオープンするときにハンドリングしろよ。
オープンできなけりゃ死ぬなら、死ねばいいんだし、
リトライやらなんやらするならそいつがやれ。
gotoやらlngjmpの代わりに使うな。

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

>>736
なにをそんなに熱くなってるのか知らんが、
殆どの例外はやろうと思えば復旧可能
例えバグによって発生したものであっても
そのバグの間接的な原因（変な値を入れない）をユーザーが
取り除いて再実行できる。

あ · 2017/07/22(土) 14:05:47.85

>>734
あー、ごめん、それは例が広すぎたな。
ユーザがすぐにリアクションできる操作でそうなりゃ、問い合わせれば良いけど、ファイルを消して再実行が間に合わんままシステム動き続けて、メモリにも乗らなくなる可能性があるなら、最初からCatchすんなと。
そう言う意味では上の方でDiskFullExceptionを握ってるやつが居たら死ねと思う。

ってか、容量ぐらい先に確保できるか確認して、確保できなければエラー、確保できれば確保してから書いてケツを整えたら良いんでないの？

あ · 2017/07/22(土) 14:07:42.06

>>737
それは、例外でやるべきじゃなくて、チェックロジックでやるものでしょ？って。
自分が壊れたもの自身が「自分はリカバリできました！」って言う事ほど信用ならん事はない。

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

>>738
（自分の都合がいい場合）は例外じゃなくていいって言ってる？
都合がわるい場合は例外とかダブルスタンダートはよせよｗ

> ってか、容量ぐらい先に確保できるか確認して、
はい。ダメなパターンｗ

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

>>739
> 自分が壊れたもの自身が「自分はリカバリできました！」って言う事ほど信用ならん事はない。

自分が壊れたものを、他人が直せるわけ無いだろ？
何を言ってるんだ。

あ · 2017/07/22(土) 14:12:48.02

>>735
実行時例外だっけ。OutOfMemoryErrorでCatchはできるけど。

あ · 2017/07/22(土) 14:16:20.98

>>740
お前何言ってんの？
都合が良いも悪いも、そんなもん、例外としてなげるんじゃなくて、ハンドリングしてからやれ、っていうライブラリ側の話と、
ユーザが、っていう業務ロジックの話を混同してるからじゃねえの？

>>741
当たり前だろ。
おもなしく死ねって言ってんだよ。
おとなしく死んだらまともな奴が代わりを立ち上げるし、
それでも死んだらデータが悪い。

まともな奴が判断しろ。

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

>>743
代わりを立ち上げるのなら、
そのまま起動し続けたほうがよくね？ｗ

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

正常＝＝０て
ペチパーの人達が死にそうだねｗ

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

ウイードーズでさ
デスクが満杯エクスペクションになったら
エラーメッセじゃなくて
ショットダウンしていいのか？

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

>>745
PHPのベースとなってるのはC言語で、
そのC言語は0 = NULL だから
0は偽として扱う必要があるんだよね。

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

こんな無駄な討論ばっかしててよく会社クビにならないな。

設計の粒度とか一貫性なくて、大規模で開発したら崩壊しそう。

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

>>728
> いや、呼べてしまうから、呼べないようにしたい、に対してをずっと言ってるんよ。
> 呼ぶんじゃなくて、呼びたいとキューなりなんなりしろ、と。
お前こんだけ話が続いてて一切進歩ないな。
呼べないようにするって話と、要求をQueueで管理するってのに全く関連性はないぞ。

> だから、データに生やしたメソッドでやるのは、そのデータ一人が対応できる処理に限ろうね、って話に行き着くから、データ自体でロジック書かないでおこうね、って話だよ。
だから、その範囲のビジネスルールはそのデータがもつmodelなんかに実装しましょうねってことだ。

**デフォルトの名無しさん** · 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

オブシコきっしょ