オブジェクト指向システムの設計 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/19(水) 21:48:22.18

>>649
ここは初心者が活発に意見交換して知識を共有するためのスレッドだよ
まともな人はこんなところに来ない

あ · 2017/07/19(水) 22:54:49.71

>>656
そうなの？
キャットドアとかいう欠陥問題を揉んでるスレかと。

なんともならないとなったら壊れる奴居るとこもどっかのスレと同じだなぁ。

あ · 2017/07/19(水) 22:59:30.27

>>651
注文日オブジェクトって何者なの？
正規化しすぎたRDBみたいな話じゃん。
そんな意味のあるようで無いデータ、共通参照したら死人が増えるだけでは？
「何日以内」って誰が持ってる設定値で、誰がそれ使って処理するの？注文日オブジェクト？
密すぎると思う。分離できてそうで、全くどれも単独で存在できないじゃん。

あ · 2017/07/19(水) 23:03:03.88

>>653
ドメインモデルなら、EntityとValueとServicesに分けたら、Orderはどこに行くの？

**デフォルトの名無しさん** · 2017/07/19(水) 23:18:58.09

>>655
よろしく

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

話は変わるが、お前らこういうコード書いたらダメだからな

if (order.cancelable()) {
　order.cancel()
}

例外はなんにでもあるからそのことについてコメントはしないが、
この場合キャンセル可能と判明した直後にキャンセル不可能になる可能性がある。

if (order.cancelable()) {
　sleep 1日
　order.cancel()
}

とやれば理由がわかるだろう。

これが正しい書き方だからな

try {
　order.cancel()
} catch(e) {
　キャンセルできない場合の処理
}

**デフォルトの名無しさん** · 2017/07/19(水) 23:33:07.83

>>658
＞「何日以内」って誰が持ってる設定値で、
＞誰がそれ使って処理するの？
たとえば注文日オブジェクトが
期限日を判定するメソッドの形で持つ
キャンセルがそれを参照する

もっとていねいにやるなら
注文日オブジェクトの値から
期限日オブジェクトを生成して
キャンセルは期限日オブジェクトだけ参照するとか

どれくらいの粒度でやるかは
実際の処理がどれくらい複雑かによる

＞密すぎると思う
それはたんにひとつのクラスで
何でもやることを密だと思ってない感想

＞共通参照したら死人が増える
逆、逆

構造化だと修正に弱いから
仕様変更に対応できなくてデスマになる

**デフォルトの名無しさん** · 2017/07/19(水) 23:36:30.58

>>659
OrderはEntity
注文日とかはValue

>>661
もちろん実務では例外処理が重要になるが
サンプルコードとしては複雑になるので省略してる

**デフォルトの名無しさん** · 2017/07/19(水) 23:40:49.25

わかってないなあ

**デフォルトの名無しさん** · 2017/07/20(木) 00:13:09.93

>>664
回答まだ？

あ · 2017/07/20(木) 08:44:25.42

>>662
期限を判定するメソッドには注文日オブジェクトが必要、
期限日は別にオブジェクトとして期限日オブジェクトが必要。
それCOBOLなんかでよくあるメタテーブルとかわらんくない？

一つのクラスでやらんよ。ジョブランナーはひとつだが、例で挙げたOperaionごとに、は別クラスというか、タスクとしてアクター最初から作る。
どのOperationだとどのアクターか、ってのはジョブランナーしか本来は知ることができないものでしょ。

毎年会計周りは変わるシステムだったけどデスマ起こったことほとんどないよ。
会計屋は、会計する以外のタスク持ってないんだから。

>>663
注文がEntityなのがわからん。何故？
注文日をValueにしたからでは？

**デフォルトの名無しさん** · 2017/07/20(木) 10:39:07.21

>>653
> ファクトリに隠蔽すれば
わざわざ結合度が高いクラス同士に分割して、簡単にインスタンス化できなくなり、
なのでファクトリメソッドを用意する？
>>577のように実装すればシンプルなのに、そうやることでなにかメリットがあるのか？

> データと処理をカプセル化する
> OOの基本はDDDでも変わらない
Entity, ValueObuect, Serviceの話だよ

>>662
> たとえば注文日オブジェクトが
> 期限日を判定するメソッドの形で持つ
> キャンセルがそれを参照する
まぁ俺なら文字列比較で一行で終わらせるだろうが、無駄に複雑にして何がうれしいんだか

あ · 2017/07/20(木) 12:03:30.26

>>667
>>577はシンプルそうに見えて闇が深くないか？
例外をThrowするなら、外のCatchは本来は型指定でCatchしてるはずじゃん？
例外の種類増えないって保証も無いし、事実上はCancelを変えると、一旦全体の動作が保証できない状態に陥るかと。
そこからテストするんだろうけど、まず全体のテスト定義書き換える事になるから、全体のテスト定義の定義にあたる要件定義からテスト起こし直しでは？
自動テストかけられる方向で修正したくない？

**デフォルトの名無しさん** · 2017/07/20(木) 13:34:14.05

>>668
> 例外の種類増えないって保証も無いし
例外クラスは基底クラスでcatchできるということは理解してるか？

> 事実上はCancelを変えると、一旦全体の動作が保証できない状態に陥るかと。
Order自身は、正しくキャンセルできたかできなかったかのどちらかでしかないから、
全体の動作は変わらないと思うが

> そこからテストするんだろうけど、まず全体のテスト定義書き換える事になるから、全体のテスト定義の定義にあたる要件定義からテスト起こし直しでは？
> 自動テストかけられる方向で修正したくない？
ちょっと意味がわからない

あ · 2017/07/20(木) 18:21:23.58

>>669
基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。
>>559でいったような、否定文での条件定義と同じく、そのときに定義されていたもの、でしかない。

Orderが正しくキャンセルされたか、って、キャンセルすることができるか以上に正しくが未定義すぎる。

自動テストのくだり。
今までのロジックに一切手を加えていなくて、かつ、お互いが疎であれば、今回分の増分のテスト作って実施しつつ、過去のテストをそのまま実行すりゃ良いじゃん。
呼び出す、みたいな形だと、呼び出してる側のテストまで作り直しじゃん。

全段落含めて言うけど、実務でやらんの？

**デフォルトの名無しさん** · 2017/07/20(木) 18:30:59.84

>>670
> 基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。
いやちょっと根本認識が違いすぎて、何をいいたいのかよくわからん
君のソースには、catch () {}が10個くらい並んでるのか？

> Orderが正しくキャンセルされたか、って、キャンセルすることができるか以上に正しくが未定義すぎる。
キャンセルが完了するかしないかの二択でしょ（それ以外に致命的な以上による例外を含めれば三択だが）
キャンセルできないパターンが多少増えても、全体で見れば変わってないでしょ

> 自動テストのくだり。
> 今までのロジックに一切手を加えていなくて、かつ、お互いが疎であれば、今回分の増分のテスト作って実施しつつ、過去のテストをそのまま実行すりゃ良いじゃん。
> 呼び出す、みたいな形だと、呼び出してる側のテストまで作り直しじゃん。
まじで何を言っているのかわからんのですが
コードで説明して

**デフォルトの名無しさん** · 2017/07/20(木) 18:45:26.11

つか、依存しているオブジェクトの変更が、依存する側に影響しないようにするのが基本で、
例えばSOLIDの原則とかがあるんだろ

なんでCancelを変更したら、全体に影響するんだよ
そりゃ設計が悪いとしか言えんわ

**デフォルトの名無しさん** · 2017/07/20(木) 18:52:06.11

例外もそう

勝手に既存の例外クラスツリー/群と全く関係ない例外クラスなんか作るなよ
Validatiorライブラリ作ってるんなら、
class ValidatorException extends RuntimeException {}
を継承したOutOfBoundsValidatiorExceptionを追加しろ

で、Validatorライブラリのクライアントは、基本的にはValidatorExceptionかRuntimeExceptionをcatchしろ

あ · 2017/07/20(木) 19:25:21.13

>>671
え？どー言うこと？Exceptionなんかでトラップしたら静的解析にすら怒られるだろ。
FileNotFoundExceptionなのか、とかトラップして、定義外はアプリケーションレベルのハンドラまで飛んでプロセス殺すよ。

それでも既に3択じゃん。
キャンセルには、キャンセル後に承認が必要になった、なんてときには、キャンセル呼んでる所全部直してくの？
キャンセル出来た訳ではなくなるよ。キャンセル処理は完了したんだろうけど。

そもそも正常系を例外で処理すんな。

テストの事。
....cancel()が、メソッドで、かつ、例外を吐くならば、
呼び出し元のtry-catchやってる、例えばCartやらUserやら、そのクラスも必ず再試験でしょ。
CardやらUserを再試験するならば、システム全体の結合試験もやり直しだわな。
かつ、その試験仕様は、要件が変わったんだから、試験仕様やソース以外からつくる他ないだろ。
サブシステムやデータクラスの問題が、システムの問題になる。

例外吐くんだから。例外って端的に言えば大域ジャンプだぞ。

>>673
アホか。

**デフォルトの名無しさん** · 2017/07/20(木) 19:37:01.08

例外は極力クラス内で殺したい
モノによったらゼロは難しいかもしれんけど外に迷惑かけたらやばい

プログラムの例外を逃がすだけでリアルの俺が殺される

**デフォルトの名無しさん** · 2017/07/20(木) 20:48:26.88

>>667
同じことの繰り返しになるから
ひとつだけ言うと

＞Entity, ValueObuect, Serviceの話だよ
Value Object はメソッドを持つよ
データと処理をカプセル化する

Services は処理専門だけど
Entity と Value Object だけで扱いづらいものだけ
Services を例外的に適用するのであって

Value Object をメソッドを持たない
たんなるデータの入れ物にして
Services から処理するのは
手続き的なアンチパターンで
DDDのやり方ではない

**デフォルトの名無しさん** · 2017/07/20(木) 22:30:58.38

インスタンス生成の処理は
ファクトリに隠蔽すれば
クライアントは依存関係や
コンストラクタについて知らなくてもいい

これ意味わからん
コード書いてみてよ

**デフォルトの名無しさん** · 2017/07/20(木) 23:38:17.62

よくわからんが、order.cancel();　が出来るってことは
orderオブジェクトはそのメンバにシステムへのリンクを持ってるってことか？
class order
{
　　system s;
　　void cancel()
　　{
　　　　s.cancel( this );
　　}
};
↑これなんかすごく筋悪くね？
system.cancel(order);
で良くね？
cancelの処理がオーダーだけで完結するとは思えんし
俺の中でorderがレシーバーとなってcancel処理っていう発想がない

で、order.is_cancelable();　も何か変で、キャンセルできるかどうかは
orderクラスだけで決まることではないし、キャンセルできるかどうかのフラグを
orderに持たせていちいち更新するのも変な話だな
そもそも、orderが何でそんなこと知ってるんだ

ただ、キャンセル中かどうかなどのステート値はorderに持たせて良いと思うけど
他に置き場ないし

**デフォルトの名無しさん** · 2017/07/20(木) 23:39:43.75

主従関係が逆転した考え方は嫌いだな
プログラムは明確にトップダウンなほうが読みやすい
手続き型プログラムにはデータ構造と制御構造の二要素しかないんだから
それぞれ組み立てたうえで、それらをどのように割り振るかってことだけ
考えとけば変なことになりようがないと思うんだけど

あと「誰が処理するべきか」って発想がダサくて、そりゃ誰かと問われれば
処理するのは何時でもコンピュータだわな
そうじゃなくて、本来は　「どこへ書くべきか」　だろ？
発想の転換というか、本来のあるべき考え方を取り戻すというか
現実を正しくとらえないとな

**デフォルトの名無しさん** · 2017/07/20(木) 23:45:13.58

俺が全てを知ってるんだから
俺オブジェを作ろう
ore.god

**デフォルトの名無しさん** · 2017/07/20(木) 23:47:19.71

どこへ書いておけば後々楽かなぁ～ってことだけ考えとけばよく
誰が処理するか、とかワケワカランことは考えなくてよし
これで大体迷子になっている人が多い印象、2chみてる限りはね

**デフォルトの名無しさん** · 2017/07/20(木) 23:47:26.83

>>680
そのオブジェは邪魔なのでお片付けしちゃいましょーね～

**デフォルトの名無しさん** · 2017/07/20(木) 23:48:59.86

>>681
そうやって君はコントローラーやセービスにたくさん手続き書くんだろう？
それじゃオブジェ志向にはなれないだよ

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

すべてを知ってるのにファクトリ隠蔽をご存じないのはおもしろいですね
カプセル化としても大切なポイントなのに

**デフォルトの名無しさん** · 2017/07/20(木) 23:59:13.34

別にそういうわけでもないけど

でもよ、書かなきゃならないコードの総量は決まっているわけよ
必要な機能を削るわけにはいかないからな
とにかく、それは、決まってるから、初めから

それを分割してどこへ書くかってだけの話で
無理に小さなオブジェクトへ不必要にコードを押し込んでも意味無いっつーか
自然な形で実装できればそれでよし
自然が一番

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

あぁ、「小さなオブジェクト」ってのは変な表現だな
「末端のオブジェクト」でおねがい

**デフォルトの名無しさん** · 2017/07/21(金) 00:26:40.80

自然な手続き型至上主義の老害ガイジいるかぎり
日本の未来は明るいな

**デフォルトの名無しさん** · 2017/07/21(金) 00:27:36.02

> でもよ、書かなきゃならないコードの総量は決まっているわけよ
> 必要な機能を削るわけにはいかないからな
> とにかく、それは、決まってるから、初めから

これ読んだだけで程度がしれるからすごい

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

あと、SSE用、AVX用、AVX2用、AVX512用、と
プログラムのメイン部を4つも用意するのはマジ勘弁なんで
その辺も含めてコンパイラのループのSIMD展開に頑張ってもらうしかないと思う

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

そういった煽りには何かこう、イラッとすら来ないんだよ
何言っても無駄なのは知ってるし
囚われてる的な何か
自分で気づくまではどうにもならない類

迷路を自分で作って自分で解くのには飽きた
ただそれだけ

**デフォルトの名無しさん** · 2017/07/21(金) 06:50:23.04

糞設計糞コード糞重複
↓
でもよ、書かなきゃならないコードの総量は決まっているわけよ
必要な機能を削るわけにはいかないからな
とにかく、それは、決まってるから、初めから

ガイジか？

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

コード総量がどーのって方は固定値取得とかエラー処理、ログ出力のような汎用的な処理も毎回コピペしてるんだろうか
そして毎回同じテストをしているのだろうか

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

>>691
クソコードクソ重複が
お前にとっては「書かなきゃならないコード」
ってことかい？ｗ

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

俺も最後にするわ

>>676
> DDDのやり方ではない
ルールをどこに実装するかの話で、あ氏はデータがルールを持つのに納得できないというので、
DDDではServiceにルールを実装することもあり、DDDの話を持ち出したまで

**デフォルトの名無しさん** · 2017/07/21(金) 10:43:54.11

>>674
> そもそも正常系を例外で処理すんな。
ケースバイケースだしポリシーの話でもあるね
>>577でも「例えば例外をthrow」って書いてるだろ？

俺がそれに関して今君と話したいのはここね
>>670
> 基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。

> テストの事。
> ....cancel()が、メソッドで、かつ、例外を吐くならば、
> 呼び出し元のtry-catchやってる、例えばCartやらUserやら、そのクラスも必ず再試験でしょ。
まぁ別に再試験してもいいが、しなくてもいい
なぜなら、
class Exception;
class ServiceException extends Exception;
class OrderServiceException extends ServiceException;
class OrderCancelNotAllowedException extends OrderServiceException;
という例外クラス群だったとき、CartやUserは、ServiceExceptionやOrderServiceExceptionなんかで
catchすべきだから

> CardやらUserを再試験するならば、システム全体の結合試験もやり直しだわな。
OrderCancelNotAllowedExceptionを作成する前後で、全体として何かがかわったわけではない
まぁ、やり直してもいいけど

> >>673
> アホか。
何がアホなのか全くわからない
君と会話する意義がゼロに近づいてるぞ

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

話がかみ合っていない

おそらく基底クラスの認識がズレてる

あ · 2017/07/21(金) 13:09:10.34

>>695
例外をスローってのは、もうどうしようもない場合だろ。

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

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

APIとしてシンプルが売りって、それ呼ぶときだけで、ハンドリングは全然シンプルじゃないじゃん。

あ · 2017/07/21(金) 13:14:58.39

見た目上疎なのと、実際に疎なのは全然違うし、
大雑把にしか取らなくて良いのと、大雑把にしか取れないのは全然違う。
未来の定義を含んでるから大きく取る他無い、って設計として柔軟なんじゃなくて、設計としてあやふやなんじゃん。

ある意味、そいつが責務として無責任な返事をしてて、その後始末を使う側に押し付けてるように見える。

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

そもそもの質問の題意からかなり外れてしまっているように思えるんだが
こういう風にかくも脱線するのがOOPなのかしらね

平たく言えば、もともとは
メソッドが正しくないタイミングで呼ばれたら、どう対処すべき？
って質問だったろう
で、明確な答えなんかないだろう
例えば、a=10; b+=a; って書くべきところを順番を間違えて b+=a; a=10;　って書いたら
正しくないタイミングで処理したといえるわけだけど、コンパイルエラーも実行エラーも出ないし
それが我々の日常で、ただのバグであって、手続き型言語というのは何時でも順番が大事で
正しいタイミングで処理が走るように気を付けて書くものだったろう
一方で、順番を間違えたためにバグってヌルポやdiv0が発生することもある
ただしこれはどうしても続行が不可能だから例外を飛ばしているわけであって・・・
あとほか、初期化前の変数を参照しようとして怒られるとか、もあるが

基本的には手続き型言語は処理の順番の権化なので
処理する順番を間違えたとか、変なタイミングでメソッドを呼んだとか
それはプログラマのポカ、バグ、なんだから、テストで炙り出すしかないだろう
こんなことを全部が全部丁寧に例外なんかで対応していたら
手続き型言語はすべての個所で順番が重要なわけだから、全てでチェックが必要になる
順番やタイミングを誤って良い場所など、無いと思ったほうが良い

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

しかし、丁寧に作るなら
明らかにおかしなタイミングやおかしな順番で呼ばれたら例外を投げるのは有り
ただしそれはプログラマがミスをしたことを早期に伝えるためであって
そこで条件分岐などして通常フローに組み込んだらまたおかしなことになる
まぁほどほどに

っていう程度の話なのに、それが何故
何処でキャンセル出来るかどうか判断するか、とか
キャンセル処理は何処でするか、とか
認可がどうのこうの、ジョブがどうのこうの
とかって話に派生するのが謎だわ

ある意味では面白い問いかけでは有ったと思うよ
手続き型言語で「手続き」を間違えた場合、どう対処するか？っていう
そのままバグるのか、例外投げるのか、エラーコード返すのか、何もしないのか
好きなのを選べ

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

俺が思うに
「呼び出し元のプログラムがバグってて誤ったタイミングや順番でメソッドが呼ばれた場合
　どう対処すべきか」
っていう問題と
「仕様上、今現在キャンセルできる状態なのかどうなのか、また、どこで判定するのか」
という別問題を混同して一度に扱おうとするから
話がややこしくこんがらがっているのではないか

**デフォルトの名無しさん** · 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だと普通なのか？