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

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

スレ立て乙

今回はどうなるものやら

今頃流行ってんだなOOP
10年くらい前は否定派のオッサンが多くてめっちゃ肩身狭かったけど

>>3
お前の会社は可哀想だなｗ

>>3

川俣 晶さんの著書を読むと、「Ｃ＃で開発しているプログラマは、Ｊａｖａ以上にすばらしいＣ＃に満足して開発している。」
っていうふうなこと描かれているね。
あえて、ＯＯＰが良いとか、ＪａｖａよりＣ＃が良いなんて書籍やネットで騒ぐより、Ｃ＃でプログラミングしているほうが楽しいってことみたい。

ってことで、「ＯＯＰ否定」の流れにくみする人が多かったということだったのかも？

C#でコーディングしてるんだけど、呼び出した1メソッドずつtry~catchで囲め、共通化メソッド内での分岐じゃ読みにくいって言われたんだけどそんなに読みにくいの？
3分岐ぐらいしかないんだけど
1メソッドずつコピペで囲んだらなんかあったとき修正漏れとかあると思うんだけど
俺がおかしいの？
throwするとわかりにくいって怒られるし。

>>6
実際のコードがないと何とも言えん気がするが

＞throwするとわかりにくいって怒られるし。
糞無能の悪寒
その屑さっさとビルの窓から放り投げるのがベスト解決策な気がするね

C界隈出身の先輩が言う事は話半分で聞いてりゃいいよ。

>>5
むしろ10年前にOOP否定とか
他に何やってたんだ、そいつは？
最高に見通しのいい伝説の1ファイルmain()1万行とか書いてたのか？

4K40型モニタでハッ倒してやりたいね

職場の人がみんなそうで、毎日変数一つにまとめろとかクラス一つにまとめろとかいろんな人から怒られたりして気が狂いそう
javaから入ってオブジェクト指向学んだんだけど、javaと同じようにオブジェクト指向で作っちゃいけないの？
戻り値列挙型で定義したら戻り値二択にしてboolで返せって、戻り値によってswitch文で処理書いてたんだけどそれも全部捨てろって
俺そんなにおかしいもの書いたのかな？
共通化したりするとわかりづらい読みづらいって言われる

>>7
共通化メソッドって言うのは例外処理のことね
例外処理一つにまとめたら例外ごとにメッセージ出せって言われたからメソッドこしらえたら分岐とか読み辛いからやめろって
読みやすいように考えたのに、そんなダメだったかな。

>>11
簡単にでいいから書いてみ↓
https://ideone.com/

>>12
書いたらrunて押せばいいの？

>>13
Runでok
Runして表示されるページのアドレスをここに書き込めば、みんなが見れる

https://ideone.com/KbepnL
こう？

変なのだったらごめん。
あとクラス名間違えてるごめん。

レビューは的確に
誤解がないよう断定調で書く
反省を促すためにも積極的に人格否定などを織り込む
これ良いレビューの基本ね

がんばれよ糞コードヴォーイ
お前はセンスない上頭が悪くてきっとチビデブハゲブサメンワキガだけど、ここにコードを書いたガッツだけは認める
今日流した悔し涙は、明日のお前の血になる

>>6
なんとも言えんなー
ぶっちゃけまるっとtry-catchで括っちゃうと不味い場面のが多い気がする
今の職場では「ハイ例外ハイ死んだーエラーログ出てるからオッケー」
なんてノリだけどな
途中で死んで処理切り上げて抜けました後片付けは知りません
落ちて死んだりもしたけれどアプリケーションは元気です!
ってそれ不良品じゃねーか!
って気がしなくもない
DB関連の処理ならロールバックあるけど
やっぱ真面目に作ろうとすると昔ながらのc言語スタイルかなと

>>17
返信ありがとう
createメソッドとかcopyメソッドとかが出現する場所全部に入れないといけないからそういう風にしてる
throwはするなって言われたからキャッチした場所でメッセージ出力して、場合によっては戻り値返してる
こうしたくてこうしたいんじゃないけど、現状非難は浴びてるから向いてないのかもしれない

俺が悪かった
薬飲んで寝るよ

>>22
ちゃんと意見言ってくれただけでもありがたいよ。
薬飲んでるのか？
体は大事にな。
ゆっくり休んでな。

精神不安定杉内
やっぱIT業界って頭やられちまう奴多いんだなｗ

>>19
そこまで複雑な処理じゃないんだ。
最初は下位で何かあったら共通処理から上がってきて、メソッド毎に○○処理中に〜みたいなメッセージ出力してまた投げて、メインで例外処理するだけのものだったんだけど、それじゃだめだって言われて
例外発生タイミングで例外処理しろって、投げるなって
じゃあチェック処理含めてcreateメソッド囲った共通処理作ってその中でメッセージ出力したらどうだって言ったら
ややこしいからコピペで一回一回囲めって言われたんだ
伝わるかな？

>>23
ちなみにそういう時は、コードを2つ並べて書くものだ。
A. 俺はこう書いたんだが、
B. こう書けといわれて戸惑ってる
みたいに。どちらかは丸ごとコメントアウトしておけばいい。
>>15がAで、>>17がBであっているのか？

あとそれが正統Java流だと思っているのなら、とりあえずJavaスレでも聞いてみたらどうか。
もちろんここで既に聞いたことは明示して。
ちなみに皮肉で言っているわけではなく、俺では単に判定出来ないから「聞いてみれば」と言っている。
割とJavaってそんな感じで刻むイメージがあるから。

>>19
> やっぱ真面目に作ろうとすると昔ながらのc言語スタイルかなと
それはない。
C言語スタイルでは大規模アプリの例外処理は
大変すぎて手に負えなくなる。

using使え

C言語スタイルってなんぞ？

>>27
いやいや
だって例外を1番上で捕まえると
死ぬ箇所によって死に方が千差万別よ

それって折角閉じたクラスや関数であっても大ジャンプしてケツも拭かずに飛び出して来るからね

だから例外を一括で処理するとデリケートな処理してっとこだとまじーんじゃねーかな?ってのは思うわ

Cって例外ないじゃん
C++は既にJavaに似た例外あるじゃん

C言語スタイルってなんじゃん？

>>31
だから例外ないからその場で処理するしかないだろ

>>32
アナルほど凍死罵

>>30
> だって例外を1番上で捕まえると
> 死ぬ箇所によって死に方が千差万別よ

頭が硬すぎ。困るときだけ対処しろよ。

困らないときがほとんどなんだから
困るときだけ対処すればよい。

C言語よりもあとにできた言語では
ほぼ全て例外機構があって、例外を使うのが推奨されている。
（例外を使うなって意見聞いたことあるか？）

という現実を見れば議論するべき内容じゃない。
例外が良い。の一択

>>35
釣りか？
むしろ使うなという方が大勢だと思うが。
http://www.textdrop.net/google-styleguide-ja/cppguide.xml#%E4%BE%8B%E5%A4%96

C言語の例外処理はシグナルを使う方法だろ

>>36
Googleは例外が使われていない大量のレガシーコードを抱えている
そのレガシーコードと例外を扱う今風のコードを混ぜることにコストがかかるから例外を使わないというルールになっている
新規にコードを書くなら例外でエラーするのが一般的

>>Googleの既存コードに例外に対する耐性がないことを考慮すると、Googleのプロジェクトで例外を使うのは、新規プロジェクトで例外を使うのと比べて、ややコストが大きいと言えます。
>>例外の変換プロセスには時間がかかり、問題になりやすいものです。また私たちはエラーコードやアサーションといった例外の代替手段が大きな障害になるとは考えていません。

>>36
Googleは特殊な事例があるからってだけだなｗ

もうネタ切れ？ つまり例外を使うべきだよね。
（もう何度もやって答え出てること繰り返すのは面倒だ）

>>34
会社でどっちに倒すか?
ってなったら俺ならその場で対処だな

ロールバックの付いてないDBみたいな処理のが世の中多いと思う

例えば0割とかモノによってはその場で対処必須なものもやっぱあるわけで

どっちかに方針を統一しろって話になったら例外大ジャンプは取り返しがつかない事態を内包すると思う

まあ、概ね大丈夫ってのはわかるけどね

文中の例えばは間違い

>>40
> 例外大ジャンプは取り返しが
だからさ、例外小ジャンプすればいいだけだろ

なんで使い分けられない？

プログラミングやってて時たまいるんだが、
視野が狭いっていうか、何かをやれって言ったら、
それだけしかやらないやつな。

自分で適切なコードが何かがわからない。
マニュアル通りにしかコードをかけない。

そんなやつがいるんだよね。

例えば例外はちゃんとキャッチしろって言ったら、
はいはいわかりましたよって、すべての関数にtry-catchを入れる。
んで、え？あんたがキャッチしろっていったんでしょ？
だから全部入れてやったんですが？って言うようなやつ。

>>38
そこは俺も読んでるよ。
しかし俺は逆に「例外を使え」ってのを聞いたことないんだが、
日曜コードではなくて、マジの商用コードでそういう方針の所ってあるか？

> しかし俺は逆に「例外を使え」ってのを聞いたことないんだが、

なんのために言語に例外なんて機能を追加していると思ってるんだ？

言語マニュアルを読めば例外はどういうときに使うもので、
どういう使い方をするか説明してあるだろ。
それにその言語のライブラリは例外使われてるだろ。

ごく普通に使われってるとおりに使えばいいだけ。

まああれだ。C言語のしがらみがないライブラリで
例外を使っていないライブラリありますか？
という質問に答えてみればいい。

例外を使うのが自然すぎてわざわざ使えという話じゃないことがわかるはず。

>>43
エラーと例外の処理 (Modern C++)
https://msdn.microsoft.com/ja-jp/library/hh279678.aspx

>>最新の C++ のほとんどのシナリオでは、論理エラーとランタイム エラーの両方を報告および処理する方法として、例外を使用することが推奨されます。

ごめん、まちがえた
>>47は>>44宛

>>47
レスする相手は俺じゃないだろｗ

例外の使用が推奨ね。
当たり前だが。

>>47,48
情報ありがとう。頭だけざっくり読んだけど、詳細検討には時間がかかりそうだ。
googleのコーディングガイドでしれっと最後に
> Windowsのコードについては、このルールは例外です（シャレでなく）。
とあるのだが、Windowsで閉じている場合は環境が整備されているから
googleみたいな運用方法でも障害にはならないということなのかな？

大ジャンプが問題になっているけど、
現実的には大ジャンプ無しでの処理を強制するのなら例外を使う意味は無いよね。
例えば>>17なら従来方式、

int result = Director.Create("C:\\testdir");
if (result==1) MessageBox.Show("入出力エラーが発生しました。");
else if (result==2) MessageBox.Show("想定外のエラーが発生しました。");

でもほぼ同じなわけでさ。当然そのMSのサンプルコードもthrowしている。
その点>>15の方がそのMSのサンプルコードには似ている。
とはいえthrowするなってのは環境的な問題もあるとは思うんだが。

>>6
tryで囲む領域が大きくなると、どこでエラーが起きたか、わかりにくい

throwはややこしい。
一々、これは内側、これは外側の関数で処理するとか、変わるのはややこしい

LinuxのようなC言語だと、関数の下の方に、
リソース解放などの共通処理をまとめて、gotoでそこへ飛ばすようにするけど、
まあ、ややこしいプログラミングは避けた方がいい

仕事のプログラムは、個人のプログラムとは、書き方が違ってくる。
初心者・新入社員も入って来るから、自分だけがわかる書き方はダメ

>>50
そんな小さい処理で同じとか言われてもな。

resultって数字しか返せないだろ。
例外ならオブジェクトを返すことができる。
エラーとして返せる情報は無限大だ。
見つからないパスがどこか情報だって返せる。

あと自動で上に戻る機能。
とかさ、例外の機能をお前は理解してるか？
してないだろ。

なんでどの言語にも例外があるのかを考えよう。
必要だったから例外を作ったんだよ。
これぐらいは理解しろ。
理解したら、なぜ必要なのかの理由を調べろ。

> throwはややこしい。
> 一々、これは内側、これは外側の関数で処理するとか、変わるのはややこしい

うん。馬鹿だからだと思うよｗ

処理する必要があるときだけ処理する。
それだけのこと。

っていうかさ、さっき俺が言ったことじゃん。
自分で何が適切かを考えられない。

マニュアルを用意してほしい、そのとおりにやりたい
自分で何も考えたくない。
やれって言われたからやりましたー。
だから俺の責任じゃないですー。

自分で考えることを何もしようとしない。

>>47,48
だいぶ読んだ。

どっちがいいかは結構微妙だと思うんだけどね。
結局の所全体ポリシーとして「例外」を考慮しないといけないし、もちろんRAIIも徹底してないと危険。
だから出来るだけスマポというのはその通りだけど、
言っちゃ悪いけどRAIIとスマポだけで行く気なら最初からGC言語使えばいいだけだし。
むしろGC言語でGCタイミングをユーザが完全に制御可能にして例外使いまくりというのが正解か？

ついでに教えて欲しいんだけど、下記URLにある
https://msdn.microsoft.com/ja-jp/library/hh279653.aspx
no-fail/strong/basic保証ってのは単なる知識として考慮しろって話であって、
コンパイラに型として指示してコンパイラ側で全部整合性をチェックしてくれるようなことはないんだよね？

どこまで処理するかにもよるけど、原因が分かってそれを通知出来ればいいだけなら、
むしろ「例外機構」の設計が必要になる分、無駄なような気も。
なんつーか、将棋ソフトの駒クラスの例外を設計しようぜ！みたいな。

例えば、
> 発生することのないエラーをチェックするには、アサートを使用します。
> 発生する可能性があるエラー (たとえば、パブリック関数のパラメーターにおける入力検証のエラーなど)
> をチェックするには、例外を使用します。(>>47内URL）
つまり、将棋で言うと「二歩」「打ち歩詰め」は例外として処理しろってんだろ？
なんだかウザイだけの気が。（まあそれ以前に駒クラスが不要だが）

元々は正常処理と異常処理のコードを「見やすさ」の為に分離したいというところから来ているはずなのだけど、
その「見やすさ」を得る為に他も色々注意して設計しろというのは無駄/本末転倒だと思うね。
ただそのコストが環境整備によって極限まで低下したのであれば、それもありかとも思うけど。
それがWindowsの世界なのかなとはgoogleの付け足しから感じた。

Googleのスタイルガイドを読む限り、Windowsのコードの場合は独自性ガ強くて
どうにもならんところが多いからコーディング規則を逸脱しても仕方がないって感じだな

>>54
あんたが例外を使ったことがないから
例外がすごく使いやすいってことを知らないだけ。
何かと理由をつけて使いづらいってことにしたがってるだけだな。

戻り値だと注意が必要な場面がたくさんあるが、
例外だとさほど注意しなくても正しく動くアプリが作れる。
なにせ例外処理する必要が有るところだけ書けばいいからね。
すべて正しく書かないといけないC言語方式は大変。

例えばC言語方式だと、
printfの戻り値までチェックしないといけない。

ちなみにprintfが失敗する例として書き込み不可能な
デバイスに標準出力をリダイレクトする等がある。

例外だとチェックしなくても書き込みができなかったときに
エラーで中断してくれる。

例外を「例外」だと思わないマが多すぎる
とくにJavaから来た人

ところでOOPと関係ある？

例外よりeitherの方が使いやすいよ
型安全だし

ここはOOだけやってんだろ？Pはスレ違いだしな。

例外よりeitherの方が使いやすいよ
型安全だし

>>17はずれてるだろ

例外処理のメソッドを作った理由は「分割しなきゃならんほど複雑な処理している」からじゃなくて
「あちこちで発生する例外」を共通に処理するためだろ
だから当然再利用もしている
「catchすんのかthrowするのか」ってのも意味不明

>>63
意図を汲んでくれてありがとう

>>26
規約も規則もないみたいで好きに作っていいっていわれたからこう作った。
https://ideone.com/g1uE5d
ちなみにローカル環境でしか動かさないツールだから例外処理はログ出力ぐらいでしか
使わない。
ツールが落ちないようになってるならthrowしちゃいけない理由も特にない。
そうしたらなんでこういう風に作るの？はぁ、ちゃんと見ておけばよかっ、た。
って言われて、レビューとヒアリング聞いてみたの結果これが最適解だった。
コメントは言われたこと少し載せてみた感じ。
https://ideone.com/lbl7VW
これで伝わる？
多少おかしなとこあったとしてもそんなに意味わかんないことしたのかな。
ややこしい？
ファイル作るのにファイル名抜けてたりなんだりしてるけど黙殺してくださいごめん。

う〜ん、PG歴2年目くらい？
コードをたくさん書きたいお年頃的な
なんつーかクドい

下のコードで必要十分に見えるよ

＞予期せぬ値って何？想定があるの？必要？(笑)
同じ感想でﾜﾛﾀ

普通に書け
普通に
オリジナリティなんていらねえんだよゴミが

>>55
最後の「ルールの例外」からするとそんな感じだな。
夜はそこまで読んでなかったわ。

>>60,62
大事なことなので？
ってのはさておき、それについても布教用のドキュメントはあるのか？（例>>47)
ググッてもいまいち出てこないんだが。

>>47,48
こんな記述を見つけた。これって何言語か知らないか？
> 言語によっては基本保証やno-fail保証を静的に解析可能なものがあります。
> いくつかの言語ではno-fail保証をそのまま言語レベルでサポートしています。
> コードを静的に解析することでno-fail保証を約束するものもあります。
> また、基本保証を強制している言語や機構があります。
http://qiita.com/Kokudori/items/987073d59529b6c9a37c

>>66
初心者であるとかお年頃であるとか
そーいうのじゃない可能性もあるな

文章にしたって簡潔に書けない人おるやろ
あの手の人は死んでも直らない

>>68
Eiffelみたいな契約プログラミングによる保証か、
https://ja.wikipedia.org/wiki/契約プログラミング
もしくは、
C++11のnoexceptのような仕組みかな
http://cpprefjp.github.io/lang/cpp11/noexcept.html

noexceptでヌルポったらどうなるん？

>>68
>>60のはHaskellのEitherモナドのことを言っていると思われ
http://itpro.nikkeibp.co.jp/article/COLUMN/20090210/324443/
一応、C++やC#でそれっぽいコードを書いている人はいるみたいだが……

>>71
例外が投げられたら、std::terminate()が呼ばれて終了

>>66
共通の例外処理を繰り返したくないと書かれてるじゃん
読解力がない上に自分の意見を押し付けるってさあ…

>>65
おー書いたか、ご苦労さん。
俺が想定したものとは異なるが、それ以上に情報を含んでいたので、
レビューの様子もよく伝わったぜ。

まあ感想は他の連中と同じだな。
君は難しいコードを書いている。だから駄目なんだよ。
張り切って色々やろうとしているけど、それが駄目なんだ。
手を抜くことには努力を惜しまないってのが優れたプログラマだろ。
少なくともそのレビューと上司はまともだから、言うことを聞いた方がいい。

その上司のコードが何故いいか？それは簡単だから。
構造が単純だから、ぱっと見たらちゃんと動くことが分かる。
それに対して、君のコードはちゃんと動くかはよくよく見ないと分からない。

上司のコードは「自分で処理出来る例外はcatch、それ以外は放置」というポリシーだから、
基本的に下から上がってきた例外は「予想外」として落としている。
つまり例外ツリーは単純なツリー構造で、
このポリシーさえ守れば今後とも簡単に処理を追加出来る。
そして処理も基本的に上から下に処理されるだけだ。単純明快でいい。

対して君のコードは、そうじゃない。
よくよく読まないと果たしてちゃんと動くかどうかも分からない。
そして追加するにしても君が作ったクラスを全部知ってからでないと追加出来ない。
つまり、やることが増えすぎているし、密結合になっている。
対して減らせたのはせいぜいDirectry/Fileの例外の被り部分だけだろ。
それは明らかに設計コストを増してしまっている。

多分勘違いしているのだと思うし、実際そういう奴も多い気もするが、
ベタに書くのが悪いとか、同じようなコードが2箇所に出現するのが悪いとか、
そういう単純な問題ではないんだ。
分かりやすく言えば、
「そのコードを初めて渡されて、ああこのコードはちゃんと動くだろうねと分かるまでに、何秒かかるか」
について最適化しろということなんだよ。
当たり前だが全く同じ内容がダブってたら読むのに2倍かかるから、
それはループなり多態なりして一つに減らせってことになる。
だけど無理に多態したりして「コードを追う手間」が増えるようでは駄目なんだ。

その上司のコードはさらっと読んだだけで動くのが分かる。
でも君のコードはあちこち追い回さないと動くかどうかも分からない。

もちろん君が書いたコードだから、君のコードを君が読むのには苦労しないだろう。
だからもし君に同様の同僚がいて、同様に駄目出しをくらっているのなら、
その時の両方のコードを君が初見で読みこんで、
その構造と動くかどうかを把握するまで何秒かかるかを比較してみればいい。

CreateTempFileの中身はこうだな

void CreateTempFile(string path) {
　String directory_path = ディレクトリのパス(path);
　Directory.CreateDirectory(directory_path);
　File.Create(path);
}

ディレクトリやファイル作成時にExistsなんてやる必要ない。
Existsのチェックした後に、他プロセスから作成されることもある。
「チェック→実行」のパターンはロック機能がない限りたいていアンチパターン。

なにこのキモいスレｗ

>>70,72
情報ありがとう。

> 契約プログラミング
考え方はよしとして、大して採用されてないのは効果がいまいちだったのかな？

> noexcept
お？これはなかなか良い感じ。

ついでにそこから辿れる以下も読んだが、こちらも例外を有効活用しようとしている。
(より正確に言えば、例外を有効活用する時のライブラリの作りについてだが)
http://boostjp.github.io/archive/boost_docs/document/generic_exception_safety.html
例外の文法を使えば、確かに表現力は上がる。それは事実だが、ここに書いてあるように、
当然STLや自前クラスがどの例外保証を持っているかすべて把握してないと駄目だし、
完全活用するとなるとなかなか難しい気がするね。
(プログラミング時に把握しなければいけない項目が増える）

> HaskellのEitherモナド
Haskellの知識はないのでとりあえず日本語部分だけ読んでみたが、
この読み方では有効かどうかは判定不可能だorz
> C++やC#でそれっぽいコード
このURLをくれればすごく助かります。

> 当然STLや自前クラスがどの例外保証を持っているかすべて把握してないと駄目だし、

例外保証ってなんや？

その例外保証があるかどうかわからんものが
戻り値でエラーを返したら、それを保証してくれると
思う根拠は何や？

気をつけることがあるとしたら、それは戻り値でも同じだし
正常処理とエラーを、一つの戻り値（変数）に入れる分
複雑度は上がるんだぞ。

>>65
ディレクトリを作れない時に、throwして外のスコープに飛ばすのは、ややこしい。
そこでエラー処理できる

外のスコープから見ても、内側からも、throwしてくると考えると、
考える組み合わせ数が増える。
組み合わせ爆発を避けるため、早期に枝切りすべき

また、内外のスコープで、情報を共有するため、
Commonというグローバル変数もどきを、作らざるを得ないから、
内外の関数が、密結合を起こしてしまっている

修正・保守していくうちに、こういうのがいずれ、スパゲティ・泥団子へと成長していき、
誰の手にも負えないようになっていく

>>65
的確な指摘じゃない？
どうみても下の方が出来がいい

>>80
>契約プログラミング
C++だとBoost.Contract
.NetだとSystem.Diagnostics.Contracts
があるね
使ったことないけど

>例外保証
なんか、まじめに考え過ぎな気がする
どのクラスがどの例外保証を持っているかなんて、気にして書いている人なんていないんじゃないか
(と、言うとちゃんとやってる人に怒られそうだが)

例外安全、例外耐性を考慮して、きれいにやるなら把握しているに超したことはないけれど
基本的には「いちいち戻り値でエラー判定するのが面倒。戻り値だとエラー判定忘れることがある(アプリがエラー状態のまま動き続けてしまう)。例外をつかえばそれらを簡単に回避できる」くらいの感覚で使われてるんじゃないかな

例えばオブジェクト指向でクラス設計するときはSOLID原則を意識することはあれ、
そこまで厳密に遵守して書かないし、他人の書いたクラスがSOLID原則に則ってるかなんて気にしないでしょ？

それに今時の言語なら標準ライブラリが例外を投げるから、それらを使うなら自分のコードでも例外を使うことで
「このコードでは、エラーは常に例外で通知する」という一貫性が生まれる

プログラミングにおいて一貫性は重要だ
先日のGoogleのスタイルだと「例外を使わない」という点で一貫性がある

もちろん、現実世界ではそんなにすべてうまくいかないから
必要があれば戻り値のエラー通知を部分的に使うのはかまわないと思うよ
.Netにも例外を投げるInt32.Perseと投げないInt32.TryPersreの2種類があるし

>Either
"C++ Either"や"C# Either"でググれば「書いてみた」系のブログが引っかかる

おはようございます！
ご回答ありがとうごさいました。
そうかー難しいのか。
難しいということはたまに言われますが、なにが難しいのかわからなくていつも悩んでいるので、自分は設計には向いていないのかもしれません。
下流で頑張ります。
皆さんも今日一日頑張ってください！
それでは！

>>84
> .Netにも例外を投げるInt32.Perseと投げないInt32.TryPersreの2種類があるし

名前が重要なんだよ。（ちなみにParseな）

例外を使ったときのメリットは、関数の名前通りの戻り値にできるってこと。

Parseはパースするんだよ。だから戻り値はパースした結果であり
エラーを戻すことはない。パースできなければ例外。

TryParseはパースすることをトライするんだよ。だから戻り値はトライした結果。
もしトライすることすらできなければ、それは当然例外。

その2つは、例外を投げるかどうかの違いじゃなくてやる処理の違い。
そしてどちらもやるべきことができなければ、例外を返す。

そんなに力説するほどの事か？w

>>87
これは力説するほどのことだよ。
なぜなら可読性の話だから。

英語わからんとか、ソースコードを命令の並びだとかしか
認識してないレベルの人にはわからないだろうけど、
ソースコードは読むもの。

読みやすさを大きく左右する要素の一つが、
適切な名前をつけているかどうかだから。

たまに適当な関数名つけてる人がいるけど、ほんとやめてほしい。
適当な単語を並べただけじゃソースコード読めないから。
名前から意味がわからないから、中の処理を読んで解析しないといけなくなる。

それなら問うが
Parseが返すパーズした結果とは何ぞや？
TryParseが返すトライした結果とは何ぞや？
俺には名前だけではさっぱり分からんのだが
これがお前の望む適切な名前とはとても思えんのだがw

>>89
友情努力勝利に決まってるだろ

正直TryParseで変換できちゃうのはちょっと気持ち悪い

>>84
例外をエラー通知として使う分にはその辺は知らなくていいんだよ。
ただ、例外で復旧させようとするのなら、その辺を全て把握する必要がある。
そして彼等はそれにも耐えられるようにSTLを整備しようとしている。
それは無駄なコストを発生するから、それについて彼等も議論しているわけだ。

ただ、今見た限りはまだ環境が追いついていないね。(ドキュメントが出来ていない)
偶々このページを見ていただけだから、unordered_map自体に意味はないけど、
http://en.cppreference.com/w/cpp/container/unordered_map
個々のメソッドには例外発生時の動作が書いてあるけど、本体のページに纏まっていない。
だからunordered_mapを使ったらどの例外安全になるのかを確認する為には、
全部のメソッドを確認するしかない。
大半の奴は確認もせずに「例外を使った方が安全です」と信じているだけだろう。

例外を活用しようとなると、既に書いたように、大ジャンプを避けられない。
その場でいちいち判定するだけなら、余計に汚らしくなるだけだ。
ただしこれについては速度面ではtry/catchの方が上だと指摘されているし、
表面上のコード量では確かにそうだ。
とはいえ、x86に於いては分岐予測＋投機実行なので、
ほぼ常に通らないパスのif-elseifについては、
気になるのなら1段目で切ってしまえば速度低下はしない。(if (result>0))

> 必要があれば戻り値のエラー通知を部分的に使うのはかまわないと思うよ
個人的にはTryParseをよく使っている。それで十分だから。
必要性はない。try/catchでも書ける。

戻り値判定の場合は、その場での処理が強要される。
結果、65の上司型のコードしか書けない。
実際にあのコードを戻り値判定に変換するのも簡単だ。
この使い方をする場合は好みの問題でしかない。

一方、例外を用いれば、65がやろうとした「積極的にthrowして統合的に扱う」ことも出来る。
戻り値判定でこれをするのは大変なことになるので、これをしてこそ活用だと言える。
とはいえ、これがろくな事になる気配が全く感じられない。

ちなみに、言語的な例外復旧能力に必ずしも頼る必要はない。
上位レベルでの復旧も実は簡単だからだ。
例えばTryParse、ファイルから読むのならソースは保持する必要がない。
Seek出来ないネットワークストリーム等なら、MemoryStreamに一旦受ければいい。
JSONみたいに階層ありオブジェクトを丸々生成するのなら、成功した後に差し替えればいい。
これらの場合は、ロールバックを上位で行うことはほぼ自然に出来てしまうので、
結果的にSTLが実装した例外機構の為に無駄に税金を払う事にしかならない。
この点を修正しようというnoexceptはC++っぽくていいが、
なるほどこんな事をやっているうちは生Cを駆逐することは出来ないだろう。

生Cはある意味世界がno-fail保証されている。
そして失敗した場合は上記のように自前で戻すか、諦めるしかない。単純な話だ。
ロールバックする気なら、この点については例外で処理した方がコード的には楽だ。
しかし実行効率ではどうやっても生Cの方が上になる。何もしてないコードだからだ。
生Cは世界が単純に出来ている。あまり気にしたことはないが、これは大きな利点だね。
言語がシンプルな結果、シンプルな記述を強要され、結果的に65のようなコードを記述出来ない。
65みたいな「考えすぎておかしくなっている奴」には生Cギプスが効くかもしれない。

> .NetだとSystem.Diagnostics.Contracts
以下を見る限り、型についてのTDDみたいな感じだな。
静的チェックが出来るのはいいね。ただ、流行るかと言われれば微妙かな。
https://visualstudiogallery.msdn.microsoft.com/1ec7db13-3363-46c9-851f-1ce455f66970

> C++ Either
以下でいいか？
http://faithandbrave.hateblo.jp/entry/2014/05/30/153325
つまりは例外を呼ばずに値として埋め込みたいだけか。
関数型で組んだ場合には個々の要素で例外呼ばれても困るから、そりゃこうなるだろう。
そういった意味ではC++の例外機構は「手続き型」にしか対応してないね。
そこですぐ呼ばれる前提だ。

他の関数型言語の例外機構ってどうなっているんだ？知ってたらよろしく。
Haskellがこの手で値埋め込み、後でユーザ側で確認するというのは分かった。
なおJavaScriptは0割は無限大になるというお気楽仕様だ。
当初は驚いたが、正直これで問題ないよなとも思う。

>>89
> Parseが返すパーズした結果とは何ぞや？

正しくはInt32.Parseなんだから当然Int32だろｗ
Int32に変換した結果を戻す
（変換できなければ戻さない）

> 俺には名前だけではさっぱり分からんのだが

あー、うん。クラス名が先に作ってことに
気づかなかったのねｗ
>>86で引用してる>>84にかいてあんだろ。
気づけよｗ

Int32.Parse　だからといって、必ずInt32が返るとは限らないだろ
おまえは、human.age()で必ずhumanが返ると考えるか？

>>94
> なおJavaScriptは0割は無限大になるというお気楽仕様だ。

いや、お前、例外っていったら0除算しか思いつかんのかよｗ
eval("{") とか実行してみろ。JavaScriptは例外を使う言語だ。

0以外の数値を0で割ったら無限大になるのは数学的に正しい。
JavaScriptが無限大を扱える言語ってだけだ。
もちろん数学的に正しいことをやっているから、 0 / 0 は NaN （非数）になる。
少なくともこの点は、お気楽ではなく高度な言語だと言える。

もっともJavaScriptに例外が搭載されたのはJavaScript 1.4（1999年あたり）からだけどな。
それ以前は（エラーを戻り値で返すのではなく）スクリプトが停止され
window.onerrorイベントが呼ばれたんだっけな？もう忘れたが。

いっとくが、human.age()で必ずintが返るとは限らないからな
もしかしたらageオブジェクトが返るかもしれないからな

>>96
> Int32.Parse　だからといって、必ずInt32が返るとは限らないだろ
> おまえは、human.age()で必ずhumanが返ると考えるか？

Parseとageで関数名が違ってるじゃんｗ
名前で返すものが決まるって言ってんだろ。

human.parseだったら、human返すんじゃねーの？

>human.parseだったら、human返すんじゃねーの？

そんなの思い込みだろ
ヒューマンパーズオブジェクトが返るかもしれないだろ

>>94
> 他の関数型言語の例外機構ってどうなっているんだ？知ってたらよろしく。

関数型で戻り値でエラー情報なんか返したら
大混乱になるわｗ

関数呼び出しの中の、関数呼び出しの中の、関数呼び出しの中の、関数呼び出し で
エラー情報が返ってきたら、if式による分岐の嵐でもはや
関数型言語のように見えないだろうね。

>>100
> ヒューマンパーズオブジェクトが返るかもしれないだろ

ほらね？ 何が返るか想像できてるじゃんｗ

Int32.Parseじゃ何を返すかさっぱりわからないって言ってるから
それが間違いだよって話。

なにも100%完全に返り値の情報がわかるなんて言ってないんだよw

型を見りゃいいだろ

まさかこのスレに居ながら、屁臭いペチプ〜やゴミのペールやペールの糞からひり出されたルビーや・・・そんな糞まみれのウンコ野郎はおるまいね？

>>102
いやお前それ苦しいだろ

>ほらね？ 何が返るか想像できてるじゃんｗ

想像？
思い込みでしょ
ヒューマンパーズオブジェクトが返るかもしれない、とは書いたが
実際には何が返るかわからないから、そう書いただけであって
どうせ、仕様を調べなきゃならないんだよ

>>104
言うと思ったｗ

でお前これから先仕様なんて調べるの？
調べないよね。もう覚えてしまったから。
あとは文字を見れば思い出すはずだ。

適切な名前があると覚やすいっていうのはこういうこと。

>>101
>関数型で戻り値でエラー情報なんか返したら
>エラー情報が返ってきたら、if式による分岐の嵐でもはや

ifの分岐しないためにfunctorだのアプリカティブだのmonadだのtraverseがあるじゃん？
try1 >=> try2 >=> try3 >=> ... tryN
みたいので「成功するまで処理を続けて失敗したら例外情報をもって途中で抜ける関数」を作れるし
こういう合成力は関数型の強み

自分の思い込みの通りなら良い設計良いコードw

正しく意図した通りに騙してくれるなら
明らかに良いコードだろ
頭のてっぺんからケツのシワまで数え上げてようやく読解できるコードが糞じゃなきゃ何なんだ

クソの主観によりクソ認定されたコード達w
本当は良い奴も沢山いただろうに不憫だわーw

車輪の再発明しか出来ない人がいると聞いて。

DAO とかDTO ってのが出てくるアーキテクチャは手続き型であって、オブジェクト指向ではない

ってのが解る人ここにいるか?

そんな嘘ついちゃいけないんだお

今の日本人は>>111みたいな馬鹿が普通なんだお

>>113
やはり解る人はいないか
DAOやDTOってのはデータと処理を分離するから手続き的なんだがなぁ

オブジェクト指向なのはEntityを使ったタイプのO/Rマッパーだね。
Railsとかもそう。DAOやDTOなんてのは出てこないで
データベースがオブジェクトにそのままマッピングされる。

抽象化が過ぎて解る人がいないだけ

>>111
主張が良くわからない。

http://www.nulab.co.jp/designPatterns/designPatterns3/designPatterns3-4.html
に出てくる例と説明にそって、論を展開してみてくれ。

言いたいのは単純に

DAO/DTO

オブジェクト指向論で定義されたものじゃない。
オブジェクト指向で実装されただけで、これらを使うには手続きが必要だ。

それだけだろ。

んなことゆーたら全部手続きですやんける

>>119
程度の問題

単に>>114が知ったかぶりしたいだけだろ。
>>111の段階で明らかだし。

>>118
逆だろ
使うのはオブジェクト指向にするためで
その実装の中身は程度の差こそあれ
DBを相手にする以上手続き的にならざるを得ない

知ったかぶりにすらなってなくて意味のない単語の羅列にすぎん

クラスの中に別のクラスをコンポジットしてあり、
そのクラスの中にも別のクラスをコンポジットしてあり…という場合、

最下層のクラスに必要な値を入れるために何度もメソッドを経由するのが大変なのですが
オブジェクト指向ではこれが普通なのでしょうか？

カプセル化せずに
outerClass.middleClass.innerClass.set_value(100);
とした方が楽だと思うのですがまずいでしょうか？

別に良いけど
innerClass.set_valueが呼ばれて値が変更されたときに
変更されたことをouterClassやmiddleClassに通知する仕組みが必要になるかもしれないよ
この場合、余計にややこしくなる

そのほかのディメリットはカプセル化しないことで発生するディメリットと同じ

>>124
O/Rマッパーを使うからそういう処理は
勝手にやってくれる。

>>124
更に言えば
実装方法としても、set_valueは分かり難いし楽でも何でもない
あえてやるなら
outerClass.set_value(key, value)とか？

>>127
最低のやり方だな
そのk,vのMap、実行するまで完全なブラックボックスになるじゃん
死んで、どうぞ

>>127
くっせ〜なホント
こういうペチプ〜崩れの塵屑見ると延髄チョップからのバックドロップ食らわせてやりたくなるわ
まじな。死ね。

なんでもarrayにしときゃいいと思ってるド低脳
チンパンジー以下のサルゥ
ほんとつっかえ・・・

>>127
血染めの赤にしてやる
死ね

>>127
おら何とか言えよゴミ
ID変わるまで逃げるのか？
ほんまつっかえゴミくずやな〜

イコール代入するなら、最後は明示されたセッター呼ぶのは中途半端な気がする。

各クラスにユーティリティメソッド実装できるなら、
outerClass.getNodeFromPath("middleClass.innerClass").set_value(xxx)
とか取得関数持っちゃうと、文字列だけ不細工だけどなんとでもなったりするんじゃないかな。

結論
余計なことはするな

株式会社TOUAが2016年7月に破産
http://www.tdb.co.jp/tosan/syosai/4191.html

>>135
派遣会社ってピンハネしかしてないのに潰れるの?

>>136
トウアは仕事をしない、仕事ができない人間を抱えすぎていたのと、資金がもともとないのにオフィスを分散させたり、複数社のグループにしていたせいで効率が悪かった。

これは会社を大きく見せたい人間が社長の会社の典型的なパターン。

中間搾取でも取引先の支払いが遅いと資金が足りなくなって破たんする。

最後はとにかく仕事を増やして乗り切るつもりだったんだろうけど追いつかなかったんだろうな。

プロパーのレベルが低いのは、賢いSIer、ユーザー企業も分かってたし、仕事をここの下請けに丸投げ、押し付けているのも分かるから仕事が取れなくなっていた。

ドコモあたりのアホ企業頼みだった。

予想通り、誰もいなくなったのね。

static Koma.move() の頃がおまいら一番輝いてたね}

人の意見を聞かずにバッサリ切り捨てる、典型的な２ch脳な人が
のさばり出した時点で離れた。

それぞれに結論がでてる状態なんだろ？
俺も一連のやりとりでオブジェクト指向ってやっぱりクソだなって再認識した

やっぱり誰でもわかる手続き型がナンバーワン

手続き型は誰でもわかるが工数が多すぎてな
ビジネスでやる以上工数は節約しなきゃ

誰でもわかる明朗なコードを書かなくてはいけない
ビジネスだからこそ、手続き型がナンバーワン
ビジネスは君の趣味ではない

ビジネスだからこそお荷物は解雇しなきゃならない
ある程度の能力のある人間が工数を減らせる手法で開発する
工数の掛かる手続き型しか書けない読めない人は解雇するべきビジネスだから

趣味をビジネスに持ち出すオタクはNGですよ、これ常識ｗ

成長しない新米プログラマをいつまでも傭い続けるわけにはいかない
ビジネスってさボランティアじゃないんだよね

で、君らはまたstatic final Koma.move(int kyori)すんの？

回り将棋ならいいかもしれない

ViewModelってどのレイヤーに属するんだ？
Viewに関する知識はないからUIレイヤーではないだろう
ビジネスルールに関する知識は必要だからドメインレイヤー？

UIレイヤーの中のドメインレイヤーとの境界面、じゃないの

あ、あとViewModelに必要な知識はビジネスルールじゃなくて
ドメインレイヤーのインターフェースだけじゃないのかな？
ビジネスルールに関することはモデル内で処理するべきだと思って作ってるけど…

>>152
俺も最初はそう思ってたけど現実にそれではうまくいかなかったんだ

Hoge
x
y
z => sqrt(x * y)
このエンティティはビジネスルール上の不変条件としてx * y >= 0でなければならないとする
普通ならxとyのセッターで不変条件を監視して不正ならすぐに例外を投げる実装になる
ドメインレイヤーのModelって基本的に全てこんな感じ

でもViewModelでは不変条件を常には満たさなくてもいい
その代わり不変条件を満たしていない事を検知する方法が必要って感じになると思う
つまりこんな感じ
HogeViewModel
x
y
z => x * y >= 0 ? sqrt(x * y) : null
hasError => x * y < 0
xとyのセッターでは不変条件の監視をしないで不正な値も受け入れる
ただし不正な状態ではhasErrorが真になる
xとyは入力コントロールに、zは出力コントロールにバインドされる
hasErrorはエラーアイコンやコントロールの色にバインドされる

両者はビジネスルール的には同じ事を表現しているはずなんだけどドメインModelとViewModelでどうしても別々の実装になってしまう
ViewModelからドメインModelを参照するだけではうまくいかないしどうしてもViewModelにビジネスルールが染み出してしまう

自分は個人で作ってるだけで好きなようにやれるからだけど、
そういう場合、自分はxもyもそのままモデルに投げてその処理はいったんそこで終わり。
モデルで値をチェックしてエラーならエラーイベント発生
→入力用ViewModelがそのイベントを受け取ってViewに伝えるDataErrorイベント発生
→Viewが変化

zについても、モデルから受け取ったPropertyChangedイベントをViewに中継するだけにする、かな…

あくまでも、x,ｙの値によってモデルが例外を投げないように自分で作れるからだけど…

限界あるな
xにうんこって入れられても一旦は保存するってことだろそれ
まさにクソまみれ

ViewModelが勝手に「これはうんこだ！捨てておこう！」「これはうんこじゃない！大丈夫だ！」
なんてやってる方が、いずれシステムがうんこまみれになる危険が高い気がするが…

人間だって、目がうんこの反射光をとらえて、視神経がそれを脳に伝えて、
そして最後に脳が「うんこだ！汚い！」ってやるんだから
Modelが「うんこだ！汚い！」と判断するまで、
ViewやViewModelが入力情報をそのまま伝えていくことを
「うんこを一旦保存」とかとらえるのはおかしいと思うんだけどな…

>>156
じゃあ超長い文字列とかも一旦は保存するんだろ?
思想に限界があるって気付けよ

そもそも画面仕様が専用であるはずなのに
データ型のみModel依存ってこだわりがうんこ
画面なんか内部も含めて作り捨て上等だろ

次の変更は一度にたくさん入力したいのでExcelかcsvから読み込んでもらえますか?
だったら一生懸命付けた汎用性もm9(^Д^)ﾌﾟｷﾞｬｰ

画面の検証は入力長、上下限、正規表現など簡単なものだけ採用する
自動計算項目も簡単なものだけを採用する
例えば金額と税率から税込価格を自動計算するとか商品コード入力したら商品名取ってくるとかその程度で我慢する
画面の検証や自動計算項目はあくまで入力支援が目的なのでビジネスルールに完全に遵守する必要はない
ビジネスルールを厳密に守らなければいけないのはアプリケーションサービスインターフェースより向こう側だけ
アプリケーションサービスの内部で画面か受け取った入力内容をドメインモデルにマップしてそこで本気の検証や計算を行う

一切関知すべきじゃないな。
うんこかもしれないもの、としてVM以降に渡して、うんこではないものを貰うしか無い。

それだと使い勝手は悪くなるな

>>161
小数じゃないのに小数点が入力できちゃったり
マイナス値なんて取らないのにマイナスが入力できちゃったり
全角なんて入力してほしくないのに全角で打てちゃったり
ファイルパスを入力して欲しいのにパスに入力できない文字が入る
その状態でファイルオープンダイアログ開いたら死ぬの?とか
素人丸出しアプリだな
visualstudioでプロパティいじれば解決する話をわざわざコードで記述してバグる超絶欠陥製品にしかならないだろうね
すべての値のチェックを入口で退治するんではなくて一度保持してしまうから問題を拡散している
undoしたらどこの値に戻るの?それ

>>163
何を誤解してるかわからんが、それは、ビューモデル以外の場所で即座に否定されたり、是正されたり、これはは間違ってますよとエラーと判定されるから、
ビューモデルは、判定結果をおとなしく持って、ビューにレンダリングしてもらうだけじゃん。

お前がやってんのは、それはVMの仕事じゃない。

>>164
だからさ
その構造を実現することになんの意味があるのって話

>>163
そういうのは大前提としてやった上での話だよ
整数入力コントロールには指定した桁数いないの数字しか入らない(アルファベットなどはキーを押しても入力されない)
その上でビューモデルにどこまでビジネスルールの知識を与えるか、ドメインモデルとの違いはなんだ、という議論をしている

>>165
データを処理する処理に徹することができるのと
データを描画する処理に徹することができるんじゃん。

>>167
現実にはできなくて、やるメリットもあまりなくてって状況だと思うけど

>>166
だったら内部の仕様も画面にべったりなんでしょ?
今更分離して何がしたいの?

はっきり言ってしまうと経験が浅いから掲げる理想が陳腐
大規模DBとそれを操作するインターフェイスを真似たモデルであれば
画面なんてプロジェクトごと作り捨て上等なんだよ
DBはもう誰も仕様変更を入れられない
画面は実現したい内容によって完全廃棄もありうる
これが現実なんだよ

>>169
VとMVの分離のメリットなら2つ大きいのがある
1. UIの状態数の最小化
2. 手続型から宣言型への移行

>>170
画面を使い捨てる前提ならますます分離した方がいい
ひと昔前はViewにビジネスロジックが当たり前のように書かれていた
こういう画面は本当に使い捨てていい画面なのか判断が難しい
画面を使い捨てる前にリファクタリングを行いビジネスロジックを抽出して分析しなければならなかった
必要なビジネスロジックは残して別の画面から利用するように変更しなければならない
この作業が全てうまくいけばようやっと画面を使い捨てる事が許される

だからさ
現実にはできないじゃん
ちょっと突っ込まれるだけでボロボロ抜けが出てくんだから

>>173
最近はちゃんと分離されているシステムが増えてきてる

>>174
誰の周辺の話なの?

>>175
世界的に

>>168
割と大規模やってるけど、気合でWPFに移行してからそこそこうまく行ってるよ。
出来なくて切った会社は沢山あった。

>>177
そんな多大な犠牲を払ってようやくできたのか?（笑）
設計ってみんながわかりやすくするためにするもんじゃないの?
選ばれし者しかできない時点で失敗してるんだよ
わかる?

>>178
莫大な犠牲は下請けが払ったんだと思うよ。
選ばれしものしかできないとは思わないが、
選ばれしものが出来ないのはある程度あるんじゃないの？
馬鹿とか。

>>179
何のための画面と内部の分離だったの?
メリットが見えない
選ばれし者しか理解できないソースと組んだやつしか読めないソースの品質の違いが俺にはさっぱりわからないよ

>>180
前者は選ばれしもの(といってもWPF程度なら並みのプログラマで十分なので選ばれしもというのは大げさだが)なら超低コストで保守できる
後者は書いた本人も含めて保守に膨大なコストがかかる
このようにコストが全く違うわけだけど何故同じと思ったのか理解し難いね
メリットが見えないんじゃなくて見えないフリしてるだけだろきみは

インスタンスメソッドは選ばれしものにしか使えないから
全てスタティックメソッドにしなさい
ってことですか？

>visualstudioでプロパティいじれば解決する
あーダメダメ

できるヤツができないヤツに合わせる必要はない
退化する

スタティックお兄さん爆誕
古き良きプログラミングの時代、復活の刻

>>181
え?でもいまの状態で画面と内部の分離ができてないじゃん
値のチェック前に一旦値を保存するんだよね?
内部に問い合わせないとチェックする内容がわからんから
偉そうなこと言ってるけどできたもんはゴミじゃん

>>186
保存ってどこから出てきたんだ？

>>187
このスレよく読んでからレスしてね

ViewModelからModelに入力値の通知を行うことを「保存」と呼ぶ頭のおかしい人が約1名いるだけ

なるほど
どうりで話が通じんわけだ

>>180
画面直すのかデザイナさんにもできる、
ロジック直すのが画面に一切影響しない事を謳ってプログラマだけで出来る。
これ大規模だと結構大きいよ。デザイナさんに動いてもらうのそこそこかかるし。

>>186
一旦保存って何かわからん。VMの変数に持つよね、って事？
VMの変数に持とうがなんだろうが、入力値と使用値と出力値が同じ所(例えばテキストボックス)に表示されるのは、そもそもが事故の元だよ。

>>191
はぁ?
なんのこと喋ってるの?
ちゃんと理解してからレスしてね

>>192
>>177
で発端にすらなってるから、理解はしてるが。
アホなのかな。

なぜオブジェクト指向の設計の話になると喧嘩になってしまうのか？
やはり関数型にすべきでないのか？

>>194
モナドを許すか許さないか論、原始再帰関数の定義の喧嘩になるのがオチ。
手続きとしてCPUが処理している所に別のパラダイム持ち込むとこうなるし、
関数としてGPUが処理している所に手続きを持ち込むと同じように異論は出てくる。

喧嘩がなくなるなら関数型喜んでつかうわ

工数の少ない方を採用するなぁ
何が何でもオブジェクト指向！ってのは手段が目的になっちゃってるように感じる

感情をイミュータブルにしましょう

工数最小マンって無責任だと思うよ
保守は他人がやるからラピッドでええやんってクズばかりだから業界全体が停滞してるんだよ
多少工数が増えてもエレガントなOOPで作るべきだ
というかそもそも工数ベースで見てもOOPの方が優位だけどな

工数最小≠OOP
って、どっから沸いてきた式だよ
コンパイル通らないぞハゲ

>>199
ん?でもさぁ
汎用性つけまくった挙句に次の変更が来なかったら汎用化にかけた工数は無駄じゃない?

>>201
汎用性と保守性を混同するのは初心者にはありがちだけど全く別のものだぞ
OOPはまず保守性を高めてくれるってのが主だ
結果として見ると汎用性もオマケで付いてくる場合が多いってだけだ

>>202
そもそもOOPだと何で保守性上がるの？

粗結合の徹底→モジュール化→単体テストしやすさ、古くなった部分の可換性

>>203
SOLIDを実践しやすいから
モデルを忠実にコードに反映できるから

>>204
OOPならではの部分を強調してほしかったが
疎結合とモジュール性についてまっさきに触れているので結果的に好感触

>>205
聞いて損した

>>206
俺も答えて損した
馬の耳になんとかってヤツだね

なんかごめんね…

>>208
反省しろよ

>>209
おまえもな

>>210
消えろ
ぶっ飛ばされんうちにな

>>211
おまえもな

>>211
あんまり調子こいてると手続き型にするぞ？

もういいから

工数気にするのって完全受注型で自分とこで商品開発できないようなところだろうなと思うわ

採算度外視で開発とかないわ

オブジェクト指向の良書教えて

>>217
http://echo.2ch.net/test/read.cgi/tech/1467992113/

ループかよ

>>204
手続き型でもできる。
というよりオブジェクトみたいに状態に注目するより
メッセージやメソッド、関数に注目するほうが自然な場合もある。
まあオブジェクト脳だとそういった処理をまとめたクラスを作るんだろうけど。

>>220
具体例は？

　サ　ー　ビ　ス　ク　ラ　ス

>>220
> 手続き型でもできる

それはとても興味深い指摘です。後学のため、
これぞ手続き型の（つまり「そこまでやったらもはやOOP」とは言わせない、そういった小細工のない）
コードで実演してみてもらうことはできますか？

そもそもオブジェクト指向にメリットなんかないのにやり方がわからないとかさっさと廃業しろ

デストラクタは OOP でないと難しいね
え？ポインタの存在自体が邪道ですか？そうかもしれないですかね‥

デストラクタってOOP以前からあるしOOPと直結する関係性もない
それになぜいきなりポインタ？もはや何が言いたいのか判らない

そう難しく考える必要はなく物事をシンプルに考えていくと自然とOOPにたどり着くんだけどね
OOPに拒否感を持つ人はその当たり前の感覚を持っていないアスペなんじゃないかな
子供の頃いじめられたりしなかったか？

機械的な命令並べてgotoするより意味的な命令並べてifとかloopとか使ったほうが簡単だな
同じ処理をなんども書くより関数にしたほうが簡単だな
引数が多くて煩わしいから一緒に使う変数をまとめて構造体にしたほうが簡単だな
この構造体は特定の関数以外から変更されたらそれらの実行の前提条件が崩れるからそれら以外からメンバに触れないようにアクセス制御したほうが間違えなくていいな
それらの関数を構造体と同じ箇所で定義すれば管理しやすいな
メンバ変数みたいにドット演算子でそれらの関数にアクセスできれば楽だな
………

こういう感覚は別にOOPを知らなくてもコーディングを簡単に安全にしたいという欲求があれば自然とたどり着くものなんだけど
感覚がおかしいのかガチで気が付かなかったのか
たどり着けないかわいそうな子も世の中には少なからずいるんだね

なんていうかね
棍棒だと重いし動物殺しにくいけど木の棒の先っぽに鋭い石括りつけたら軽くてめっちゃ殺せるんだけどウホホwww
正直この程度の発想でしかないんだよ
OOPってそんなに高尚で難しいものじゃない
それをわざわざ難しい概念だと錯覚して悩むのは時間の無駄じゃないか？
OOPとはなにかOOPの存在意義はなんて哲学者みたいなことを考えてないでさ
自分の感覚に従ってOOPってよくわからんけど手続き型より楽だわウホホwwwって気楽にコーディングすればいいんだよ

なんで人格攻撃に移るの?
自分の中で辻褄が合ってないから反論できないのに他人を叩くことでそれを解消しようとするのは間違ってる
お前は技術者を廃業しろ

ワイ「関数型最強ウホホｗｗｗ」

> 物事をシンプルに考えていくと自然とOOPにたどり着く

逆だろうね
物事を自分のおつむの程度にしかとらえられない人間がようやくたどり着いたのが>>227が書てるOOPもどき
この程度の理解の人間がOOPを真に理解してそのメリットを引き出せているとはとうてい思えない

>>229
残念ながらこれもOOPがらみでよく見られる光景
追い詰められてならまだしもわりと最初のほうからこれだもんね
さらにそれにしたってそれすらを長文でぐだぐだと…推して知るべし

2chの長文すら読めないオジサンって、普段技術書読まないんですかあ？

技術書ってクソばかりじゃないですか

>>226
デストラクタはOOPと同時ですよ

protectedっていつ使うんですかぁ？中途半端じゃないですかぁ？

継承やUTで簡単に使えるようにするため
privateは全てprotectedにしろと言われたことあったわ

継承っていう仕組みがクソ。疎結合とはなんだったのかって気分にしてくれる。

OOPのメリットとして吹聴される要素の8割はクソ。
カプセル化はクソ（めんどくさい）
継承はクソ（親子のねっとりしたつながりがキモイ）
多態は野ぐそ（多態のための汎化、インタフェース抽出とか勘違いも甚だしい。保守性に逆行している）
俺OOP使ってこんな曲芸できます案件多すぎクソ。

葡萄に手が届かない狐さんのたわごと

>>239
車輪的再発明すきそう

OOPみたいな簡単な仕組みも理解できない人って可哀想
もっと体動かすだけとか根性あればなんとかなる仕事に転職しないの？

OOPは本当に簡単で短絡的な思考のすえたどり着く結論だからね
オブジェクトに操作が内包されているというのは
まるで利権主義で、縦割り行政で、日本的といえる
自分の仕事しかしないし、利権はぜった他人に渡さない
利権という物質的なオブジェクトにすべてが紐づいていて整理されている

まぁ実用面では便利な部分もあるんだが
外でOOPサイコーとかいうと人格を疑われかねない
本音と建て前でこっそり使うものだ

OOPを無くした人類はどこへ向かうのか

オブジェクト指向を用いるメリット
｢ラクして、楽しく、良いもの｣を作れる

スッキリJavaより抜粋

｢ラクして、楽しく、良いもの｣を作れる
オブジェクト指向登場後のソフトウェア業界は
さぞかし良い世界になったんだろなあ

とてつもなく良い世界にはなってる。

簡単になりすぎて捌ける規模が大きくなったから
逆に要求が膨れ上がって結局辛い世になってる気もするが
まあCOBOLとかやらされるよかマシかな

オブジェクト志向言語使っててもアホが考えた社内規約とやらとヘボいフレームワークで全く楽にならねえw

>>249
あーわかる
なぜか規約もフレームワークも手続型っぽいんだよな

オブジェクト指向の利点って明確にならないね

そういやこのスレって、どんな話題で始まったんだっけ？
「オブジェクト指向の利点を明確にする」
だったっけ？

>>252
まずメリットが明確にならないとやる意味もわからなくてさ

>>251
俺も最近正直そう思うようになった

最初の頃：おぶじぇくとしこう？
途中：OOP！ポリモ！デザパタ本！OOSC本！
その後：関数型？関数と変数だったら変数散らかるんじゃないんけ！
そののち：意外と関数型記述性ある！不思議と短く書けるなんやこれ！
しばらくして：いや？非OOPでも意外と書けた！
　OOP-OOPLというより大事なんは単にモジュール性や！直交性や！
　徹底してインタフェースと実装のシンプルさを保つことや！
今：そんでOOPのメリットって何なんやろな？

そういう本質的に重要な事を記述しやすいってところだろ？

>>255
え?
全然意味わかんない

>>256
そのうちわかるよ

でたｗ
「そのうち」としか答えない相手から聞き出せることはもう無い

>>254
要するに編集方針の違いでしかないんだよ。
出来るやつが書けばどれでもどうとでもなる。
それだけ。
それよりOAOO/DRY/メトリックス(トポロジー)の方が重要。

ソースのどこに記述するか?って方式の話でしかないよね
ボタン1を押したときの処理Aはオブジェクト指向で記述しようがそれ以外で記述しようが
ソースのどこかに記述しなければならない
オブジェクト指向ってのはつまるところその様式美



別にどこだっていいじゃん( ´∀｀)ｂ

そしてウンポコPのペチプァみたいなゴミ屑コードができあがる

そのボタン1は、UIコントロールの基底クラスを継承するというOOPで作られてるとは思うけど
まぁだからといって使う側がOOPに従わなきゃならん、ということにはならないな

ボタン1を使いながら「OOPなんて不要！」と言ってるとしたらアホだとは思うが

>>262
話の主旨もわからず回答とかおめでてーな

イベントハンドラの引数に押されたボタンのid渡すコード見るたびに
せっかくのオブジェクト指向が台無しになってる感はある。

クソコードハラスメントって概念を提唱したい
書いた本人が意図する、しないにかかわらず、相手が不快に思い、
相手が自身の尊厳を傷つけられたと感じるようなクソコードを指します。

糞レベル1. 汚いコードだなぁと思う
糞レベル2. 汚すぎて読むのためらう
糞レベル3. どうしたらこうなっちゃうのか理解不能
糞レベル4. なぜこれを人に見せたのか理解不能

大概書いた奴は既に現場にいないという現実

某糞PHPの糞保守案件でガチで撲殺してやりたいコードあったわ

自社で保守する仕事なら綺麗に書くけど
同業他社が保守するなら難解な方がいいだろ
足を引っ張って競争が優位になる

無駄

>>267
こんなんだから凋落してくんだよジャップランド土人が

アベノミクスで不景気だしどこも余裕がない
毎日残業で安月給じゃそりゃ人格も歪んでくる

>>265
その全てをパスしているが動かないコードと
その全てを満たしているが動くコードの
どちらを持っていくかと言われたら迷わず糞を持っていく俺

>>271
動くなんて大前提だよ
そんなんだから脳みそまで糞まみれなんだよボケナス
殺すぞ

>>272
動いた上でさらに付加する価値だろ?
そんなの省かれるに決まってるだろ
いい加減テメェのこだわりは重要じゃねぇって気付けよ

結論が出た様です
>>265のセンスのない造語の使用は却下されました
妥当な結果でしょう

仕様が無いのになぜ動いていると言えるのか。

動いてるとも動いてないとも言えない
これが波動関数ってやつさ

>>275
仕様がない＝動作が正＝動いている

仕様がないつまり未定義
つまり何が起こってもおかしくない
パルプンテ状態

Cの悪口はやめろ

初期化以降はリードオンリーとするフィールドint barがある場合
class Foo {
private int bar;
public Foo(int bar) {this.bar = bar;}
public int getBar() {return bar;} // ゲッターだけ公開
}
↑こうするより↓こうしたほうが色々気持ちよくない？
class Foo {
public final int bar; // C#ではfinalのかわりにreadonly
public Foo(int bar) {this.bar = bar;}
}
どうよ？

>>280
C#ならプロパティ使えばよくね

>>281
Java脳だから仕方ない

C#は、自動プロパティの初期化もできるようになったしな

OOPでフィールドを丸出しなんてはしたないことはやめてください

>>284
それに対する俺の考えはこう
・あるものが不変で良いなら不変にしておきたい
・不変であるのならメソッドを経由しなくていい
・フィールドをpublicにしておける言語がある理由もそこらへんじゃないのかなっ
どう？
「OOPで〜」に対する返事にはなってないかもしれないけど

フィールドは実装
実装を晒しては行けない

オブジェクト指向的にはプロパティへのアクセスはメッセージに限定してカプセル化としたいんじゃないかなぁ?
って思う

元の主張はいったん置いとくけど

>>286 >>287
そういうOOPLがあったらいいのにね（あるかどうかは知らない）
それはそれでスッキリすると思うよ

あとクラス図なんかにフィールド含まれてるのすら嫌だもん
>>286的理由で
インタフェースで考えていたいレベルに実装が飛び出てるのが嫌だしダメだと思う

そういうOOPLってのは
フィールドをpublicに出来ない言語って意味ね

ま、はしかみたいなものだね
OOの美学みたいな考えがあるんだろうけど
よくよく考えると大した概念ではないし、本質的でもない
多くのOOPはマルチメソッドをサポートしていないので
二つのオブジェクトに跨る処理をどちらに書こうかという
問題にぶち当たるし、得てしてそういった複数のオブジェクトに跨がる処理が
そのプログラムの本質的な部分であったりもするからね
プログラムの簡単な部分に関しては簡単に書ける、それがOOP

OOはどちらかといえばデータ構造に基づいた設計手法で
(あ、クラスはデータじゃなくて機能って言う人もいるだろうが
データに対する機能を提供している側面があるので・・)
空間に基づいた設計手法といえるが
当然、時間に基づいた考え方というのもあり得て
プログラムの本質が手続きであり、命令を上から順番に実行していくものだとするなら
こちらのほうが本題かもしれなく、少なくとも何がどの順で実行されるか
良くわからないという事態だけは避けなければならない
あまり自律的なオブジェクトを設計してはダメってこと
AがBのメソッドを呼んで、その中で今度はBがAのメソッドを呼び出す・・・
ということは避けなければならない
なぜならAがBのメソッドを呼び出したとき、Aは処理の途中であり
その状態でBがAのメソッドを呼び出すのは危険だから
デッドロックの危険性もある
オブジェクト同士がメッセージをパッシングし合い、まるで生態系のように振る舞い
結果として何らかの機能が提供されるというのは、機能の観点からは遠回りであるし
何がどの順で実行されるかよくわからないという意味で、手続き的には厄介だ
俺たちは何かのシミュレーションがしたいというわけではない
AとBをコミュニケートされるなら、それらの親にあたる部分が仲介すればよく
AとBが直接コミュニケートする必要はない
そうすれば手順が明確になる
オブジェクトとは良きパーツであるべき

private Integer id;
private String domain;

String getAccountId() {
return domain + "-" + id.toString() + ;
}

こんな感じで、ゲッタの方が処理挟まないといけんくなったとき、ラクダからちゃう？
でもやっぱaccountId定義してコンストラクタ初期化すれば
やっぱフィールドおっ広げいいかとも思っちゃったり

リフレクションでめんどくさいからやめろよ

>>292
それはじめると君の同僚たちもそれに倣って、
結果、画面にもSQLにも業務ロジックにも、至る所に文字列操作が書かれるぞ
連結してaccountId作ったり、accountIdを文字数や正規表現でidとdomainにバラしたり…

class User {
private Integer id;
private String domain;

String getAccountId() {
return domain + "-" + id.toString() + ;
}
}

ならええやろ
user.getAccountId()や

至る所で
String aid = user.getDomain() + "-" + user.getId();
こんなんされるよりまし

それだと至る所でハイフンでsplitされるって話だろ
AccountId値型を作ろう

instanceおじさんをレイオフする会を発足します

本来であればフィールドメンバと引数とわずかばかりのシステムメソッドで処理を完結するのがベストなのだが、
それしようとすると、やりたいことをやるために必要な情報がなかったりして
親の親から引数を渡し直さないとけなくなったりしてそうこうしてるうちに
結局グローバル変数やシングルトン(instance)で便利になったと喜んでしまう性。

>>295
現時点でCallerには「domain-id」の文字列以外必要ないなら、それでOK
Callerもid or domainが単独で必要ならgetIdやgetDomainもつける

IDだけじゃなくて、たとえばなんかのログインフォームのようにメールアドレスもサポートするならクラス側で承ける
文字列返すかAcccontDataクラスでも作るかは
idの形式があと3つ4つあるか（ついったと顔ブックとなんちゃらinアカでもログインOKみたいな、ならクラス）
or メルアドのみで数年やれるか（なら文字列でサクっと実装しちまえよ）による

ワインと豆腐には旅をさせちゃあいけない
という山岡さんの名言がある

俺は変数にも旅はさせてはいけないと思う
つまり、変数はprivateにのみしておいて
それを外に参照させたり渡したりしないうちは安泰だということ

漫画を引用する様な見識の狭い奴の言う事を誰が本気で聞くのか
語りたい事があるなら自分自身の言葉で語れ

旅をするのは変数ではなく値なんだけどね

グロバール変数やめました
シングルトンもやめました
結果、
オブジェクトをたらい回しにしまくりんぐ地獄

郵便物が来たってメモはたらい回しでいいけど、
郵便物自体はたらい回しするなよ。

それは郵便物オブジェクトが人間オブジェクトにメッセージパッシングして言ってんの？

郵便物オブジェクトは何もしないだろ。
メッセージをパッシングしているのはメッセンジャーさ。

メッセンジャーヴォーイズはどこで何をしてるんだい？？

staticおじさんは今日も元気でした

>>308
言葉に気をつけろよ
キャットドア問題の前にお前らはボロ雑巾のように敗れ去っているのだから

勝ち負けだったのか

>>310
負けは認めるんだな

ごめんやけど最近来たから勝負してたところを見たことない
どんな勝負だったの？

あとキャットドアって初めて聞いたんだけど何なの？

>>キャットドア問題
ググってもAmazonしか出てこない、、、

google「オブジェクト指向　キャットドア問題」
で出るな

>>315
まじか！
ありがとう、見てみるよ

なんか別のスレがヒットするだけなんだけどあってる？
http://itest.2ch.net/test/read.cgi/tech/1491118238/

キャットドア問題って何だよ
博識な俺様でも知らんぞ

それを流行らせようとして必死なやつをどっかのスレで見たわ
放置推奨

なんだ
騒ぎ立ててるヤツが居るだけなのね

なんかおもしろい議論があるのかと思って期待してたのにな

結局、キャットドア問題解決できなかったしね

>>315
オブジェクト指向 "キャットドア問題"
9 件 （0.37 秒）

キャットドア問題が何を問題にしているのかわからない
合力できるようにDoorOpenerCompositionを定義すれば済む話では？

(new Cat(weight: 5)).can_open(new Door(weight: 4, knob: true)) //=> false
(new Human(weight: 15)).can_open(new Door(weight: 14, knob: true) //=>true
(new Cat(weight: 5)).can_open(new Door(weight: 4, knob: false)) //=> true
(new Cat(weight: 5)).can_open(new Door(weight: 10, knob: false)) //=> false
(new Cat(weight: 4) + new Cat(weight: 3) + new Cat(weight: 5)).can_open(new Door(weight: 10, knob: false)) //=> true

staticおじさんは今日も大勝利

結局どんな勝負なの？

>>325
結局、キャットドア問題解決できなかったしね

キャットドアとやらが拠り所なのか…

if cat door is open
human begining become
and we will we will goto heaven

ごめん、それでは理解できない
どんな勝負だったの？
勝利条件やルールは何だったの？

何かの引用のもじりなんだろうか？
ひどい英語に見えるけどなんか意味あるのかな…

>>329
逃げるのか？

ネコ用のドアって蚊やハエが入って来ないの？

>>331
や、だから俺はそもそも勝負に参加してないっての
参加するにしても勝利条件とルールを聞いても誰も教えてくれないから参戦もできない

>>333
マヌケなヤローだ

ああ
これは会話させてくれないやつだ

放置推奨と言われた意味がやっとわかった

>>335
いいや、本スレに行って参戦宣言でもすれば即座に着火するよ
みんな内心納得してないからね

クラス階層をどう作るか、メソッドをどのオブジェクトに持たせるかっていう、大抵は主目的にならない部分の問題を、
現実世界の物理的な制約、言語学や分類学の観点から「〜であるべき」と主張しあうおバカな問題だよ＞キャットドア問題
たまに出現してスレを白けさせる美少女クラス云々と同類。

プログラミングを知らなくても身近なものを抽象化して語ることは誰でもできるから、無駄にレスが稼げる

それは抽象化ではないとだけ言っておこう

>>337
おバカな問題だということが分からないやつがたくさんいるから
似非開発者をフィルタリングするのに便利だよ

頭が悪いという事実以外にどこに問題があるのか

まあな、お前らほど優秀な奴らがあの場にいたらキャットドア問題など発生すらしなかったんだろうなｗ

どんなに優秀なやつが居ても無理
自分の考えることが正解で他はダメみたいな考えしてるやつらの口論に出口はない

>>323
俺はこんなコード書きたくないなあ

>>343
お前が書かなくても>>323が書いてお前に保守させるから問題ない

>>344
> お前に保守させるから

無理だろｗ
どうやって、やらせるんだよ。
お前に、他人に何かをやらせる力なんてないだろｗ

>>337
わかるわかる
美少女クラスがどうとかウンコがどうとか
そーいうので必死でレス稼いでる子がいるよな
自転車置き場議論の一端だよな
これならレスできる！って連中が集っちゃう

OOの技術って何って言われたら
整理整頓術、としか言いようがない罠
とりわけコードに対して、オブジェクト(クラス)にぶら下げとけば良いんじゃね？っていう
多態だ継承だっつっても、コードをオブジェクト単位で整理したときに
ちゃんと動くようにするための仕組みでしかないよ
それなのに犬は哺乳類で猫はニャーとか、最近はこういうこと言う人居なくなったけど
かつて本当にバカげたことを言っていたよね
仕事をするうえで整理整頓は重要だけど、作業性の問題であってサイエンスでは無いしな
いやね、まじめな話、作業性さえよければ何だってかまわないでしょ、マジで
だから結局、作業性の問題なんだよ、これは

作業性？

我々生まれもって木構造が好きだから
クラス階層というもんのドキュメント性も何か
心惹いてたんだろうねえ
継承がもたらすポリモの便利さにくわえてね

実際、作業性なんだよ
作業性が良いと、仕事が早く終わるし、ミスも減るんだよ
そのために整理する仕事があるんだよ
どこの工場でもやっていることだ
工場に限らず仕事は全てそうではあるがな

逆に物凄く崇高な理論や思想が何かあったとしても
余計に時間がかかってミスも増えるんなら糞くらえだろ
家に帰れなくだけ

まぁソフトウェアの設計といえば
どれだけの時間で処理が完了するか見積もったり
メモリ使用量を算出したり
そういう楽しいのはあるけども
OOはそういうのじゃ無いよね
OO設計は完全に整理整頓術以外の何物でもない
とりわけ、コードを、どこに、書くか、という問題

>>351
普通にメンテナンス性、可読性、
複雑なものをシンプルにする技術とか
言えばよくね？

で、それって何？って言われれば
まとめて整理整頓術としか言いようがない

作業性って工場系の用語だと思うんけど定義を教えてくれ
作業のしやすさ＝作業性？
それとも作業効率を高める性質＝作業性？

自分の周りじゃあまり使われない言葉だけど便利そうだな

> 整理整頓術

これも自分の周りじゃ使われない言葉だな

大体において、作業がしやすければ、作業効率は高まるもんなんだよ
ここで、ごく一部の例外とか、そういうのはどうでもよい
基本的な原則といって良いだろう
だから両方の意味でつかわれるし、両方同時に言ってるし
付け加えれば品質の意味も含まれる
作業しやすいほうが品質が上がるのは当たり前だからな

ただ、作業性の意味が分からないってのはちょっとアレじゃねって
俺は思うが
別に工場用語でも何でもないし

あと、整理整頓術も工場用語でも何でもないぞ

それからソフトウェア業界であまり使われないのはそうだろう
俺があえてこの瞬間そう言ってる、言い直しているってこと
OO設計は結局整理整頓術ってのは俺の意見であって
Wikipediaに書いてあるようなことを書き込んでも面白くないだろ
要はバカっぽく言い直しているってこと

工場での生産の作業性をぼんやりした形で適当に定義しないでほしいな。

作業性が良ければ早く終わる、は幻想。
早い、安い、旨いは3つを取れないもんなんだよ。早くてうまけりゃ安くは無いし、早くて安けりゃ旨くはない。
効率を上げるには工程に工夫がいるし、工程を楽にしたけりゃ単純性が居るし、単純性を上げるには効率をさげにゃならん。

>>357
お前が馬鹿なのか勘違いしてるのか、恣意的に混同してるのかわからんが、少なくともお前が言ってることが机上の崇高な理論で思想だよ。

>>357
もうちょっと整理整頓して文章書こうな（藁干草）

吉野家は3件全立してると思ってた

>>361
高くはない、まずくはない、遅くもないものはなんとかなる。
その状態が、生産ラインの安定地点でもある。

>>358
そんな細かな話は一切してない
彼方を立てれば此方が立たないって領域の話は、個々に対応する話であって
それ言い出すと、美女のウンコの話になる
つまり、対象とする要件がわからないのに、美女クラス作るのは無理
不毛だろ
ただ明らかに作業性の悪い状態で作業すると作業効率が落ちるのは確か
そのことしか言えない

しかし、OOが整理整頓術と考えれば、美女のウンコであるとか
キャットドア問題とかいう意味不明なやつとか、心底どうでもよくなる
それが狙い

POAやDOAは整理整頓術とは違うの？
整理整頓術は作業性を高めるためにあるとして
異なる整理整頓術があるのは重視してる目的が異なるからじゃないのか？

整理整頓じゃなくてモデリングだな
設計とも言う

オブジェクト指向って処理をソースのどこに書くかってだけの技術だしね
どんなにこねくり回しても直接的には１円にもならないんだよね
違うと認めないやつもいそうだけど
そろそろ自分が扱ってるモノの本質を見定めるべき

それをバカにしつづけた結果
メンテ不能なモンスターができあがり
ビジネスチャンスを逃す

>>366
お前のその考えじゃ一円も生み出せないわな

>>366
需要さえ見出せばいくらでもお金になるよ
小手先の技術より経済の本質を見定めればいいと思う

経済の本質？ロボットによる自動化かね？

>>363
個々に対応しない全体論なんてあるわけねえじゃん。
頭おかしいのか？

じゃあお前キャットドア問題解けるの？

>>372
次世代言語の前スレで単なるオブジェクト指向では無理でしょ的にGoで断片書いた。

>>373
書いたじゃなくてその話をここでもう一度やれって言ってんだよ

>>374
何でもう一度？一回やったのに生産性無い事をしたがる/させるんだなぁ。
もう一回話したいテーマ挙げてよ。
少なくともキャットドア問題とやらは問題自体に不備があるから、何の解もありえないだろ。
正しく問題を出し直すなら出し直せば？

>>374
オレは>>323に書いた
これだと駄目な理由を早よ書け

>>376
323のプログラムは何の役に立つの？

>>377
キャットドア問題が解けること

砂上の楼閣が作れるスコップみたいな話か。

>>377
分脈はおろかコードすら読めない奴がレスしてんじゃねーよ

>>380
分脈！！

何の役に立つかも考えずにCatやHumanをコードに登場させてるから駄目なんだよ
それが分からないうちあのスレにいた人たちと同レベル
オブジェクト指向わかったつもり系

>>381
さながらキミは文脈わかったつもり系か

文脈系男子は帰って

データと処理が分離してるクセに継承の嵐。
意味不明なラムダ式の多様。
意味不明なabstract縛り
邪魔なprivate宣言
csvの共通クラスだけで10以上のクラス

悪夢を見てるようだ。

これがオブジェクト指向というやつか。恐ろしい。

全てのメソッドにstatic付けられてから嘆け雑魚が

ドヤ顔で言語仕様に振り回されて無駄だらけで読みづらいクソコード量産すんなって話だな。
全部staticのほうが逆に使いやすいなんてのは、もう目も当てられない。
中途半端にスキルあるヤツに多いんだよなあ。

>>386
その中途半端なスキルの奴は、もう次の段階に行ってるよ。
そうやって設計手法に振り回されながらも実践し、失敗を繰り返すことで成長していくんだから。
で、お前はそいつの成長過程で産み落とされたゴミをメンテする役ね。成長はないけどまぁ食っていけてるならいいんじゃない。

レッテル張りして、プンスカ怒ってるみたいだけど、そうとう図星だったか。
設計ミスるのも程々にしとき。

>>388
お前は設計ミスなんてしないもんな
なぜなら設計したことがないからw

なんか、もういいや。建設的じゃねーし。

オブジェクト指向言語って、構造体を拡張して作ったクラスに一事実一箇所の概念を持たせたものって認識で良いの?

オブジェクトという概念を実現するために、構造体に操作を持たせただけなのに、古い人が構造化プログラムから転向できないのは何でだろう

構造体知ってれば自ずと解りそうだけど

>>392
多くの人にはドメインのモデリングが難しいから
手続きを箇条書きする方が簡単だから
構造体がわかることと構造体を組み合わせて大きなシステムを構築できることは別物だから

古い人もオブジェクト指向が理解できないわけではないんだろうよ
ただ、今までそれなりに書いてきてて
要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
あと、オブジェクトに着目するって発想がアホっぽくて嫌だとかかな
若い人は何も考えないからそのまま受け入れるかもしれないが
それなりの経験を積んできた大人からしたら
こういったアホっぽい発想に拒否反応が出ても仕方がないんじゃないかな

やはりプログラムで一番複雑化しやすいのは複数のオブジェクト同士の相互作用で
自分自身にしか影響がないような処理はOOではカプセル化するが
そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
だからOOは元から簡単なことをより簡単にする為のものともいえる
簡単なことがより簡単になるから、難しいことに集中できるってアイデア
もともとgoto文を使わずにfor文を使いましょうってのも
簡単なことを簡単に書くための物だから方向性はあってる
ていうか、プログラミング言語の進化自体が、簡単なことや頻繁に出てくる処理を
構文でサポートして、難しいことは自分で考えてね、って歴史だから
OOも例に漏れずって感じ

あとは、手続き型言語である場合は処理の順番も重要かと
処理の順番を間違えるとあっという間にバグる
継承による差分プログラミングが上手くいかないのも処理に順番があるから
継承元のクラスの処理のされかたについて正しく理解してないと差分だけ書いたって上手く行かない
協調動作させなければならないが、それには処理の順番が重要になってくる
それと、OOになってから処理の順番は、むしろ分かりにくくなってる節がある
クラス単位で処理が細切れになっていたり、仮想関数で目に見えない分岐をしたり
そーゆーのを嫌うってのはあり得る話
処理順が明確なプログラムのほうが読みやすいってのは普通に有る

↑のようなことを理解したうえでOOを使うのは全然よいんだろうが
適当に作られたOOのプログラム、特にOOを使うこと自体が目的であるかのような奴はマジで糞だから
そういう麻疹みたいなのに自分が巻き込まれないように、自衛のためにOOを避けたり
使わせなかったりってのはあるだろう（Linusとかね）

おっさん主導プログラミング
は根性駆動

この業界はKKD法のシェアが一番

根性って大切なんやで

大事かも知れんがそれで全部解決させようとするのは愚行すぎる

オブジェクト指向を理解した上で採用しないオジサン居るのかな

構造化プログラムで思考停止してるのばかりな気がするけど

たいてい制御系上がりの上司

>>400
構造化もDOAも本当は理解してないから無理

構造化という言葉の意味を知らないとしても、いまどき構造化プログラミングから外れるようなコードってあまり見ないよね。

構造化プログラミングは人類の至宝
制御構造、サブルーチン、ブロック
こんな大事なもんほかにあるか？

正しい名前付けとディレクトリ構造の方が重要

俺は>>403に賛成なんだけど
面白いのは>>403のように、動き、動詞、メカニズムに拘る人もいれば
>>404のように、名詞、物体、に拘る人も居るってことだな

>>394-395
意見について反対は無いが、俺の例で言うと、

> 要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
ただ単に必要を感じなかったから、だね。
とはいえ、適切に使えばOOPの方が見やすくなるのは確かだから、
やってないだけの奴にはとにかくやらせればいい。

> 自分自身にしか影響がないような処理はOOではカプセル化するが
> そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
いや、元々自分自身にしか影響が無いのなら、べたに書いても疎結合化はされてる。
というか他の処理とつながりようがないし。
OOP構文を使えば、スコープが分離されて、文法的に疎結合化が確約されるだけで、
プログラム自体の構成には全く影響が無い。
だから所詮は編集方針の違いであって、本質的にはクラス階層が導入されたに過ぎないんだよ。
とはいえ、クラスライブラリが提供されていれば、それを使った方が楽なのは確か。
使わないのはただ単に、無くてもなんとでもなるのと、（俺の場合はこれ）
自分がすべてやることに慣れているから、逆にブラックボックス部分があると怖いとかじゃないかな。
あとCみたいに限界まで無駄をそぎ落とすことに慣れていると、
クラスみたいにある程度の無駄を許容してコードの簡素化を優先しようという思想が嫌いだったりする。

> 協調動作させなければならないが、それには処理の順番が重要になってくる
継承をガンガン使って思ったのは、コードの記述順が超重要だということ。
これは昔のコピペプログラミングだと、実はかなりルーズで、あまり気にしたことが無かった。
（動けばいい、位のノリで書いていた）
ただこれを仕様が確定する前に完全にうまく書ききることはかなり難しい。
だから差分のみでは済まず、結局元のクラスのメソッドをチョイ修正する必要があったりする。
結局、○○を使ったから馬鹿でも超楽勝！、なんてことにはならない。
むしろ、OOPの方がシビアになってる。
これを何とかするのがインミュータブルや参照透過や再代入禁止のはずなのだが、
（適切に使えばコード順はほぼ自由に出来る）
関数型()のアホ共はこれを理解できずに見当違いの方向に暴走してる。
まあOOP側もOOPが目的みたいなコード書いたりするし、結局本人次第でしかないが。

関数型についていえば、本来はOOPでも対応できない巨大コード/構成を相手にするためのものであって、
関数型()の連中はわずか数行のコードしか相手にしてないから駄目なんだと思う。
というか、大規模コードを書いたことの無い関数型信者は基本的に馬鹿なことを言っていると思う。

ところでlinusってOOPさせないのか？知らんかった。

せいぜい数十行のコードを書いて、あのメジャー言語よりみじけー！とか言って喜んでるのが関数型にわかだよ

ちなみにググッたら簡単に出てきた。結構有名みたいね。
https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html

まあ言っている内容はごもっとも。流石と言うべきか。
とはいえ本質的には結局本人が出来る奴かどうかであって、
言語とか○○型とかは関係ない気もするが。

ところで話題のGitのソース眺めてみようと思うが、どれを見ればいいのかな？
https://github.com/git/git

>>408
ちなみにErlangは明確にスケールアウトを目指していいとは思う。
あれが正しい関数型の使い方だろう。
（あまり知らんが）Haskellは結局遅延評価だけで、
HaskellHaskell言っている奴は基本的にゴミのような印象しかない。
他に使われている関数型はOCamlか？あれは何がいいんだ？
知ってたら教えてくれ。

>>403
オブジェクト指向は構造化プログラムを別に否定してないよね

俺は本人じゃないが、そもそも元の文章は
オブジェクト指向は構造化プログラムを否定している
とは言ってなくね？

状態によって実行できるメソッドが異なるクラスってどう実装する？
実直に実装するとinvalid state exceptionを投げまくるかっこ悪いクラスになってしまう

class order {
public void decide() { // 保留中の注文を確定する
assert<invalid_state_exception>(_state == order_state::pending);
_state = order_state::ordered; }
public void cancel() { // 注文済みをキャンセルする
assert<invalid_state_exception>(_state == order_state::ordered;
_state = order_state::canceled; }
// 省略
}

もちろんこれは単純なサンプルで現実的にはもっと複雑なビジネスルールがある

Stateパターン使うのかなとも考えたけど結局空のメソッドからnot supported exceptionを投げるようになるだけで本質的な解決策にならない

状態によって実行できるメソッドが異なるクラスって実装しない

Stateパターンつうのはこの場合
キャンセル、保留中、決定済み
これらそのものをオブジェクト化して置き換えて運用するんじゃないんけ

>>414
その場合もorderからorder_stateに移譲するだけだから結局、例外出すだけのメソッドにならない？

>>412
値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
値は値なんだし。
値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
しかも、何かさせられない状態すら持ってる。これヤバい。
何かさせられない、の定義が変わったとき過去データの扱いとかどうなるのか、すごい慎重にクラス作らないといけなかったり色々辛いと思う。

Orderクラスはオーダの状態だけを管理して、
OrderManagerみたいなクラスと関数で、
Order OrderManager.Cancel(Order order)なり、
Order OrderManager.Decide(Order order)みたいな物で触った方がいいんじゃないの？
そしたら、各メソッドでの引数の条件のチェックも楽だし、何よりテストが楽じゃん。

>>416
う〜ん
オブジェクト指向でやるか関数型でやるかは人それぞれだと思うので深入りしないでおく

ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう

interface IOrder
CanceledOrder implements IOrder
DecidedOrder implements IOrder

CanceledOrder cancel(DecidedOrder o) {}

これでどや
cancelメソに変なo渡そうとしても、コンパエラーで弾けるンゴ

>>417
関数型に見えるけど全然関数型じゃないよ。
オーダーってなんぞとモデル化した時に、
伝票と伝票処理する経理の人を浮かべただけ。

呼んではいけない処理を、「呼んではいけない」と決める事について、呼ばれる方が自分で宣言するってどーなの？

経理部の上長だけは注文済みから直接保留に戻せるとか、新しいロジックはいくらでも来そうな要件なんだし、その判断は操作する側が見てやる必要あると思う。

a+bしたら、勝手にa+=bされてるような気持ちわるさ。a.plus(b)は、aではないa+bした新しいインスタンス返してほしいってような感じで。
その上でa.div(0)が例外を吐くか、それともエラーな型返すかは別だけど、少なくともaが破壊される事はやめてほしい。

invalid argument exceptionで例外として扱うから辛い。
サブタイプでエラーなOrderのクラスにするか、
最初からにsanityみたいなプロパティのフラグ持たしといて変な事したら倒しゃ良いじゃん。

状態によってメソッドが異なるというのがオブジェクト指向と合わない気がするね
メソッドを呼ぶ側がオブジェクトの状態を気にするのは変だし

>>420
うん。もしくは、モデル化に失敗してる。
正確には、メソッドは呼んでもいいし、そこで例外を出しても良いけど、だいたいそういうのはトランザクションチェックとかになると思う。
掴んでるOrderが最新でなければどの行為も全てできない事、とか。
履歴が必要な類のシステムはそんな感じかと。

「注文」だと、Decideはほとんど客がやるが、Cancelは客も店もやる。
「注文書」の「「発行」「取下」「受領」「可決」「否決」「発送番号交付」」くらいに分けとけば
「発行」「取下」は「客」が出来て、
「取下」「受領」「可決」「否決」は「事務方」が出来て、
「発送番号交付」は「現場方」ができる
みたいにモデル化しやすい。
全部Operatorがやるべき事で、できるできないは注文書の状態や自分の職位の組み合わせで決まる事かと。
受領済みでなければ取下できるが、受領済みであれば取下できないとか、
取下済みであれば受領できないとか、そんなの例外で捌くもんじゃなくて、ロジックで捌くもんじゃん。

>>412
> 状態によって実行できるメソッドが異なる

面白いので、もうちょっと要件を確認させてください

ここで「実行できる」というのはコンパイルが通る、という意味？
それとも型チェックはせずにただ実行時にそういう振る舞いをするオブジェクトがありさえすればよいの？

もし後者の場合、呼んではいけない処理を「呼べない」というのは具体的にはどういう仕組みを想定している？
「not supported exceptionを投げるようになるだけで本質的な解決策にならない」というからには
実行時に例外をあげるのでは不十分ということなんだよね？

認可を各Modelに入れ込もうとするからややこしくなる

とりあえず認可の話ではない
サービスレイヤーで認可を済ませた後
オブジェクトの内部状態によって呼べる呼べないを判断する
orderedのorderをdecideすることはできないしpendingのorderをcancelできないという事実に権限は関係ない
orderedのorderをcancelできるのは誰だといった問題は別のところで行う
orderは短い例であって実際の業務ではorderではないし状態数はもっと多い(5〜10程度)
それぞれの状態で実行できないメソッドが1つ以上ある

すると、状態を確認して例外を投げる、という定型的なコードをあちこちに書くことになって精神衛生上良くない
Stateパターンを使えばクラス内部の定型文は排除できる
しかしその場合でもクラスの利用者が、状態を確認してメソッドを呼ぶ、という定型文を書くことを避けられない

このやり方は殆ど能力照会と同じという点で気に入らない
せっかく静的な言語を使っているのだから動的言語のようなことはできるだけ避けたい

お伺いを立ててからご用立てする社会みたいでめんどくさいな
よろしく！って軽い気持ちでブン投げたいわ

>>424
だから、それぞれの状態で呼べる呼べないを判断するのは権限によるチェックと同じレベルの、ロジックであって、例外ではないじゃんって。
認可の話じゃないなら、Not Supportedはもっと違う。サポートされて無いんじゃなくて、その処理は許されてないから、サポートされてないんでしょ？

>>425
確認した結果ならば、例外ではなく、正常系。
デザパタ云々ではない、それ以前の問題。
静的な言語ならではの方法で解決したい、ってのは無駄。
何故なら、例外を投げる時点でランタイム任せだから。

ワインゴの神設計コードをミロや


CanceledOrder implements IOrder
DecidedOrder implements IOrder

CanceledOrder cancel(DecidedOrder o) {}

まちがえたンゴ
こうンゴよ
どうンゴ？


CanceledOrder implements IOrder{
@Override public showOrder(){}
}
DecidedOrder implements IOrder {
@Override public showOrder(){}
public cancel(){}
}

interface IOrder {
public showOrder(){}
}

>>429
Decidedで、かつ、何らかの理由でCancelに失敗した時、cancelがCancelledOrder帰してると詰む。

>>430
それはどう考えてもthrows イレーガル何とかやろ
全部のOrderにisCancelSucseeded()やisValid()生やすおつもりか？

>>431
Orderは、State持ってるだけで良いじゃん。
StateがDecidedか、Decided+Cancelledか、Decided+Recieved+Acceptedか、がまずOrderが持つべき状態。
ハンコリレーする時の、下のハンコ欄みたいな感じ。これはOrderが持つ他無い。
Order.IsStateIn(状態)みたいなメソッド持ってたらわかりやすいし、
Order.AddState(次の状態)くらいで良いのでは？
Order.Lock()
If(Order.IsStateIn(Accepted)){
　なんやかんや
　Order.Commit()
}
Order.Release() //finallyに
では？
Commit()メソッドでDBにセーブした時にDBの最新値と不一致があれば、それはExceptionかと。
どう考えても、のケースはクラスのユーザが判断するべきものじゃないんだから。

>>424
> とりあえず認可の話ではない

>>421
> 「発行」「取下」は「客」が出来て、
> 「取下」「受領」「可決」「否決」は「事務方」が出来て、
> 「発送番号交付」は「現場方」ができる
これ、認可の話だよね

>>424
> オブジェクトの内部状態によって呼べる呼べないを判断する

ここで「判断」するのは誰（いつ）？

コンパイラ（コンパイル時）？　ランタイムシステム（実行時）？　オブジェクト自身（コール後）？

>>433
認可の話だよ。認可と「呼べる呼べない」は、本質的には同じだと言うとる。
「呼ばせられる、呼ばせられない」なんだから。
だから、データになるオブジェクト側が制御するのは悪手。相手方を意識しないと判断できないものを、相手方を持たないものが持つべきではない。

あくまで自分の状態が自分の範囲で正しいか正しくないかを判断する事しか出来ん。
そうしとかないと、密結合すぎて改修不能になるぞ。

なんせ呼ぶ側の改修全てに対応する羽目になるし、改修したらそいつを呼ぶ側全ての動作確認と、場合によっては更なる改修が必要で、そうなったらまた呼ばれる方の改修をして、と
そこそこ悲惨な事になる。下請けを札束で殴るような改修になるぞ。

正直、日本語が下手すぎて、何を言いたいのかよくわかりません

>>436
要は、データはデータらしくしてろ、と。
伝票がペンを跳ね返すような真似すんな、書けていい。
単に正しい人間が正しく書いてない伝票が無効になるだけだ。書く書かない、書ける書けないは人間の問題だ。
って言ってる。

interface使えばいいだけの話

>>437
「注文が発送済みになったらもうキャンセルできない」は誰が判断すべきだということですか？
・注文自身
・キャンセルしようとした人
・その他

>>439
お前ほんと筋が悪いなぁ

「保留中だとキャンセル出来ない」を認可の話と認識してしまうのはちょっとおかしい
「99レベルだとレベルアップ出来ない」を認可の話と認識してしまうのと同じようなものだよ
認可ってのは「申請者本人とスーパーユーザーは申請済みの注文書をキャンセルできる」とか「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」とかそういうこと

言葉はわかりづらいので数学で示して

>>439
その他。
注文に対する処理を行うロジック。

>>441
レベル99だとレベルアップ出来ない、は話が散らかってる。
レベル100になるために必要な経験値が定義されていない、が正解。

そうじゃなくて、「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」と同じく「自分の権限が及ばない物は変更ができない」でしかない。

>>443
もうめちゃくちゃだな
そのうち100円と20グラムを足し算できないのも権限の問題とか言い出しそうだ

>>444
それは逆に聞くが、各ステータスのOrderは100円と20グラムくらい違う単位系のアイテムなの？
足せないなら、それはデータ同士の問題でオペレーターの問題じゃない。

>>421で言ってるようにトランザクションの問題として扱ってもいいし、
円が入るフィールドにグラムが入ってるかグラムが入るフィールドに円が入ってるかわからんが、とにかく腐ったな伝票としてそれ以上動かんようにロックするしかないだろ。
一回腐ったものを、腐ったもの側からリカバリするのは無謀そのもの。

>>443
一貫性がないんじゃないの？

>>437
> 書く書かない、書ける書けないは人間の問題だ。

>>443
> 注文に対する処理を行うロジック。

まぁ、オブジェクト指向としては>>424が正解だと思うんだが、なんで話が紛糾するのかわけわからんわ

>>446
人間の問題、の「人間」はそれぞれの操作をするオブジェクトのメタファだと理解してる？
だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
各「操作するオブジェクト」全部に同じ処理書く訳であるまいし。

>>447
間違い。
オブジェクト自身が「操作できる」「出来ない」を決められるのはオブジェクト自身が一人で判断できる事に落とし込むべき。
古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃないでしょ。

>>448
> 古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃない

M にロジック入れずにどこに入れるのさ

http://aokilab.kyoto-su.ac.jp/documents/MVC/page3.html

だな。ロジックにもいろいろあるが、
ビジネスロジックはMに入れるけど。

>>448
> だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
「注文書自体の状態を変える」主体が誰/何かを聞いているのではなくて、できるかできないかの判断は誰/何がすべきですかという質問です

で、OrderMode, OrderController, OrderViewがあったとしたら、OrderControllerであるというのがあなたの答えであるということですか？

> >>447
> 間違い。
> オブジェクト自身が「操作できる」「出来ない」を決められるのはオブジェクト自身が一人で判断できる事に落とし込むべき。
「発送されたらもうキャンセルできない」は、オブジェクト自身が判断できますね（ビジネスロジック）
「発送されたらもうキャンセルできない」と、mode.cancel()を呼べるかどうかは別問題ですよ

>>449
確かに。smalltalkとイベントと言われたらモデルが持つべきか。
しかし、決定とキャンセルをモデルが勝手に自分で判断するのはちょっと素直に納得できんな。

>>451
OrderModelとOrderControllerはあるだろうが、
それ自体は見せずに、
OrderOperationControllerかなんか作ると思う。
正常にOrderを失敗したりし辛いじゃん。
注文という行為は正常に行われたけど、在庫が無くて注文の確定は行われなかった、とか、invalid Operationでもinvalid Stateでも無いと思うが。

拗らせちゃった感あるな

例を変えてタスククラスで考えよう
タスククラスの状態は

TODO 作業予定
DOING 作業中
DONE 終了

可能な状態遷移はこれだけ
TODO -> DOING -> DONE

DONEから手戻りでDOINGに戻るかもしれない
とかそういうツッコミはなし
このドメインではとにかく上記の遷移しか許されない
そしてこのシステムはシングルユーザーを想定していて権限の問題は考慮しない

TODOの時のみBeginTaskを実行可能
DOINGの時のみEndTaskを実行可能

どう設計する？

TodoTask型
DoingTask型
DoneTask型
を定義しろ
func(task : TodoTask)
にDoneTaskを渡そうとしたらコンパイルエラーで弾ける
これがオブジェクト指向だ

>>453
TODO以外の時にBeginTaskを実行するコードはコンパイルエラー？
コンパイルは通るけどコールする前に実行時エラー？
コンパイルもコールもできるけどオブジェクトが実行時エラー？（あるいは黙殺？）

無駄過ぎるだろ。
結局そのタスク同士を変換(処理)する奴は、別のアクターでしょ

public class TaskService : ITaskService {
private IRepository<Task> _tasks;
public TaskService(IRepository<Task> tasks) { _tasks = tasks; }

// インターフェース分離の場合
public void BeginTask(TaskId id) {
IToDoTask todo = _tasks.FindToDo(id);
IDoingTask doing = todo.BeginTask(); // ToDoじゃなければnullpo
_tasks.Store(doing);
}

// インターフェース共通の場合
public void BeginTask(TaskId id) {
ITask task = _tasks.Find(id);
task.BeginTask(); // ToDoじゃなければInvalidState
_tasks.Store(task);
}

この程度だと使う側から見てもどっちも大差ないな
シンプルさと失敗の原因がわかりやすいだけ下の方がいいか

夜間バッチのようにもっと長くて複雑な手続きならIToDoTask、IDoingTask、IDoneTaskに分離した方が型安全で書きやすいかもしれん

>>457
気持ち悪いシンタックスだな
何言語？
てゆーかガイジ？

>>458
Javaしか知らない人には気持ち悪く見えるのかな？？