オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/
オブジェクト指向システムの設計 172 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/
javaから入ってオブジェクト指向学んだんだけど、javaと同じようにオブジェクト指向で作っちゃいけないの？
戻り値列挙型で定義したら戻り値二択にしてboolで返せって、戻り値によってswitch文で処理書いてたんだけどそれも全部捨てろって
俺そんなにおかしいもの書いたのかな？
共通化したりするとわかりづらい読みづらいって言われる
共通化メソッドって言うのは例外処理のことね
例外処理一つにまとめたら例外ごとにメッセージ出せって言われたからメソッドこしらえたら分岐とか読み辛いからやめろって
読みやすいように考えたのに、そんなダメだったかな。
簡単にでいいから書いてみ↓
https://ideone.com/
書いたらrunて押せばいいの？
Runでok
Runして表示されるページのアドレスをここに書き込めば、みんなが見れる
こう？
あとクラス名間違えてるごめん。
わかりにくい（怒）
try {
// your code goes here
Director.Create("C:\\testdir");
} catch (IOException ex) {
MessageBox.Show("入出力エラーが発生しました。");
} catch (Exception ex) {
MessageBox.Show("想定外のエラーが発生しました。");
}
これで十分だろ
何ErrHandlerって
再利用性もゼロだし、分割しなきゃならんほど複雑な処理してんのか？
ついでに言えばcatchすんのかthrowすんのか、どっちかにしろよ
このmainはcatchした上でまたthrowするの？
おまえ向いてないよ
誤解がないよう断定調で書く
反省を促すためにも積極的に人格否定などを織り込む
これ良いレビューの基本ね
がんばれよ糞コードヴォーイ
お前はセンスない上頭が悪くてきっとチビデブハゲブサメンワキガだけど、ここにコードを書いたガッツだけは認める
今日流した悔し涙は、明日のお前の血になる
なんとも言えんなー
ぶっちゃけまるっとtry-catchで括っちゃうと不味い場面のが多い気がする
今の職場では「ハイ例外ハイ死んだーエラーログ出てるからオッケー」
なんてノリだけどな
途中で死んで処理切り上げて抜けました後片付けは知りません
落ちて死んだりもしたけれどアプリケーションは元気です!
ってそれ不良品じゃねーか!
って気がしなくもない
DB関連の処理ならロールバックあるけど
やっぱ真面目に作ろうとすると昔ながらのc言語スタイルかなと
返信ありがとう
createメソッドとかcopyメソッドとかが出現する場所全部に入れないといけないからそういう風にしてる
throwはするなって言われたからキャッチした場所でメッセージ出力して、場合によっては戻り値返してる
こうしたくてこうしたいんじゃないけど、現状非難は浴びてるから向いてないのかもしれない
. | | |
∩∩ | | | ∩∩
| | | | | | | | | | | ／￣￣￣￣￣￣￣￣￣￣￣
( ,,) | | | (・ｘ・ ）＜おらっ！出てこい、 ID:aTiidMol
/ つ━━"....ﾛ|ﾛ . | l |Ｕ ＼＿＿＿＿＿＿＿＿＿＿＿
～（ / | | |⊂＿ |～
し'∪ └──┴──┘ ∪
俺様が貴重な時間割いてレビューして下さったんだぞ？
涙の一つくらい流して感謝の言葉でも述べたらどうだ
お礼は三行以上
ついでに糞コード書いてごめんなさい、産まれてきてごめんなさいも言え、このビチグソが
こういう勘違いしたバカがリーダブルコード読んで利いたふうな口をきくからコードが糞臭くなるんだよ
PHPからやり直せ
薬飲んで寝るよ
ちゃんと意見言ってくれただけでもありがたいよ。
薬飲んでるのか？
体は大事にな。
ゆっくり休んでな。
やっぱIT業界って頭やられちまう奴多いんだなｗ
そこまで複雑な処理じゃないんだ。
最初は下位で何かあったら共通処理から上がってきて、メソッド毎に○○処理中に～みたいなメッセージ出力してまた投げて、メインで例外処理するだけのものだったんだけど、それじゃだめだって言われて
例外発生タイミングで例外処理しろって、投げるなって
じゃあチェック処理含めてcreateメソッド囲った共通処理作ってその中でメッセージ出力したらどうだって言ったら
ややこしいからコピペで一回一回囲めって言われたんだ
伝わるかな？
ちなみにそういう時は、コードを2つ並べて書くものだ。
A. 俺はこう書いたんだが、
B. こう書けといわれて戸惑ってる
みたいに。どちらかは丸ごとコメントアウトしておけばいい。
>>15がAで、>>17がBであっているのか？
あとそれが正統Java流だと思っているのなら、とりあえずJavaスレでも聞いてみたらどうか。
もちろんここで既に聞いたことは明示して。
ちなみに皮肉で言っているわけではなく、俺では単に判定出来ないから「聞いてみれば」と言っている。
割とJavaってそんな感じで刻むイメージがあるから。
> やっぱ真面目に作ろうとすると昔ながらのc言語スタイルかなと
それはない。
C言語スタイルでは大規模アプリの例外処理は
大変すぎて手に負えなくなる。
いやいや
だって例外を1番上で捕まえると
死ぬ箇所によって死に方が千差万別よ
それって折角閉じたクラスや関数であっても大ジャンプしてケツも拭かずに飛び出して来るからね
だから例外を一括で処理するとデリケートな処理してっとこだとまじーんじゃねーかな?ってのは思うわ
C++は既にJavaに似た例外あるじゃん
C言語スタイルってなんじゃん？
だから例外ないからその場で処理するしかないだろ
アナルほど凍死罵
> だって例外を1番上で捕まえると
> 死ぬ箇所によって死に方が千差万別よ
頭が硬すぎ。困るときだけ対処しろよ。
困らないときがほとんどなんだから
困るときだけ対処すればよい。
ほぼ全て例外機構があって、例外を使うのが推奨されている。
（例外を使うなって意見聞いたことあるか？）
という現実を見れば議論するべき内容じゃない。
例外が良い。の一択
釣りか？
むしろ使うなという方が大勢だと思うが。
http://www.textdrop.net/google-styleguide-ja/cppguide.xml#%E4%BE%8B%E5%A4%96
Googleは例外が使われていない大量のレガシーコードを抱えている
そのレガシーコードと例外を扱う今風のコードを混ぜることにコストがかかるから例外を使わないというルールになっている
新規にコードを書くなら例外でエラーするのが一般的
>>Googleの既存コードに例外に対する耐性がないことを考慮すると、Googleのプロジェクトで例外を使うのは、新規プロジェクトで例外を使うのと比べて、ややコストが大きいと言えます。
>>例外の変換プロセスには時間がかかり、問題になりやすいものです。また私たちはエラーコードやアサーションといった例外の代替手段が大きな障害になるとは考えていません。
Googleは特殊な事例があるからってだけだなｗ
もうネタ切れ？ つまり例外を使うべきだよね。
（もう何度もやって答え出てること繰り返すのは面倒だ）
会社でどっちに倒すか?
ってなったら俺ならその場で対処だな
ロールバックの付いてないDBみたいな処理のが世の中多いと思う
例えば0割とかモノによってはその場で対処必須なものもやっぱあるわけで
どっちかに方針を統一しろって話になったら例外大ジャンプは取り返しがつかない事態を内包すると思う
まあ、概ね大丈夫ってのはわかるけどね
> 例外大ジャンプは取り返しが
だからさ、例外小ジャンプすればいいだけだろ
なんで使い分けられない？
視野が狭いっていうか、何かをやれって言ったら、
それだけしかやらないやつな。
自分で適切なコードが何かがわからない。
マニュアル通りにしかコードをかけない。
そんなやつがいるんだよね。
例えば例外はちゃんとキャッチしろって言ったら、
はいはいわかりましたよって、すべての関数にtry-catchを入れる。
んで、え？あんたがキャッチしろっていったんでしょ？
だから全部入れてやったんですが？って言うようなやつ。
そこは俺も読んでるよ。
しかし俺は逆に「例外を使え」ってのを聞いたことないんだが、
日曜コードではなくて、マジの商用コードでそういう方針の所ってあるか？
なんのために言語に例外なんて機能を追加していると思ってるんだ？
言語マニュアルを読めば例外はどういうときに使うもので、
どういう使い方をするか説明してあるだろ。
それにその言語のライブラリは例外使われてるだろ。
ごく普通に使われってるとおりに使えばいいだけ。
例外を使っていないライブラリありますか？
という質問に答えてみればいい。
例外を使うのが自然すぎてわざわざ使えという話じゃないことがわかるはず。
エラーと例外の処理 (Modern C++)
https://msdn.microsoft.com/ja-jp/library/hh279678.aspx
>>最新の C++ のほとんどのシナリオでは、論理エラーとランタイム エラーの両方を報告および処理する方法として、例外を使用することが推奨されます。
>>47は>>44宛
レスする相手は俺じゃないだろｗ
例外の使用が推奨ね。
当たり前だが。
情報ありがとう。頭だけざっくり読んだけど、詳細検討には時間がかかりそうだ。
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するなってのは環境的な問題もあるとは思うんだが。
tryで囲む領域が大きくなると、どこでエラーが起きたか、わかりにくい
throwはややこしい。
一々、これは内側、これは外側の関数で処理するとか、変わるのはややこしい
LinuxのようなC言語だと、関数の下の方に、
リソース解放などの共通処理をまとめて、gotoでそこへ飛ばすようにするけど、
まあ、ややこしいプログラミングは避けた方がいい
仕事のプログラムは、個人のプログラムとは、書き方が違ってくる。
初心者・新入社員も入って来るから、自分だけがわかる書き方はダメ
そんな小さい処理で同じとか言われてもな。
resultって数字しか返せないだろ。
例外ならオブジェクトを返すことができる。
エラーとして返せる情報は無限大だ。
見つからないパスがどこか情報だって返せる。
あと自動で上に戻る機能。
とかさ、例外の機能をお前は理解してるか？
してないだろ。
なんでどの言語にも例外があるのかを考えよう。
必要だったから例外を作ったんだよ。
これぐらいは理解しろ。
理解したら、なぜ必要なのかの理由を調べろ。
> 一々、これは内側、これは外側の関数で処理するとか、変わるのはややこしい
うん。馬鹿だからだと思うよｗ
処理する必要があるときだけ処理する。
それだけのこと。
っていうかさ、さっき俺が言ったことじゃん。
自分で何が適切かを考えられない。
マニュアルを用意してほしい、そのとおりにやりたい
自分で何も考えたくない。
やれって言われたからやりましたー。
だから俺の責任じゃないですー。
自分で考えることを何もしようとしない。
だいぶ読んだ。
どっちがいいかは結構微妙だと思うんだけどね。
結局の所全体ポリシーとして「例外」を考慮しないといけないし、もちろんRAIIも徹底してないと危険。
だから出来るだけスマポというのはその通りだけど、
言っちゃ悪いけどRAIIとスマポだけで行く気なら最初からGC言語使えばいいだけだし。
むしろGC言語でGCタイミングをユーザが完全に制御可能にして例外使いまくりというのが正解か？
ついでに教えて欲しいんだけど、下記URLにある
https://msdn.microsoft.com/ja-jp/library/hh279653.aspx
no-fail/strong/basic保証ってのは単なる知識として考慮しろって話であって、
コンパイラに型として指示してコンパイラ側で全部整合性をチェックしてくれるようなことはないんだよね？
どこまで処理するかにもよるけど、原因が分かってそれを通知出来ればいいだけなら、
むしろ「例外機構」の設計が必要になる分、無駄なような気も。
なんつーか、将棋ソフトの駒クラスの例外を設計しようぜ！みたいな。
例えば、
> 発生することのないエラーをチェックするには、アサートを使用します。
> 発生する可能性があるエラー (たとえば、パブリック関数のパラメーターにおける入力検証のエラーなど)
> をチェックするには、例外を使用します。(>>47内URL）
つまり、将棋で言うと「二歩」「打ち歩詰め」は例外として処理しろってんだろ？
なんだかウザイだけの気が。（まあそれ以前に駒クラスが不要だが）
元々は正常処理と異常処理のコードを「見やすさ」の為に分離したいというところから来ているはずなのだけど、
その「見やすさ」を得る為に他も色々注意して設計しろというのは無駄/本末転倒だと思うね。
ただそのコストが環境整備によって極限まで低下したのであれば、それもありかとも思うけど。
それがWindowsの世界なのかなとはgoogleの付け足しから感じた。
どうにもならんところが多いからコーディング規則を逸脱しても仕方がないって感じだな
あんたが例外を使ったことがないから
例外がすごく使いやすいってことを知らないだけ。
何かと理由をつけて使いづらいってことにしたがってるだけだな。
戻り値だと注意が必要な場面がたくさんあるが、
例外だとさほど注意しなくても正しく動くアプリが作れる。
なにせ例外処理する必要が有るところだけ書けばいいからね。
すべて正しく書かないといけないC言語方式は大変。
printfの戻り値までチェックしないといけない。
ちなみにprintfが失敗する例として書き込み不可能な
デバイスに標準出力をリダイレクトする等がある。
例外だとチェックしなくても書き込みができなかったときに
エラーで中断してくれる。
とくにJavaから来た人
型安全だし
型安全だし
例外処理のメソッドを作った理由は「分割しなきゃならんほど複雑な処理している」からじゃなくて
「あちこちで発生する例外」を共通に処理するためだろ
だから当然再利用もしている
「catchすんのかthrowするのか」ってのも意味不明
意図を汲んでくれてありがとう
規約も規則もないみたいで好きに作っていいっていわれたからこう作った。
https://ideone.com/g1uE5d
ちなみにローカル環境でしか動かさないツールだから例外処理はログ出力ぐらいでしか
使わない。
ツールが落ちないようになってるならthrowしちゃいけない理由も特にない。
そうしたらなんでこういう風に作るの？はぁ、ちゃんと見ておけばよかっ、た。
って言われて、レビューとヒアリング聞いてみたの結果これが最適解だった。
コメントは言われたこと少し載せてみた感じ。
https://ideone.com/lbl7VW
これで伝わる？
多少おかしなとこあったとしてもそんなに意味わかんないことしたのかな。
ややこしい？
ファイル作るのにファイル名抜けてたりなんだりしてるけど黙殺してくださいごめん。
コードをたくさん書きたいお年頃的な
なんつーかクドい
下のコードで必要十分に見えるよ
＞予期せぬ値って何？想定があるの？必要？(笑)
同じ感想でﾜﾛﾀ
普通に
オリジナリティなんていらねえんだよゴミが
最後の「ルールの例外」からするとそんな感じだな。
夜はそこまで読んでなかったわ。
>>60,62
大事なことなので？
ってのはさておき、それについても布教用のドキュメントはあるのか？（例>>47)
ググッてもいまいち出てこないんだが。
>>47,48
こんな記述を見つけた。これって何言語か知らないか？
> 言語によっては基本保証やno-fail保証を静的に解析可能なものがあります。
> いくつかの言語ではno-fail保証をそのまま言語レベルでサポートしています。
> コードを静的に解析することでno-fail保証を約束するものもあります。
> また、基本保証を強制している言語や機構があります。
http://qiita.com/Kokudori/items/987073d59529b6c9a37c
初心者であるとかお年頃であるとか
そーいうのじゃない可能性もあるな
文章にしたって簡潔に書けない人おるやろ
あの手の人は死んでも直らない
Eiffelみたいな契約プログラミングによる保証か、
https://ja.wikipedia.org/wiki/契約プログラミング
もしくは、
C++11のnoexceptのような仕組みかな
http://cpprefjp.github.io/lang/cpp11/noexcept.html
>>60のはHaskellのEitherモナドのことを言っていると思われ
http://itpro.nikkeibp.co.jp/article/COLUMN/20090210/324443/
一応、C++やC#でそれっぽいコードを書いている人はいるみたいだが……
>>71
例外が投げられたら、std::terminate()が呼ばれて終了
共通の例外処理を繰り返したくないと書かれてるじゃん
読解力がない上に自分の意見を押し付けるってさあ…
おー書いたか、ご苦労さん。
俺が想定したものとは異なるが、それ以上に情報を含んでいたので、
レビューの様子もよく伝わったぜ。
まあ感想は他の連中と同じだな。
君は難しいコードを書いている。だから駄目なんだよ。
張り切って色々やろうとしているけど、それが駄目なんだ。
手を抜くことには努力を惜しまないってのが優れたプログラマだろ。
少なくともそのレビューと上司はまともだから、言うことを聞いた方がいい。
その上司のコードが何故いいか？それは簡単だから。
構造が単純だから、ぱっと見たらちゃんと動くことが分かる。
それに対して、君のコードはちゃんと動くかはよくよく見ないと分からない。
上司のコードは「自分で処理出来る例外はcatch、それ以外は放置」というポリシーだから、
基本的に下から上がってきた例外は「予想外」として落としている。
つまり例外ツリーは単純なツリー構造で、
このポリシーさえ守れば今後とも簡単に処理を追加出来る。
そして処理も基本的に上から下に処理されるだけだ。単純明快でいい。
対して君のコードは、そうじゃない。
よくよく読まないと果たしてちゃんと動くかどうかも分からない。
そして追加するにしても君が作ったクラスを全部知ってからでないと追加出来ない。
つまり、やることが増えすぎているし、密結合になっている。
対して減らせたのはせいぜいDirectry/Fileの例外の被り部分だけだろ。
それは明らかに設計コストを増してしまっている。
ベタに書くのが悪いとか、同じようなコードが2箇所に出現するのが悪いとか、
そういう単純な問題ではないんだ。
分かりやすく言えば、
「そのコードを初めて渡されて、ああこのコードはちゃんと動くだろうねと分かるまでに、何秒かかるか」
について最適化しろということなんだよ。
当たり前だが全く同じ内容がダブってたら読むのに2倍かかるから、
それはループなり多態なりして一つに減らせってことになる。
だけど無理に多態したりして「コードを追う手間」が増えるようでは駄目なんだ。
その上司のコードはさらっと読んだだけで動くのが分かる。
でも君のコードはあちこち追い回さないと動くかどうかも分からない。
もちろん君が書いたコードだから、君のコードを君が読むのには苦労しないだろう。
だからもし君に同様の同僚がいて、同様に駄目出しをくらっているのなら、
その時の両方のコードを君が初見で読みこんで、
その構造と動くかどうかを把握するまで何秒かかるかを比較してみればいい。
まずMain関数はこれだけだ。
これ以外不要。
public class Test {
public static void Main() {
try {
CreateTempFile("targetPath");
MaggageBox.Show("一時ファイルが作成されました");
} catch(XXXException e) {
MaggageBox.Show(e.Message);
}
}
}
void CreateTempFile(string path) {
String directory_path = ディレクトリのパス(path);
Directory.CreateDirectory(directory_path);
File.Create(path);
}
ディレクトリやファイル作成時にExistsなんてやる必要ない。
Existsのチェックした後に、他プロセスから作成されることもある。
「チェック→実行」のパターンはロック機能がない限りたいていアンチパターン。
public class Test {
public static void Main() {
try {
String path = "targetPath";
String directory_path = ディレクトリのパス(path);
Directory.CreateDirectory(directory_path);
File.Create(path);
MaggageBox.Show("一時ファイルが作成されました");
} catch(XXXException e) {
MaggageBox.Show(e.Message);
}
}
}
このコードを出発点としてだ。
メッセージを変えたいのであれば、
メッセージだけを変えるように工夫すればいい。
Mainに全部入れても良いと言ったが、CreateTempFile()という1関数で実行したいならそれもあり
その場合、CreateTempFile()でメッセージを変えたい例外だけトラップして
メッセージを置き換えて投げ直すだけで、Main関数は>>76のようにシンプルのままでいられる。
情報ありがとう。
> 契約プログラミング
考え方はよしとして、大して採用されてないのは効果がいまいちだったのかな？
> noexcept
お？これはなかなか良い感じ。
ついでにそこから辿れる以下も読んだが、こちらも例外を有効活用しようとしている。
(より正確に言えば、例外を有効活用する時のライブラリの作りについてだが)
http://boostjp.github.io/archive/boost_docs/document/generic_exception_safety.html
例外の文法を使えば、確かに表現力は上がる。それは事実だが、ここに書いてあるように、
当然STLや自前クラスがどの例外保証を持っているかすべて把握してないと駄目だし、
完全活用するとなるとなかなか難しい気がするね。
(プログラミング時に把握しなければいけない項目が増える）
> HaskellのEitherモナド
Haskellの知識はないのでとりあえず日本語部分だけ読んでみたが、
この読み方では有効かどうかは判定不可能だorz
> C++やC#でそれっぽいコード
このURLをくれればすごく助かります。
例外保証ってなんや？
その例外保証があるかどうかわからんものが
戻り値でエラーを返したら、それを保証してくれると
思う根拠は何や？
気をつけることがあるとしたら、それは戻り値でも同じだし
正常処理とエラーを、一つの戻り値（変数）に入れる分
複雑度は上がるんだぞ。
ディレクトリを作れない時に、throwして外のスコープに飛ばすのは、ややこしい。
そこでエラー処理できる
外のスコープから見ても、内側からも、throwしてくると考えると、
考える組み合わせ数が増える。
組み合わせ爆発を避けるため、早期に枝切りすべき
また、内外のスコープで、情報を共有するため、
Commonというグローバル変数もどきを、作らざるを得ないから、
内外の関数が、密結合を起こしてしまっている
修正・保守していくうちに、こういうのがいずれ、スパゲティ・泥団子へと成長していき、
誰の手にも負えないようになっていく
的確な指摘じゃない？
どうみても下の方が出来がいい
>契約プログラミング
C++だとBoost.Contract
.NetだとSystem.Diagnostics.Contracts
があるね
使ったことないけど
>例外保証
なんか、まじめに考え過ぎな気がする
どのクラスがどの例外保証を持っているかなんて、気にして書いている人なんていないんじゃないか
(と、言うとちゃんとやってる人に怒られそうだが)
例外安全、例外耐性を考慮して、きれいにやるなら把握しているに超したことはないけれど
基本的には「いちいち戻り値でエラー判定するのが面倒。戻り値だとエラー判定忘れることがある(アプリがエラー状態のまま動き続けてしまう)。例外をつかえばそれらを簡単に回避できる」くらいの感覚で使われてるんじゃないかな
例えばオブジェクト指向でクラス設計するときはSOLID原則を意識することはあれ、
そこまで厳密に遵守して書かないし、他人の書いたクラスがSOLID原則に則ってるかなんて気にしないでしょ？
それに今時の言語なら標準ライブラリが例外を投げるから、それらを使うなら自分のコードでも例外を使うことで
「このコードでは、エラーは常に例外で通知する」という一貫性が生まれる
プログラミングにおいて一貫性は重要だ
先日のGoogleのスタイルだと「例外を使わない」という点で一貫性がある
もちろん、現実世界ではそんなにすべてうまくいかないから
必要があれば戻り値のエラー通知を部分的に使うのはかまわないと思うよ
.Netにも例外を投げるInt32.Perseと投げないInt32.TryPersreの2種類があるし
>Either
"C++ Either"や"C# Either"でググれば「書いてみた」系のブログが引っかかる
ご回答ありがとうごさいました。
そうかー難しいのか。
難しいということはたまに言われますが、なにが難しいのかわからなくていつも悩んでいるので、自分は設計には向いていないのかもしれません。
下流で頑張ります。
皆さんも今日一日頑張ってください！
それでは！
> .Netにも例外を投げるInt32.Perseと投げないInt32.TryPersreの2種類があるし
名前が重要なんだよ。（ちなみにParseな）
例外を使ったときのメリットは、関数の名前通りの戻り値にできるってこと。
Parseはパースするんだよ。だから戻り値はパースした結果であり
エラーを戻すことはない。パースできなければ例外。
TryParseはパースすることをトライするんだよ。だから戻り値はトライした結果。
もしトライすることすらできなければ、それは当然例外。
その2つは、例外を投げるかどうかの違いじゃなくてやる処理の違い。
そしてどちらもやるべきことができなければ、例外を返す。
これは力説するほどのことだよ。
なぜなら可読性の話だから。
英語わからんとか、ソースコードを命令の並びだとかしか
認識してないレベルの人にはわからないだろうけど、
ソースコードは読むもの。
読みやすさを大きく左右する要素の一つが、
適切な名前をつけているかどうかだから。
たまに適当な関数名つけてる人がいるけど、ほんとやめてほしい。
適当な単語を並べただけじゃソースコード読めないから。
名前から意味がわからないから、中の処理を読んで解析しないといけなくなる。
Parseが返すパーズした結果とは何ぞや？
TryParseが返すトライした結果とは何ぞや？
俺には名前だけではさっぱり分からんのだが
これがお前の望む適切な名前とはとても思えんのだがw
友情努力勝利に決まってるだろ
例外をエラー通知として使う分にはその辺は知らなくていいんだよ。
ただ、例外で復旧させようとするのなら、その辺を全て把握する必要がある。
そして彼等はそれにも耐えられるように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の方が上になる。何もしてないコードだからだ。
生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割は無限大になるというお気楽仕様だ。
当初は驚いたが、正直これで問題ないよなとも思う。
> Parseが返すパーズした結果とは何ぞや？
正しくはInt32.Parseなんだから当然Int32だろｗ
Int32に変換した結果を戻す
（変換できなければ戻さない）
> 俺には名前だけではさっぱり分からんのだが
あー、うん。クラス名が先に作ってことに
気づかなかったのねｗ
>>86で引用してる>>84にかいてあんだろ。
気づけよｗ
おまえは、human.age()で必ずhumanが返ると考えるか？
> なおJavaScriptは0割は無限大になるというお気楽仕様だ。
いや、お前、例外っていったら0除算しか思いつかんのかよｗ
eval("{") とか実行してみろ。JavaScriptは例外を使う言語だ。
0以外の数値を0で割ったら無限大になるのは数学的に正しい。
JavaScriptが無限大を扱える言語ってだけだ。
もちろん数学的に正しいことをやっているから、 0 / 0 は NaN （非数）になる。
少なくともこの点は、お気楽ではなく高度な言語だと言える。
もっともJavaScriptに例外が搭載されたのはJavaScript 1.4（1999年あたり）からだけどな。
それ以前は（エラーを戻り値で返すのではなく）スクリプトが停止され
window.onerrorイベントが呼ばれたんだっけな？もう忘れたが。
もしかしたらageオブジェクトが返るかもしれないからな
> Int32.Parse だからといって、必ずInt32が返るとは限らないだろ
> おまえは、human.age()で必ずhumanが返ると考えるか？
Parseとageで関数名が違ってるじゃんｗ
名前で返すものが決まるって言ってんだろ。
human.parseだったら、human返すんじゃねーの？
そんなの思い込みだろ
ヒューマンパーズオブジェクトが返るかもしれないだろ
> 他の関数型言語の例外機構ってどうなっているんだ？知ってたらよろしく。
関数型で戻り値でエラー情報なんか返したら
大混乱になるわｗ
関数呼び出しの中の、関数呼び出しの中の、関数呼び出しの中の、関数呼び出し で
エラー情報が返ってきたら、if式による分岐の嵐でもはや
関数型言語のように見えないだろうね。
> ヒューマンパーズオブジェクトが返るかもしれないだろ
ほらね？ 何が返るか想像できてるじゃんｗ
Int32.Parseじゃ何を返すかさっぱりわからないって言ってるから
それが間違いだよって話。
なにも100%完全に返り値の情報がわかるなんて言ってないんだよw
まさかこのスレに居ながら、屁臭いペチプ～やゴミのペールやペールの糞からひり出されたルビーや・・・そんな糞まみれのウンコ野郎はおるまいね？
いやお前それ苦しいだろ
>ほらね？ 何が返るか想像できてるじゃんｗ
想像？
思い込みでしょ
ヒューマンパーズオブジェクトが返るかもしれない、とは書いたが
実際には何が返るかわからないから、そう書いただけであって
どうせ、仕様を調べなきゃならないんだよ
言うと思ったｗ
でお前これから先仕様なんて調べるの？
調べないよね。もう覚えてしまったから。
あとは文字を見れば思い出すはずだ。
適切な名前があると覚やすいっていうのはこういうこと。
>関数型で戻り値でエラー情報なんか返したら
>エラー情報が返ってきたら、if式による分岐の嵐でもはや
ifの分岐しないためにfunctorだのアプリカティブだのmonadだのtraverseがあるじゃん？
try1 >=> try2 >=> try3 >=> ... tryN
みたいので「成功するまで処理を続けて失敗したら例外情報をもって途中で抜ける関数」を作れるし
こういう合成力は関数型の強み
明らかに良いコードだろ
頭のてっぺんからケツのシワまで数え上げてようやく読解できるコードが糞じゃなきゃ何なんだ
本当は良い奴も沢山いただろうに不憫だわーw
ってのが解る人ここにいるか?
やはり解る人はいないか
DAOやDTOってのはデータと処理を分離するから手続き的なんだがなぁ
Railsとかもそう。DAOやDTOなんてのは出てこないで
データベースがオブジェクトにそのままマッピングされる。
主張が良くわからない。
http://www.nulab.co.jp/designPatterns/designPatterns3/designPatterns3-4.html
に出てくる例と説明にそって、論を展開してみてくれ。
DAO/DTO
オブジェクト指向論で定義されたものじゃない。
オブジェクト指向で実装されただけで、これらを使うには手続きが必要だ。
それだけだろ。
程度の問題
>>111の段階で明らかだし。
逆だろ
使うのはオブジェクト指向にするためで
その実装の中身は程度の差こそあれ
DBを相手にする以上手続き的にならざるを得ない
そのクラスの中にも別のクラスをコンポジットしてあり…という場合、
最下層のクラスに必要な値を入れるために何度もメソッドを経由するのが大変なのですが
オブジェクト指向ではこれが普通なのでしょうか？
カプセル化せずに
outerClass.middleClass.innerClass.set_value(100);
とした方が楽だと思うのですがまずいでしょうか？
innerClass.set_valueが呼ばれて値が変更されたときに
変更されたことをouterClassやmiddleClassに通知する仕組みが必要になるかもしれないよ
この場合、余計にややこしくなる
そのほかのディメリットはカプセル化しないことで発生するディメリットと同じ
O/Rマッパーを使うからそういう処理は
勝手にやってくれる。
更に言えば
実装方法としても、set_valueは分かり難いし楽でも何でもない
あえてやるなら
outerClass.set_value(key, value)とか？
最低のやり方だな
そのk,vのMap、実行するまで完全なブラックボックスになるじゃん
死んで、どうぞ
くっせ～なホント
こういうペチプ～崩れの塵屑見ると延髄チョップからのバックドロップ食らわせてやりたくなるわ
まじな。死ね。
チンパンジー以下のサルゥ
ほんとつっかえ・・・
血染めの赤にしてやる
死ね
おら何とか言えよゴミ
ID変わるまで逃げるのか？
ほんまつっかえゴミくずやな～
各クラスにユーティリティメソッド実装できるなら、
outerClass.getNodeFromPath("middleClass.innerClass").set_value(xxx)
とか取得関数持っちゃうと、文字列だけ不細工だけどなんとでもなったりするんじゃないかな。
余計なことはするな
http://www.tdb.co.jp/tosan/syosai/4191.html
派遣会社ってピンハネしかしてないのに潰れるの?
トウアは仕事をしない、仕事ができない人間を抱えすぎていたのと、資金がもともとないのにオフィスを分散させたり、複数社のグループにしていたせいで効率が悪かった。
これは会社を大きく見せたい人間が社長の会社の典型的なパターン。
中間搾取でも取引先の支払いが遅いと資金が足りなくなって破たんする。
最後はとにかく仕事を増やして乗り切るつもりだったんだろうけど追いつかなかったんだろうな。
プロパーのレベルが低いのは、賢いSIer、ユーザー企業も分かってたし、仕事をここの下請けに丸投げ、押し付けているのも分かるから仕事が取れなくなっていた。
ドコモあたりのアホ企業頼みだった。
のさばり出した時点で離れた。
俺も一連のやりとりでオブジェクト指向ってやっぱりクソだなって再認識した
ビジネスでやる以上工数は節約しなきゃ
ビジネスだからこそ、手続き型がナンバーワン
ビジネスは君の趣味ではない
ある程度の能力のある人間が工数を減らせる手法で開発する
工数の掛かる手続き型しか書けない読めない人は解雇するべきビジネスだから
ビジネスってさボランティアじゃないんだよね
Viewに関する知識はないからUIレイヤーではないだろう
ビジネスルールに関する知識は必要だからドメインレイヤー？
ドメインレイヤーのインターフェースだけじゃないのかな？
ビジネスルールに関することはモデル内で処理するべきだと思って作ってるけど…
俺も最初はそう思ってたけど現実にそれではうまくいかなかったんだ
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にうんこって入れられても一旦は保存するってことだろそれ
まさにクソまみれ
なんてやってる方が、いずれシステムがうんこまみれになる危険が高い気がするが…
人間だって、目がうんこの反射光をとらえて、視神経がそれを脳に伝えて、
そして最後に脳が「うんこだ！汚い！」ってやるんだから
Modelが「うんこだ！汚い！」と判断するまで、
ViewやViewModelが入力情報をそのまま伝えていくことを
「うんこを一旦保存」とかとらえるのはおかしいと思うんだけどな…
じゃあ超長い文字列とかも一旦は保存するんだろ?
思想に限界があるって気付けよ
データ型のみModel依存ってこだわりがうんこ
画面なんか内部も含めて作り捨て上等だろ
だったら一生懸命付けた汎用性もm9(^Д^)ﾌﾟｷﾞｬｰ
自動計算項目も簡単なものだけを採用する
例えば金額と税率から税込価格を自動計算するとか商品コード入力したら商品名取ってくるとかその程度で我慢する
画面の検証や自動計算項目はあくまで入力支援が目的なのでビジネスルールに完全に遵守する必要はない
ビジネスルールを厳密に守らなければいけないのはアプリケーションサービスインターフェースより向こう側だけ
アプリケーションサービスの内部で画面か受け取った入力内容をドメインモデルにマップしてそこで本気の検証や計算を行う
うんこかもしれないもの、としてVM以降に渡して、うんこではないものを貰うしか無い。
小数じゃないのに小数点が入力できちゃったり
マイナス値なんて取らないのにマイナスが入力できちゃったり
全角なんて入力してほしくないのに全角で打てちゃったり
ファイルパスを入力して欲しいのにパスに入力できない文字が入る
その状態でファイルオープンダイアログ開いたら死ぬの?とか
素人丸出しアプリだな
visualstudioでプロパティいじれば解決する話をわざわざコードで記述してバグる超絶欠陥製品にしかならないだろうね
すべての値のチェックを入口で退治するんではなくて一度保持してしまうから問題を拡散している
undoしたらどこの値に戻るの?それ
何を誤解してるかわからんが、それは、ビューモデル以外の場所で即座に否定されたり、是正されたり、これはは間違ってますよとエラーと判定されるから、
ビューモデルは、判定結果をおとなしく持って、ビューにレンダリングしてもらうだけじゃん。
お前がやってんのは、それはVMの仕事じゃない。
だからさ
その構造を実現することになんの意味があるのって話
そういうのは大前提としてやった上での話だよ
整数入力コントロールには指定した桁数いないの数字しか入らない(アルファベットなどはキーを押しても入力されない)
その上でビューモデルにどこまでビジネスルールの知識を与えるか、ドメインモデルとの違いはなんだ、という議論をしている
データを処理する処理に徹することができるのと
データを描画する処理に徹することができるんじゃん。
現実にはできなくて、やるメリットもあまりなくてって状況だと思うけど
だったら内部の仕様も画面にべったりなんでしょ?
今更分離して何がしたいの?
大規模DBとそれを操作するインターフェイスを真似たモデルであれば
画面なんてプロジェクトごと作り捨て上等なんだよ
DBはもう誰も仕様変更を入れられない
画面は実現したい内容によって完全廃棄もありうる
これが現実なんだよ
VとMVの分離のメリットなら2つ大きいのがある
1. UIの状態数の最小化
2. 手続型から宣言型への移行
画面を使い捨てる前提ならますます分離した方がいい
ひと昔前はViewにビジネスロジックが当たり前のように書かれていた
こういう画面は本当に使い捨てていい画面なのか判断が難しい
画面を使い捨てる前にリファクタリングを行いビジネスロジックを抽出して分析しなければならなかった
必要なビジネスロジックは残して別の画面から利用するように変更しなければならない
この作業が全てうまくいけばようやっと画面を使い捨てる事が許される
現実にはできないじゃん
ちょっと突っ込まれるだけでボロボロ抜けが出てくんだから
最近はちゃんと分離されているシステムが増えてきてる
誰の周辺の話なの?
世界的に
割と大規模やってるけど、気合でWPFに移行してからそこそこうまく行ってるよ。
出来なくて切った会社は沢山あった。
そんな多大な犠牲を払ってようやくできたのか?（笑）
設計ってみんながわかりやすくするためにするもんじゃないの?
選ばれし者しかできない時点で失敗してるんだよ
わかる?
莫大な犠牲は下請けが払ったんだと思うよ。
選ばれしものしかできないとは思わないが、
選ばれしものが出来ないのはある程度あるんじゃないの？
馬鹿とか。
何のための画面と内部の分離だったの?
メリットが見えない
選ばれし者しか理解できないソースと組んだやつしか読めないソースの品質の違いが俺にはさっぱりわからないよ
前者は選ばれしもの(といってもWPF程度なら並みのプログラマで十分なので選ばれしもというのは大げさだが)なら超低コストで保守できる
後者は書いた本人も含めて保守に膨大なコストがかかる
このようにコストが全く違うわけだけど何故同じと思ったのか理解し難いね
メリットが見えないんじゃなくて見えないフリしてるだけだろきみは
全てスタティックメソッドにしなさい
ってことですか？
あーダメダメ
退化する
古き良きプログラミングの時代、復活の刻
え?でもいまの状態で画面と内部の分離ができてないじゃん
値のチェック前に一旦値を保存するんだよね?
内部に問い合わせないとチェックする内容がわからんから
偉そうなこと言ってるけどできたもんはゴミじゃん
保存ってどこから出てきたんだ？
このスレよく読んでからレスしてね
どうりで話が通じんわけだ
画面直すのかデザイナさんにもできる、
ロジック直すのが画面に一切影響しない事を謳ってプログラマだけで出来る。
これ大規模だと結構大きいよ。デザイナさんに動いてもらうのそこそこかかるし。
>>186
一旦保存って何かわからん。VMの変数に持つよね、って事？
VMの変数に持とうがなんだろうが、入力値と使用値と出力値が同じ所(例えばテキストボックス)に表示されるのは、そもそもが事故の元だよ。
はぁ?
なんのこと喋ってるの?
ちゃんと理解してからレスしてね
>>177
で発端にすらなってるから、理解はしてるが。
アホなのかな。
やはり関数型にすべきでないのか？
モナドを許すか許さないか論、原始再帰関数の定義の喧嘩になるのがオチ。
手続きとしてCPUが処理している所に別のパラダイム持ち込むとこうなるし、
関数としてGPUが処理している所に手続きを持ち込むと同じように異論は出てくる。
何が何でもオブジェクト指向！ってのは手段が目的になっちゃってるように感じる
保守は他人がやるからラピッドでええやんってクズばかりだから業界全体が停滞してるんだよ
多少工数が増えてもエレガントなOOPで作るべきだ
というかそもそも工数ベースで見てもOOPの方が優位だけどな
って、どっから沸いてきた式だよ
コンパイル通らないぞハゲ
ん?でもさぁ
汎用性つけまくった挙句に次の変更が来なかったら汎用化にかけた工数は無駄じゃない?
汎用性と保守性を混同するのは初心者にはありがちだけど全く別のものだぞ
OOPはまず保守性を高めてくれるってのが主だ
結果として見ると汎用性もオマケで付いてくる場合が多いってだけだ
そもそもOOPだと何で保守性上がるの？
SOLIDを実践しやすいから
モデルを忠実にコードに反映できるから
OOPならではの部分を強調してほしかったが
疎結合とモジュール性についてまっさきに触れているので結果的に好感触
>>205
聞いて損した
俺も答えて損した
馬の耳になんとかってヤツだね
反省しろよ
おまえもな
消えろ
ぶっ飛ばされんうちにな
おまえもな
あんまり調子こいてると手続き型にするぞ？
http://echo.2ch.net/test/read.cgi/tech/1467992113/
手続き型でもできる。
というよりオブジェクトみたいに状態に注目するより
メッセージやメソッド、関数に注目するほうが自然な場合もある。
まあオブジェクト脳だとそういった処理をまとめたクラスを作るんだろうけど。
具体例は？
> 手続き型でもできる
それはとても興味深い指摘です。後学のため、
これぞ手続き型の（つまり「そこまでやったらもはやOOP」とは言わせない、そういった小細工のない）
コードで実演してみてもらうことはできますか？
え？ポインタの存在自体が邪道ですか？そうかもしれないですかね‥
それになぜいきなりポインタ？もはや何が言いたいのか判らない
OOPに拒否感を持つ人はその当たり前の感覚を持っていないアスペなんじゃないかな
子供の頃いじめられたりしなかったか？
機械的な命令並べてgotoするより意味的な命令並べてifとかloopとか使ったほうが簡単だな
同じ処理をなんども書くより関数にしたほうが簡単だな
引数が多くて煩わしいから一緒に使う変数をまとめて構造体にしたほうが簡単だな
この構造体は特定の関数以外から変更されたらそれらの実行の前提条件が崩れるからそれら以外からメンバに触れないようにアクセス制御したほうが間違えなくていいな
それらの関数を構造体と同じ箇所で定義すれば管理しやすいな
メンバ変数みたいにドット演算子でそれらの関数にアクセスできれば楽だな
………
こういう感覚は別にOOPを知らなくてもコーディングを簡単に安全にしたいという欲求があれば自然とたどり着くものなんだけど
感覚がおかしいのかガチで気が付かなかったのか
たどり着けないかわいそうな子も世の中には少なからずいるんだね
棍棒だと重いし動物殺しにくいけど木の棒の先っぽに鋭い石括りつけたら軽くてめっちゃ殺せるんだけどウホホwww
正直この程度の発想でしかないんだよ
OOPってそんなに高尚で難しいものじゃない
それをわざわざ難しい概念だと錯覚して悩むのは時間の無駄じゃないか？
OOPとはなにかOOPの存在意義はなんて哲学者みたいなことを考えてないでさ
自分の感覚に従ってOOPってよくわからんけど手続き型より楽だわウホホwwwって気楽にコーディングすればいいんだよ
自分の中で辻褄が合ってないから反論できないのに他人を叩くことでそれを解消しようとするのは間違ってる
お前は技術者を廃業しろ
逆だろうね
物事を自分のおつむの程度にしかとらえられない人間がようやくたどり着いたのが>>227が書てるOOPもどき
この程度の理解の人間がOOPを真に理解してそのメリットを引き出せているとはとうてい思えない
残念ながらこれもOOPがらみでよく見られる光景
追い詰められてならまだしもわりと最初のほうからこれだもんね
さらにそれにしたってそれすらを長文でぐだぐだと…推して知るべし
デストラクタはOOPと同時ですよ
privateは全てprotectedにしろと言われたことあったわ
カプセル化はクソ（めんどくさい）
継承はクソ（親子のねっとりしたつながりがキモイ）
多態は野ぐそ（多態のための汎化、インタフェース抽出とか勘違いも甚だしい。保守性に逆行している）
俺OOP使ってこんな曲芸できます案件多すぎクソ。
車輪的再発明すきそう
もっと体動かすだけとか根性あればなんとかなる仕事に転職しないの？
オブジェクトに操作が内包されているというのは
まるで利権主義で、縦割り行政で、日本的といえる
自分の仕事しかしないし、利権はぜった他人に渡さない
利権という物質的なオブジェクトにすべてが紐づいていて整理されている
まぁ実用面では便利な部分もあるんだが
外でOOPサイコーとかいうと人格を疑われかねない
本音と建て前でこっそり使うものだ
｢ラクして、楽しく、良いもの｣を作れる
スッキリJavaより抜粋
オブジェクト指向登場後のソフトウェア業界は
さぞかし良い世界になったんだろなあ
逆に要求が膨れ上がって結局辛い世になってる気もするが
まあCOBOLとかやらされるよかマシかな
あーわかる
なぜか規約もフレームワークも手続型っぽいんだよな
「オブジェクト指向の利点を明確にする」
だったっけ？
まずメリットが明確にならないとやる意味もわからなくてさ
俺も最近正直そう思うようになった
最初の頃：おぶじぇくとしこう？
途中：OOP！ポリモ！デザパタ本！OOSC本！
その後：関数型？関数と変数だったら変数散らかるんじゃないんけ！
そののち：意外と関数型記述性ある！不思議と短く書けるなんやこれ！
しばらくして：いや？非OOPでも意外と書けた！
OOP-OOPLというより大事なんは単にモジュール性や！直交性や！
徹底してインタフェースと実装のシンプルさを保つことや！
今：そんでOOPのメリットって何なんやろな？
え?
全然意味わかんない
そのうちわかるよ
「そのうち」としか答えない相手から聞き出せることはもう無い
要するに編集方針の違いでしかないんだよ。
出来るやつが書けばどれでもどうとでもなる。
それだけ。
それよりOAOO/DRY/メトリックス(トポロジー)の方が重要。
ボタン1を押したときの処理Aはオブジェクト指向で記述しようがそれ以外で記述しようが
ソースのどこかに記述しなければならない
オブジェクト指向ってのはつまるところその様式美
別にどこだっていいじゃん( ´∀｀)ｂ
まぁだからといって使う側がOOPに従わなきゃならん、ということにはならないな
ボタン1を使いながら「OOPなんて不要！」と言ってるとしたらアホだとは思うが
話の主旨もわからず回答とかおめでてーな
せっかくのオブジェクト指向が台無しになってる感はある。
書いた本人が意図する、しないにかかわらず、相手が不快に思い、
相手が自身の尊厳を傷つけられたと感じるようなクソコードを指します。
糞レベル1. 汚いコードだなぁと思う
糞レベル2. 汚すぎて読むのためらう
糞レベル3. どうしたらこうなっちゃうのか理解不能
糞レベル4. なぜこれを人に見せたのか理解不能
某糞PHPの糞保守案件でガチで撲殺してやりたいコードあったわ
同業他社が保守するなら難解な方がいいだろ
足を引っ張って競争が優位になる
こんなんだから凋落してくんだよジャップランド土人が
毎日残業で安月給じゃそりゃ人格も歪んでくる
その全てをパスしているが動かないコードと
その全てを満たしているが動くコードの
どちらを持っていくかと言われたら迷わず糞を持っていく俺
動くなんて大前提だよ
そんなんだから脳みそまで糞まみれなんだよボケナス
殺すぞ
動いた上でさらに付加する価値だろ?
そんなの省かれるに決まってるだろ
いい加減テメェのこだわりは重要じゃねぇって気付けよ
>>265のセンスのない造語の使用は却下されました
妥当な結果でしょう
これが波動関数ってやつさ
仕様がない＝動作が正＝動いている
つまり何が起こってもおかしくない
パルプンテ状態
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;}
}
どうよ？
C#ならプロパティ使えばよくね
Java脳だから仕方ない
それに対する俺の考えはこう
・あるものが不変で良いなら不変にしておきたい
・不変であるのならメソッドを経由しなくていい
・フィールドをpublicにしておける言語がある理由もそこらへんじゃないのかなっ
どう？
「OOPで～」に対する返事にはなってないかもしれないけど
実装を晒しては行けない
って思う
>>286 >>287
そういうOOPLがあったらいいのにね（あるかどうかは知らない）
それはそれでスッキリすると思うよ
あとクラス図なんかにフィールド含まれてるのすら嫌だもん
>>286的理由で
インタフェースで考えていたいレベルに実装が飛び出てるのが嫌だしダメだと思う
フィールドをpublicに出来ない言語って意味ね
OOの美学みたいな考えがあるんだろうけど
よくよく考えると大した概念ではないし、本質的でもない
多くのOOPはマルチメソッドをサポートしていないので
二つのオブジェクトに跨る処理をどちらに書こうかという
問題にぶち当たるし、得てしてそういった複数のオブジェクトに跨がる処理が
そのプログラムの本質的な部分であったりもするからね
プログラムの簡単な部分に関しては簡単に書ける、それがOOP
(あ、クラスはデータじゃなくて機能って言う人もいるだろうが
データに対する機能を提供している側面があるので・・)
空間に基づいた設計手法といえるが
当然、時間に基づいた考え方というのもあり得て
プログラムの本質が手続きであり、命令を上から順番に実行していくものだとするなら
こちらのほうが本題かもしれなく、少なくとも何がどの順で実行されるか
良くわからないという事態だけは避けなければならない
あまり自律的なオブジェクトを設計してはダメってこと
AがBのメソッドを呼んで、その中で今度はBがAのメソッドを呼び出す・・・
ということは避けなければならない
なぜならAがBのメソッドを呼び出したとき、Aは処理の途中であり
その状態でBがAのメソッドを呼び出すのは危険だから
デッドロックの危険性もある
オブジェクト同士がメッセージをパッシングし合い、まるで生態系のように振る舞い
結果として何らかの機能が提供されるというのは、機能の観点からは遠回りであるし
何がどの順で実行されるかよくわからないという意味で、手続き的には厄介だ
俺たちは何かのシミュレーションがしたいというわけではない
AとBをコミュニケートされるなら、それらの親にあたる部分が仲介すればよく
AとBが直接コミュニケートする必要はない
そうすれば手順が明確になる
オブジェクトとは良きパーツであるべき
private String domain;
String getAccountId() {
return domain + "-" + id.toString() + ;
}
こんな感じで、ゲッタの方が処理挟まないといけんくなったとき、ラクダからちゃう？
でもやっぱaccountId定義してコンストラクタ初期化すれば
やっぱフィールドおっ広げいいかとも思っちゃったり
それはじめると君の同僚たちもそれに倣って、
結果、画面にもSQLにも業務ロジックにも、至る所に文字列操作が書かれるぞ
連結してaccountId作ったり、accountIdを文字数や正規表現でidとdomainにバラしたり…
private Integer id;
private String domain;
String getAccountId() {
return domain + "-" + id.toString() + ;
}
}
ならええやろ
user.getAccountId()や
至る所で
String aid = user.getDomain() + "-" + user.getId();
こんなんされるよりまし
AccountId値型を作ろう
それしようとすると、やりたいことをやるために必要な情報がなかったりして
親の親から引数を渡し直さないとけなくなったりしてそうこうしてるうちに
結局グローバル変数やシングルトン(instance)で便利になったと喜んでしまう性。
現時点でCallerには「domain-id」の文字列以外必要ないなら、それでOK
Callerもid or domainが単独で必要ならgetIdやgetDomainもつける
IDだけじゃなくて、たとえばなんかのログインフォームのようにメールアドレスもサポートするならクラス側で承ける
文字列返すかAcccontDataクラスでも作るかは
idの形式があと3つ4つあるか（ついったと顔ブックとなんちゃらinアカでもログインOKみたいな、ならクラス）
or メルアドのみで数年やれるか（なら文字列でサクっと実装しちまえよ）による
という山岡さんの名言がある
俺は変数にも旅はさせてはいけないと思う
つまり、変数はprivateにのみしておいて
それを外に参照させたり渡したりしないうちは安泰だということ
語りたい事があるなら自分自身の言葉で語れ
シングルトンもやめました
結果、
オブジェクトをたらい回しにしまくりんぐ地獄
郵便物自体はたらい回しするなよ。
メッセージをパッシングしているのはメッセンジャーさ。
言葉に気をつけろよ
キャットドア問題の前にお前らはボロ雑巾のように敗れ去っているのだから
負けは認めるんだな
どんな勝負だったの？
ググってもAmazonしか出てこない、、、
で出るな
まじか！
ありがとう、見てみるよ
http://itest.2ch.net/test/read.cgi/tech/1491118238/
博識な俺様でも知らんぞ
放置推奨
騒ぎ立ててるヤツが居るだけなのね
なんかおもしろい議論があるのかと思って期待してたのにな
オブジェクト指向 "キャットドア問題"
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
結局、キャットドア問題解決できなかったしね
human begining become
and we will we will goto heaven
どんな勝負だったの？
勝利条件やルールは何だったの？
ひどい英語に見えるけどなんか意味あるのかな…
逃げるのか？
や、だから俺はそもそも勝負に参加してないっての
参加するにしても勝利条件とルールを聞いても誰も教えてくれないから参戦もできない
マヌケなヤローだ
これは会話させてくれないやつだ
放置推奨と言われた意味がやっとわかった
いいや、本スレに行って参戦宣言でもすれば即座に着火するよ
みんな内心納得してないからね
現実世界の物理的な制約、言語学や分類学の観点から「～であるべき」と主張しあうおバカな問題だよ＞キャットドア問題
たまに出現してスレを白けさせる美少女クラス云々と同類。
プログラミングを知らなくても身近なものを抽象化して語ることは誰でもできるから、無駄にレスが稼げる
おバカな問題だということが分からないやつがたくさんいるから
似非開発者をフィルタリングするのに便利だよ
自分の考えることが正解で他はダメみたいな考えしてるやつらの口論に出口はない
俺はこんなコード書きたくないなあ
お前が書かなくても>>323が書いてお前に保守させるから問題ない
> お前に保守させるから
無理だろｗ
どうやって、やらせるんだよ。
お前に、他人に何かをやらせる力なんてないだろｗ
わかるわかる
美少女クラスがどうとかウンコがどうとか
そーいうので必死でレス稼いでる子がいるよな
自転車置き場議論の一端だよな
これならレスできる！って連中が集っちゃう
整理整頓術、としか言いようがない罠
とりわけコードに対して、オブジェクト(クラス)にぶら下げとけば良いんじゃね？っていう
多態だ継承だっつっても、コードをオブジェクト単位で整理したときに
ちゃんと動くようにするための仕組みでしかないよ
それなのに犬は哺乳類で猫はニャーとか、最近はこういうこと言う人居なくなったけど
かつて本当にバカげたことを言っていたよね
仕事をするうえで整理整頓は重要だけど、作業性の問題であってサイエンスでは無いしな
いやね、まじめな話、作業性さえよければ何だってかまわないでしょ、マジで
だから結局、作業性の問題なんだよ、これは
クラス階層というもんのドキュメント性も何か
心惹いてたんだろうねえ
継承がもたらすポリモの便利さにくわえてね
作業性が良いと、仕事が早く終わるし、ミスも減るんだよ
そのために整理する仕事があるんだよ
どこの工場でもやっていることだ
工場に限らず仕事は全てそうではあるがな
逆に物凄く崇高な理論や思想が何かあったとしても
余計に時間がかかってミスも増えるんなら糞くらえだろ
家に帰れなくだけ
どれだけの時間で処理が完了するか見積もったり
メモリ使用量を算出したり
そういう楽しいのはあるけども
OOはそういうのじゃ無いよね
OO設計は完全に整理整頓術以外の何物でもない
とりわけ、コードを、どこに、書くか、という問題
普通にメンテナンス性、可読性、
複雑なものをシンプルにする技術とか
言えばよくね？
まとめて整理整頓術としか言いようがない
作業のしやすさ＝作業性？
それとも作業効率を高める性質＝作業性？
自分の周りじゃあまり使われない言葉だけど便利そうだな
これも自分の周りじゃ使われない言葉だな
ここで、ごく一部の例外とか、そういうのはどうでもよい
基本的な原則といって良いだろう
だから両方の意味でつかわれるし、両方同時に言ってるし
付け加えれば品質の意味も含まれる
作業しやすいほうが品質が上がるのは当たり前だからな
ただ、作業性の意味が分からないってのはちょっとアレじゃねって
俺は思うが
別に工場用語でも何でもないし
それからソフトウェア業界であまり使われないのはそうだろう
俺があえてこの瞬間そう言ってる、言い直しているってこと
OO設計は結局整理整頓術ってのは俺の意見であって
Wikipediaに書いてあるようなことを書き込んでも面白くないだろ
要はバカっぽく言い直しているってこと
作業性が良ければ早く終わる、は幻想。
早い、安い、旨いは3つを取れないもんなんだよ。早くてうまけりゃ安くは無いし、早くて安けりゃ旨くはない。
効率を上げるには工程に工夫がいるし、工程を楽にしたけりゃ単純性が居るし、単純性を上げるには効率をさげにゃならん。
お前が馬鹿なのか勘違いしてるのか、恣意的に混同してるのかわからんが、少なくともお前が言ってることが机上の崇高な理論で思想だよ。
もうちょっと整理整頓して文章書こうな（藁干草）
高くはない、まずくはない、遅くもないものはなんとかなる。
その状態が、生産ラインの安定地点でもある。
そんな細かな話は一切してない
彼方を立てれば此方が立たないって領域の話は、個々に対応する話であって
それ言い出すと、美女のウンコの話になる
つまり、対象とする要件がわからないのに、美女クラス作るのは無理
不毛だろ
ただ明らかに作業性の悪い状態で作業すると作業効率が落ちるのは確か
そのことしか言えない
しかし、OOが整理整頓術と考えれば、美女のウンコであるとか
キャットドア問題とかいう意味不明なやつとか、心底どうでもよくなる
それが狙い
整理整頓術は作業性を高めるためにあるとして
異なる整理整頓術があるのは重視してる目的が異なるからじゃないのか？
設計とも言う
どんなにこねくり回しても直接的には１円にもならないんだよね
違うと認めないやつもいそうだけど
そろそろ自分が扱ってるモノの本質を見定めるべき
メンテ不能なモンスターができあがり
ビジネスチャンスを逃す
お前のその考えじゃ一円も生み出せないわな
需要さえ見出せばいくらでもお金になるよ
小手先の技術より経済の本質を見定めればいいと思う
個々に対応しない全体論なんてあるわけねえじゃん。
頭おかしいのか？
次世代言語の前スレで単なるオブジェクト指向では無理でしょ的にGoで断片書いた。
書いたじゃなくてその話をここでもう一度やれって言ってんだよ
何でもう一度？一回やったのに生産性無い事をしたがる/させるんだなぁ。
もう一回話したいテーマ挙げてよ。
少なくともキャットドア問題とやらは問題自体に不備があるから、何の解もありえないだろ。
正しく問題を出し直すなら出し直せば？
オレは>>323に書いた
これだと駄目な理由を早よ書け
323のプログラムは何の役に立つの？
キャットドア問題が解けること
分脈はおろかコードすら読めない奴がレスしてんじゃねーよ
分脈！！
何の役に立つかも考えずにCatやHumanをコードに登場させてるから駄目なんだよ
それが分からないうちあのスレにいた人たちと同レベル
オブジェクト指向わかったつもり系
さながらキミは文脈わかったつもり系か
意味不明なラムダ式の多様。
意味不明なabstract縛り
邪魔なprivate宣言
csvの共通クラスだけで10以上のクラス
悪夢を見てるようだ。
これがオブジェクト指向というやつか。恐ろしい。
全部staticのほうが逆に使いやすいなんてのは、もう目も当てられない。
中途半端にスキルあるヤツに多いんだよなあ。
その中途半端なスキルの奴は、もう次の段階に行ってるよ。
そうやって設計手法に振り回されながらも実践し、失敗を繰り返すことで成長していくんだから。
で、お前はそいつの成長過程で産み落とされたゴミをメンテする役ね。成長はないけどまぁ食っていけてるならいいんじゃない。
設計ミスるのも程々にしとき。
お前は設計ミスなんてしないもんな
なぜなら設計したことがないからw
構造体知ってれば自ずと解りそうだけど
多くの人にはドメインのモデリングが難しいから
手続きを箇条書きする方が簡単だから
構造体がわかることと構造体を組み合わせて大きなシステムを構築できることは別物だから
ただ、今までそれなりに書いてきてて
要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
あと、オブジェクトに着目するって発想がアホっぽくて嫌だとかかな
若い人は何も考えないからそのまま受け入れるかもしれないが
それなりの経験を積んできた大人からしたら
こういったアホっぽい発想に拒否反応が出ても仕方がないんじゃないかな
自分自身にしか影響がないような処理はOOではカプセル化するが
そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
だからOOは元から簡単なことをより簡単にする為のものともいえる
簡単なことがより簡単になるから、難しいことに集中できるってアイデア
もともとgoto文を使わずにfor文を使いましょうってのも
簡単なことを簡単に書くための物だから方向性はあってる
ていうか、プログラミング言語の進化自体が、簡単なことや頻繁に出てくる処理を
構文でサポートして、難しいことは自分で考えてね、って歴史だから
OOも例に漏れずって感じ
あとは、手続き型言語である場合は処理の順番も重要かと
処理の順番を間違えるとあっという間にバグる
継承による差分プログラミングが上手くいかないのも処理に順番があるから
継承元のクラスの処理のされかたについて正しく理解してないと差分だけ書いたって上手く行かない
協調動作させなければならないが、それには処理の順番が重要になってくる
それと、OOになってから処理の順番は、むしろ分かりにくくなってる節がある
クラス単位で処理が細切れになっていたり、仮想関数で目に見えない分岐をしたり
そーゆーのを嫌うってのはあり得る話
処理順が明確なプログラムのほうが読みやすいってのは普通に有る
↑のようなことを理解したうえでOOを使うのは全然よいんだろうが
適当に作られたOOのプログラム、特にOOを使うこと自体が目的であるかのような奴はマジで糞だから
そういう麻疹みたいなのに自分が巻き込まれないように、自衛のためにOOを避けたり
使わせなかったりってのはあるだろう（Linusとかね）
は根性駆動
構造化プログラムで思考停止してるのばかりな気がするけど
たいてい制御系上がりの上司
構造化もDOAも本当は理解してないから無理
制御構造、サブルーチン、ブロック
こんな大事なもんほかにあるか？
面白いのは>>403のように、動き、動詞、メカニズムに拘る人もいれば
>>404のように、名詞、物体、に拘る人も居るってことだな
意見について反対は無いが、俺の例で言うと、
> 要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
ただ単に必要を感じなかったから、だね。
とはいえ、適切に使えば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か？あれは何がいいんだ？
知ってたら教えてくれ。
オブジェクト指向は構造化プログラムを別に否定してないよね
オブジェクト指向は構造化プログラムを否定している
とは言ってなくね？
実直に実装すると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を投げるようになるだけで本質的な解決策にならない
キャンセル、保留中、決定済み
これらそのものをオブジェクト化して置き換えて運用するんじゃないんけ
その場合もorderからorder_stateに移譲するだけだから結局、例外出すだけのメソッドにならない？
値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
値は値なんだし。
値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
しかも、何かさせられない状態すら持ってる。これヤバい。
何かさせられない、の定義が変わったとき過去データの扱いとかどうなるのか、すごい慎重にクラス作らないといけなかったり色々辛いと思う。
Orderクラスはオーダの状態だけを管理して、
OrderManagerみたいなクラスと関数で、
Order OrderManager.Cancel(Order order)なり、
Order OrderManager.Decide(Order order)みたいな物で触った方がいいんじゃないの？
そしたら、各メソッドでの引数の条件のチェックも楽だし、何よりテストが楽じゃん。
う～ん
オブジェクト指向でやるか関数型でやるかは人それぞれだと思うので深入りしないでおく
ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
CanceledOrder implements IOrder
DecidedOrder implements IOrder
CanceledOrder cancel(DecidedOrder o) {}
これでどや
cancelメソに変なo渡そうとしても、コンパエラーで弾けるンゴ
関数型に見えるけど全然関数型じゃないよ。
オーダーってなんぞとモデル化した時に、
伝票と伝票処理する経理の人を浮かべただけ。
呼んではいけない処理を、「呼んではいけない」と決める事について、呼ばれる方が自分で宣言するってどーなの？
経理部の上長だけは注文済みから直接保留に戻せるとか、新しいロジックはいくらでも来そうな要件なんだし、その判断は操作する側が見てやる必要あると思う。
a+bしたら、勝手にa+=bされてるような気持ちわるさ。a.plus(b)は、aではないa+bした新しいインスタンス返してほしいってような感じで。
その上でa.div(0)が例外を吐くか、それともエラーな型返すかは別だけど、少なくともaが破壊される事はやめてほしい。
invalid argument exceptionで例外として扱うから辛い。
サブタイプでエラーなOrderのクラスにするか、
最初からにsanityみたいなプロパティのフラグ持たしといて変な事したら倒しゃ良いじゃん。
メソッドを呼ぶ側がオブジェクトの状態を気にするのは変だし
うん。もしくは、モデル化に失敗してる。
正確には、メソッドは呼んでもいいし、そこで例外を出しても良いけど、だいたいそういうのはトランザクションチェックとかになると思う。
掴んでるOrderが最新でなければどの行為も全てできない事、とか。
履歴が必要な類のシステムはそんな感じかと。
「注文」だと、Decideはほとんど客がやるが、Cancelは客も店もやる。
「注文書」の「「発行」「取下」「受領」「可決」「否決」「発送番号交付」」くらいに分けとけば
「発行」「取下」は「客」が出来て、
「取下」「受領」「可決」「否決」は「事務方」が出来て、
「発送番号交付」は「現場方」ができる
みたいにモデル化しやすい。
全部Operatorがやるべき事で、できるできないは注文書の状態や自分の職位の組み合わせで決まる事かと。
受領済みでなければ取下できるが、受領済みであれば取下できないとか、
取下済みであれば受領できないとか、そんなの例外で捌くもんじゃなくて、ロジックで捌くもんじゃん。
> 状態によって実行できるメソッドが異なる
面白いので、もうちょっと要件を確認させてください
ここで「実行できる」というのはコンパイルが通る、という意味？
それとも型チェックはせずにただ実行時にそういう振る舞いをするオブジェクトがありさえすればよいの？
もし後者の場合、呼んではいけない処理を「呼べない」というのは具体的にはどういう仕組みを想定している？
「not supported exceptionを投げるようになるだけで本質的な解決策にならない」というからには
実行時に例外をあげるのでは不十分ということなんだよね？
サービスレイヤーで認可を済ませた後
オブジェクトの内部状態によって呼べる呼べないを判断する
orderedのorderをdecideすることはできないしpendingのorderをcancelできないという事実に権限は関係ない
orderedのorderをcancelできるのは誰だといった問題は別のところで行う
orderは短い例であって実際の業務ではorderではないし状態数はもっと多い(5～10程度)
それぞれの状態で実行できないメソッドが1つ以上ある
Stateパターンを使えばクラス内部の定型文は排除できる
しかしその場合でもクラスの利用者が、状態を確認してメソッドを呼ぶ、という定型文を書くことを避けられない
このやり方は殆ど能力照会と同じという点で気に入らない
せっかく静的な言語を使っているのだから動的言語のようなことはできるだけ避けたい
よろしく！って軽い気持ちでブン投げたいわ
だから、それぞれの状態で呼べる呼べないを判断するのは権限によるチェックと同じレベルの、ロジックであって、例外ではないじゃんって。
認可の話じゃないなら、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(){}
}
Decidedで、かつ、何らかの理由でCancelに失敗した時、cancelがCancelledOrder帰してると詰む。
それはどう考えてもthrows イレーガル何とかやろ
全部のOrderにisCancelSucseeded()やisValid()生やすおつもりか？
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かと。
どう考えても、のケースはクラスのユーザが判断するべきものじゃないんだから。
> とりあえず認可の話ではない
>>421
> 「発行」「取下」は「客」が出来て、
> 「取下」「受領」「可決」「否決」は「事務方」が出来て、
> 「発送番号交付」は「現場方」ができる
これ、認可の話だよね
> オブジェクトの内部状態によって呼べる呼べないを判断する
ここで「判断」するのは誰（いつ）？
コンパイラ（コンパイル時）？ ランタイムシステム（実行時）？ オブジェクト自身（コール後）？
認可の話だよ。認可と「呼べる呼べない」は、本質的には同じだと言うとる。
「呼ばせられる、呼ばせられない」なんだから。
だから、データになるオブジェクト側が制御するのは悪手。相手方を意識しないと判断できないものを、相手方を持たないものが持つべきではない。
あくまで自分の状態が自分の範囲で正しいか正しくないかを判断する事しか出来ん。
そうしとかないと、密結合すぎて改修不能になるぞ。
なんせ呼ぶ側の改修全てに対応する羽目になるし、改修したらそいつを呼ぶ側全ての動作確認と、場合によっては更なる改修が必要で、そうなったらまた呼ばれる方の改修をして、と
そこそこ悲惨な事になる。下請けを札束で殴るような改修になるぞ。
要は、データはデータらしくしてろ、と。
伝票がペンを跳ね返すような真似すんな、書けていい。
単に正しい人間が正しく書いてない伝票が無効になるだけだ。書く書かない、書ける書けないは人間の問題だ。
って言ってる。
「注文が発送済みになったらもうキャンセルできない」は誰が判断すべきだということですか？
・注文自身
・キャンセルしようとした人
・その他
お前ほんと筋が悪いなぁ
「99レベルだとレベルアップ出来ない」を認可の話と認識してしまうのと同じようなものだよ
認可ってのは「申請者本人とスーパーユーザーは申請済みの注文書をキャンセルできる」とか「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」とかそういうこと
その他。
注文に対する処理を行うロジック。
>>441
レベル99だとレベルアップ出来ない、は話が散らかってる。
レベル100になるために必要な経験値が定義されていない、が正解。
そうじゃなくて、「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」と同じく「自分の権限が及ばない物は変更ができない」でしかない。
もうめちゃくちゃだな
そのうち100円と20グラムを足し算できないのも権限の問題とか言い出しそうだ
それは逆に聞くが、各ステータスのOrderは100円と20グラムくらい違う単位系のアイテムなの？
足せないなら、それはデータ同士の問題でオペレーターの問題じゃない。
>>421で言ってるようにトランザクションの問題として扱ってもいいし、
円が入るフィールドにグラムが入ってるかグラムが入るフィールドに円が入ってるかわからんが、とにかく腐ったな伝票としてそれ以上動かんようにロックするしかないだろ。
一回腐ったものを、腐ったもの側からリカバリするのは無謀そのもの。
一貫性がないんじゃないの？
>>437
> 書く書かない、書ける書けないは人間の問題だ。
>>443
> 注文に対する処理を行うロジック。
人間の問題、の「人間」はそれぞれの操作をするオブジェクトのメタファだと理解してる？
だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
各「操作するオブジェクト」全部に同じ処理書く訳であるまいし。
>>447
間違い。
オブジェクト自身が「操作できる」「出来ない」を決められるのはオブジェクト自身が一人で判断できる事に落とし込むべき。
古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃないでしょ。
> 古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃない
M にロジック入れずにどこに入れるのさ
http://aokilab.kyoto-su.ac.jp/documents/MVC/page3.html
ビジネスロジックはMに入れるけど。
> だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
「注文書自体の状態を変える」主体が誰/何かを聞いているのではなくて、できるかできないかの判断は誰/何がすべきですかという質問です
で、OrderMode, OrderController, OrderViewがあったとしたら、OrderControllerであるというのがあなたの答えであるということですか？
> >>447
> 間違い。
> オブジェクト自身が「操作できる」「出来ない」を決められるのはオブジェクト自身が一人で判断できる事に落とし込むべき。
「発送されたらもうキャンセルできない」は、オブジェクト自身が判断できますね（ビジネスロジック）
「発送されたらもうキャンセルできない」と、mode.cancel()を呼べるかどうかは別問題ですよ
確かに。smalltalkとイベントと言われたらモデルが持つべきか。
しかし、決定とキャンセルをモデルが勝手に自分で判断するのはちょっと素直に納得できんな。
>>451
OrderModelとOrderControllerはあるだろうが、
それ自体は見せずに、
OrderOperationControllerかなんか作ると思う。
正常にOrderを失敗したりし辛いじゃん。
注文という行為は正常に行われたけど、在庫が無くて注文の確定は行われなかった、とか、invalid Operationでもinvalid Stateでも無いと思うが。
例を変えてタスククラスで考えよう
タスククラスの状態は
TODO 作業予定
DOING 作業中
DONE 終了
可能な状態遷移はこれだけ
TODO -> DOING -> DONE
DONEから手戻りでDOINGに戻るかもしれない
とかそういうツッコミはなし
このドメインではとにかく上記の遷移しか許されない
そしてこのシステムはシングルユーザーを想定していて権限の問題は考慮しない
TODOの時のみBeginTaskを実行可能
DOINGの時のみEndTaskを実行可能
どう設計する？
DoingTask型
DoneTask型
を定義しろ
func(task : TodoTask)
にDoneTaskを渡そうとしたらコンパイルエラーで弾ける
これがオブジェクト指向だ
TODO以外の時にBeginTaskを実行するコードはコンパイルエラー？
コンパイルは通るけどコールする前に実行時エラー？
コンパイルもコールもできるけどオブジェクトが実行時エラー？（あるいは黙殺？）
結局そのタスク同士を変換(処理)する奴は、別のアクターでしょ
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に分離した方が型安全で書きやすいかもしれん
気持ち悪いシンタックスだな
何言語？
てゆーかガイジ？
Javaしか知らない人には気持ち悪く見えるのかな？？
ガイジｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
GaijiLangか？
>>452
> 注文という行為は正常に行われたけど、在庫が無くて注文の確定は行われなかった
とか書かれると、こいつ何言ってんだ感が増す
メソッド名頭大文字ってどうなの
それがC#流なの？
巣に帰りましょうね
だから何？
バイバイ
たまにでいいから知識をアップグレードしたほうがいいぞ
日本のケツ舐めて忠誠を誓ってるから日本語使ってるんだね！
すごいね！！
変な言い方になったのは認めるわ…。
注文のトランザクションと、注文行為のトランザクションは別では、と言う感じ。
そこを疎にしておくと負荷上がってきたときに分割しやすいし、データの不整合起こしにくいし、不整合起きちゃった時に原因探しやすい。
注文行為自体はいくらでも上げれるけど、確定していくのはジョブが全部対応するとか。
物のオーダーじゃないけどオーダリングシステムでそういうの作ったときは、すべてのオペレーションはすべてジョブコントローラーへのキューイングで、結果はジョブコントローラーに全部に作らせてた。
なになに
シーシャーパーのポジトーーーーーク始まっちゃう？
何が間違ってるか具体的に言ってみろよ
言えるもんならなｗ
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ？
ブーメラン自分の頭に突き刺して楽しいか？
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ？
コーダーって一般常識がないからこういう些細なとこで詰んじゃうよね
判断力が必要な仕事を任せられないタイプ
違うよ。
受注に対するのは発注でしょ。
発注も受注もキューイングする処理として作って、その可否はジョブが判断する。
名詞の方の注文は、独立して存在してて、それはジョブが淡々とキューされた処理に従って処理してったり、トランザクションエラーならそうマークしていく。
どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。
君がコマンドのキューイングが好きなのは伝わったけどそれ今は全く関係ないよ
そしてそもそもお題は認可の話じゃない
ドメインモデルに定義された不変条件の話をしているんだよ
不変条件を担保するのはドメインモデルの仕事であって認可システムじゃない
誰が何をできるかを管理するのが認可システムの仕事だ
君が大好きなジョブ(トランザクションスクリプト)の場合に当てはめても根本的なところは同じね
データの不変条件を担保するのはジョブの仕事
この場合でも誰が何をできるかは認可システムの領分だ
君の間違いは不変条件と認可という全く異なる次元の話をごちゃ混ぜにして一箇所で管理しようとしたことだよ
ゲストユーザーも一般ユーザーも特権ユーザーも存在しない
誰であっても全てのサービスを実行することができる
ならばこのシステムは全てのデータを自由に書き換えられるのか？
そうではないだろう
認可処理が全くないからと言ってなんの統制もなくデータを書き換えればすぐにデータは矛盾して壊れてしまうはずだ
認可とは別次元で「こういう場合にはこういう処理はできない」といった条件が存在しなければシステムが崩壊してしまう
この条件のことを我々の業界では不変条件などと呼んでいる
不変条件と認可は全く関係なく分離して扱える２つの世界だ
これを一緒くたにジョブなどと曖昧な名前をつけて管理してはいけない
不変条件は不変条件、認可は認可
これらは分けて管理しないとすぐに混乱してしまう
うーん、認可って言葉に随分気持ちが持ってかれてるように見えるけど、
その不変条件自体が、システムの整合性を保つために設計者によって行われた「認可」そのものではないの？
ACLではない、と言いたいんだろうけど、俺の言ってるのもACLそのものじゃない。
>>485
認可条件が全くないなら、システムは崩壊する、
システムが崩壊しないならば、認可条件は全くなくは無い、
と対偶取っても大丈夫なように、
不変条件自体が、システムから与えられた認可なんよ。
しかも、不変条件は変更できない、という不変条件でいとも簡単に実装できる。
ジョブとかタスクがあるようなシステムでシステム作った事無いのかな？
ジョブはジョブで、巨大で膨大なキューが積まれるようなシステムでもない限り2つも3つも立てない、むしろ立てたらロック周り辛くなるからやりたくない、いわゆるジョブなんだけど。
ジョブは、一つのキューに対して、一つのアトミックな操作をする。その入力がオーダーとオペレーションの組み合わせで、そのオーダーとオペレーションによって、処理を行う、行わない、エラーにする、と処理をして、新しい状態のオーダーを記録する。
ただそれだけ。
シングルユーザでも同じ設計でやっとったがなぁ。
ってか書きながら思ったけど、今JSの世界で流行ってるReactのデータ周りそっくりだな。
認可ではない
もしかして言葉が悪いのかな
「できる/できない」と表現すべきではなかったか
認可は「して良い/してはいけない」だな
して良い/していけないとは全く別の次元で、そもそもその処理そのものが成立するかしないかという判定があるだろう
それがモデルの不変条件だ
100円に20グラムを足すような処理は権限に関わらず成立しない
発注していない注文をキャンセルする処理は権限に関わらず成立しない
認可がなくてもシステムは成立する
全員が全ての機能を使用できるだけ
実際そういうシステムはいくらでもあるし作れるよ
認可がないとシステムが崩壊すると君が認識する理由はね
君の作るシステムは認可と不変条件がごちゃ混ぜになっているからだよ
処理が成立しない事を、行っても良い、のであれば「認可ではない」と認めざるを得ないが、
「処理が成立しないからその処理を行うことは無い」のであれば、
処理を行うことがない理由は、「処理が成立しないから行ってはいけない」だけの話じゃん。
事実としては、100円に20グラムをどうしても足したいなら、そのロジック作るしかないんだから、もはやその置き場所が無いモデル化は余計に間違ってるとしか言い様が無いわ。
2ダース足して1個引くとか、単位系読み替え程度ならいくらでもホントにあるしな。
コード××100mgにコード○○を1アンプル足したものとかザラ。
俺のシステムは崩壊しないよw
そっちが「崩壊する」と言うから、対偶を取って見せただけなんだけど。
ごちゃまぜどころか、不変条件なのに変えなければいけない事すらあるんだから。運用では。
だから、不変条件は変更できない、なんて自己言及して定義してあるんだよ。
勝ちたいだけならもうやめとけよ。哀れだから。
わかってるよ
リクエストを受け取るとデータと処理のペアをキューイングする
ジョブがキューをポーリングして実際の処理を行う
っていう古臭いシステムの話でしょ
ぜんっぜん関係ないよね
キュー使おうがイベント使おうがAwait使おうが直列に処理しようが並列に処理しようが今の話題にとってはどうでもいいでしょ
> どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。
「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」をごっちゃにするなって
みんな言ってるのに、まだわからないかな
成立しないから行なっては「いけない」のではなくて
成立しないから行うことが「不可能」な
100円に20グラムを足すことは不可能なので実行しようがないので権限の問題ではない
ダースと個数は可換なので足し算引き算を定義することが「可能」で誰であっても実行「可能」だ
しかしそういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている
コードxx100mgにコードyyを1アンプル足すは「足す」の意味から違うじゃん
化学計算的な意味での足すじゃなく薬液を混ぜるの意味での「足す」
あるいは注文カートにxxとyyを足すといったようなパッケージング処理の「足す」
などそういった意味で「足す」だろう
そう意味での「足す」は実装可能で誰でも実行「可能」だ
そういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている
君のシステムは崩壊目前なので一度誰かにレビューしてもらった方がいい
どの状態＝ログインしているアカウントの状態
と考えれば、同じこと
> その不変条件自体が、システムの整合性を保つために設計者によって行われた「認可」そのものではないの？
違う。例えば構文が正しい場合のみコンパイラはコードをコンパイルするが
これは「コードが正しいと認可した」などとは言わない。
日本語の問題。日本語が間違っている。
それはアカウントと他のものをごちゃ混ぜにした考え方
まずはそれを分離して考えてくれ
アカウントのできるできないと他のもののできるできないは別に考えよう
その上で今はアカウントの話をしてないのでそっちについては忘れよう
ただそれだけなんだけどなんでわからないかなぁ
存在しないメソッド
使用が許可されてないメソッド
バグが有るメソッド
どのメソッドであっても（コンパイルエラーにならない場合は）
実行エラーになるが、その全てが認可エラーではない。
実行した結果、認可エラーになるものはあるが、
それは実行時エラーの特殊な場合
実行時エラーを継承して認可エラーを作るのであって
認可エラーを継承して、その他の実行時エラーを作るわけではない
などと言いだしそうだなこいつ
「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」
この２つを分離するのは間違ってる。
どの状態？という、大きな枠組みとして状態のチェックが有り、
その状態チェックの中の一つとして
・数字チェック
・範囲チェック
・整合性チェック
・権限チェック
などがある。
誰が何をできる/できないというのも、
状態のチェックにすぎない。
状態のチェックじゃないぞ。
まあ無理やり考えれば、あるオブジェクトがあって、
そのオブジェクトが数値だけではなく単位まで状態として持っているのであれば、
オブジェクトとオブジェクトの加算で状態（単位が同じであること）と
みなすことも可能だがねｗ
つまり内容はともかく全部チェック処理だからチェック処理というグループを作ってそこにまとめてぶちこめ
権限のチェックもオーダーの状態のチェックも単位系のチェックも全てチェック処理だからチェック処理のグループでまとめて考えろ
そういうことを言いたいのか？
そういうこと。
カッコつけて「認可」なんて単語を使ってるのが悪い。
単に「状態チェック」と言えば良いんだよ。
状態チェックの中の一項目として認可が存在する。
なのに状態チェックを認可なんて
カッコつけて呼ぶから、みんなから突っ込まれてる。
ドヤ太郎「引数が数字であることを認可する！」
芝を付けるようなおかしな話か？
単位系を付けるパターンは珍しいことではない
特に金を扱うシステムで国際化する場合には量と単位を持ったお金クラスの使用は必須と言ってよい
プリミティブクラスをクラスでラップしろというプラクティスはあまりにも有名だが
それはこういった単位と量の取り扱いをより厳密に実践せよということだぞ
> チェック処理のグループ
チェック処理のグループってなんだよｗ
何かの処理（メソッド）を実行した時、
それが実行可能かどうかチェックするってだけだろ
その内容なんてどうでもいいわｗ
俺が言ってるのは実行可能かチェックすることを
「認可」って名前で呼ぶなって言ってるだけ
お前が言ってるのはドルや円といった変換可能な単位の話だろ
俺が言ってるのは、円やグラムといった変換可能ではない単位の話だ
そっち側から突っ込んでるの1人だけだぞ
みんなって…？
認証・認可はセキュリティに関わる事項
特別扱いするには十分な理由で常識だ
君の発言はシステム開発に関わる人間の発言とは思えない
セキュリティに関わるから
特別扱いするのはなぜでしょうか？
セキュリティに関する部分は
単純な比較命令や条件分岐命令を使うのではなく
専用の機能を使うべきでしょう？
でも、コードからすれば何ら特別扱いは
されていませんよね？
セキュリティ事故を起こすと金もかかるし信用も失う
君も新人研修で習っただろ？
そんなバカバカしい疑問が出るってことは学生さんか？
君のコードからは特別扱いされてないだけ
認証・認可はそのためのモジュールで取り扱うのが一般的です
だからなんなんだよｗ
お前が言ってるのは重要なチェック処理と
重要でないチェック処理があるってだけの話だろ？
俺はどちらもやってることはチェック処理に
すぎないって言ってるだけ
可換不可でも発想は同じ
100円オブジェクトと20グラムオブジェクトを足そうとしたら実行時エラーないしその前にコンパイルエラーだ
> 認証・認可はそのためのモジュールで取り扱うのが一般的です
そのモジュールを使えば、メソッド一つでチェックできるようになるんだろう？
お金100円オブジェクトと金20グラムオブジェクトを足そうとしたら
価値がでるかもしれないぞ？
文字列のパターンマッチ検証と
認証サーバーへの問い合わせ
が君の目には同じ処理に見えるってことか？
世界観が違いすぎて会話が成立しないんだけど
東証の誤発注事件、セキュリティとは関係なかったよなｗ
セキュリティでなければ、お金や信用は失わないと？
その処理にビジネス上のメリットがあるとは思えないが好きにすればいいよ
> 文字列のパターンマッチ検証と
文字列のパターンマッチ検証のバグで
大損害を起こすことも考えられるからな。
重要かどうかは、やってる処理内容ではない。
やっている場所だ。
どちらもチェック処理であることは明白
重要な箇所のチェック処理であるかどうかの違いがあるだけ
> その処理にビジネス上のメリットがあるとは思えないが好きにすればいいよ
それはお前が思いつかないってだけだろう？
例えば中古買取システムだと、衣類はグラム単位で買い取り価格が決まるとか
あるわけだが。
学生さんじゃないな
小学生か
どんな処理でも事故を起こせばペナルティの可能性はある
とはいえ事故の種類によって確率も被害額も異なる
セキュリティ事故は注意していなければ事故を起こしやすく被害額も大きい
つまり対策に投資する価値が大きな分野ってこと
>>519
だからそれは否定してないってｗ
重要でも重要じゃなくても
処理自体はどちらもチェック処理
そういうドメインがあったとしても円とグラムの足し算を定義するメリットはない
混乱するだけだからエラーになるようにしろ
古着の重量から取引価格を問い合わせるサービスを書け
問い合わで得た価格を足し算しろ
その方がずっとわかりやすい
ビジネス上の価値が違うって言ってるの
処理の目的も実装も違う
チェック処理ってまとめ方は大雑把すぎる
飯を食ってくるから戻る前にレス溜めといてくれ
あとでまとめて返す
要件定義書持ってこい。
それはコンパイラがコンパイル時に行うのか
それともコール自体を実行時に許さないのか
はたまたコールは許すけど結局弾くだけなのか
どれを想定するかで設計が変わるんで
出題者はそろそろ答えてくれまいか
「これが俺の言う「認可」。お前が言ってるのはこれだろ？」に、そう呼びたいなら呼べばいいやと思ってその言葉使ってるだけで、
単純に言えば>>416でチェックって言うとる。
>>490
古臭かろうが生きているのは、変な話絶滅すべき理由が無いというそこそこ大切な理由がある。
>>491
ごっちゃにすべき話だよ。「この状態の時に何ができるか」は「誰が」をつけないと意味がない。
もちろん、「誰が」にも「この状態」にもワイルドカードが入ることもあるが。
>>492
その状態では誰でも出来ないよ。薬剤に薬剤部の承認が降りてて、実施者は医師ないし医師から指示を受けた看護師か薬剤師しかできん。
崩壊目前と言われても、もう俺が知ってるだけで12年は動いてるけどな。
サーバ側のモジュールは1989年の見たことあるわ。
>>527
コンパイル時に解決って発想がすごいな。
リリース時には、依存関係を一式リリースしないといかんのでは？と思ってしまう。
全然30代だけど、おじーちゃん扱いか…。
認可処理が体系化されてないシステムってアドホックな認可検証処理があちこちにばら撒かれて他の処理に紛れてしまうものなんだ
それで紛れちゃったから区別がつかなくなってしまったんだろう(少なくともメンテナの彼は区別が付いてない)
昔から世界中で問題視されて来た典型的なアンチパターンってわけ
多くの失敗例を反省して改善してきた答えが認可システムと他のロジックの分離なんだけど
これはその成果を取り入れる前の実験台になった世代のシステムだったということだね
まぁ、なんとでも言えば良いと思うけど、
アドホックな認証認可の検証を一切しないためのキューだよ。
取り入れるも何も、最初からしとる。
お前、全く理解できてないだろ。
オブジェクトとして、ステートフルで、操作の例外を自身がすべて処理するクラスは存在しても良い、と。
まーそれでいいよ。もう伝わんないだろうし。
無駄だわ。
レスからは年齢を感じる
30台ならまだもうちょいいけるから元気だして
他の検証処理と一緒くたにしてるんだろ
そういうのをアドホックっていうんだよ
そしてこのキューは関係ない
君の使ってるキューはジョブスケジューリングのためのものだろ
むしろこれに検証やロジックが結合しているならそれこそおかしな設計だよ
お前がそれをいうなよ
状態をコンパイルで安全に実装する話じゃなかったのか？
ad hocの意味調べてこい
大学生の時からフリーで仕事しとったから、職歴としては長いからな。
議題をまとめて。
あと、ゴールも。
まず「認可」議論が何にこだわってるのか意味不明
100円と20グラムを足せないようにしたいなら
貨幣クラスと重量クラスを作って型チェックすればいい
品物を発送したら注文のキャンセル不可にしたいなら
ステートパターンとかで発送状態にして
キャンセル判定すればいい
ふつうは前者を実行したらエラーや例外にするし
後者はいちいちアプリごと落ちたらうざいので
「発送後はキャンセルできません」とか画面に表示する
んで、それだと何がダメで
じゃあどうしたらいいのか
さっぱり話が見えてこない
不変条件は不変だから
認証系と混同するなよってことかな
それ自体はそうだよ
100円と20グラムを足すような処理は
100パーセントないと断言できるから
コンパイルエラーで100パー弾いても構わない
それに対してキャンセルの話は
発送後も不良品であれば返品できるみたいに
実務では複雑な条件になるし変更もありうる
だからその判定が複雑なら
キャンセルクラスを作って判定するかな
それよりもっと高度な何かを求めてるなら
説明してもらわないと分からない
その認識であってるよ
そこに「認証認可系とごちゃ混ぜにして処理しろ。分けて考えるな。キューイング！キューイング！」ってちょっと変な奴が絡んできたから「分けて考えるのが正解だし、そもそもそれ今関係ないだろ」って応酬を延々と続けていただけ
連休の2ちゃんではそういうことがままある
ママゴト聞いてるみたいだもん。
小学生か？ガイジか？
> だからその判定が複雑なら
> キャンセルクラスを作って判定するかな
複雑じゃない場合はどこに実装するんだ？
> 発送後も不良品であれば返品できるみたいに
> 実務では複雑な条件になるし変更もありうる
それ返品の話ですよね？
キャンセルじゃないですよね？
暇そうで羨ましいよ
>>416
> 値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
> 値は値なんだし。
> 値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
> しかも、何かさせられない状態すら持ってる。これヤバい。
で、対する一派は、オブジェクトは振る舞いを持っているしルールも持っているという認識
話は噛み合わないよ
こんなに盛り上がるとはな。
まー、いにしえのナントカ、みたいなのは良くも悪くも「ちゃんと動く」から、いにしえのナントカとして未だに生きてるんだから、
無碍に否定してもきりがない。
ジョブシステムの致命的な欠点の「ジョブサーバが死んだら何も動かない」を突かれたら
「死なんように単機能なんだ。だから、どんな処理も「処理完了,処理結果:不正」という正常系でさばく必要がある」
としか言えないところだったのに、そこはスルーなのがわからん。
オブジェクトの定義は、「単なるデータスキーマ」であるか「単なるタスクの実装」であって、それ混ぜると収拾つかなくなるよ、なので、
単にオブジェクト指向を否定してるわけではない事だけ伝わってほしい。
その線を踏み越えたらすべきじゃないと思うから、否定してるのかな。どうなんだろう。
状態に対応したテーブル用意して、キューで逐次処理する方がよくね。
そうすると、RDBとツリー階層で互換性もたせられて、色々対応づけるのに楽な場面があると思うんだよね。
発送前フォルダ、発送後フォルダとか。
キャンセルは発送前までの処理でしか受付ないし、返品は発送後２週間まで受け付けます。とか。
なんか商品に不具合あって返品したいなら、まずメールでやり取りすると思うし、その後の判断はメーカー側で行って、返品操作はメーカー側でやるでしょ。
で、返品の判断なんて難しいからシステムに組み込まないで、返品対応マニュアルをエンドユーザさんで用意してもらえば終わりでしょ。
> オブジェクトの定義は、「単なるデータスキーマ」であるか「単なるタスクの実装」であって、それ混ぜると収拾つかなくなるよ、なので、
> 単にオブジェクト指向を否定してるわけではない事だけ伝わってほしい。
（少なくとも俺は）そのオブジェクトには「ルール」が欠けていると思う
「発注されたらもうキャンセルできない」もルールの一つ
そのルールを、注文というオブジェクトの外側で担保するというのなら、俺に言わせれば、
それなんのためのオブジェクトなのってことになる
C時代の構造体＋手続き型コードと何ら変わりないでしょ
まぁ、俺が言いたいのはそれ以上でも以下でもないのだが
ジョブスが死んだらAppleは何も動かないって
話かと思った
オブジェクト指向は方法であって、目的じゃないよ。
Cの構造体でも、構造体にそんな関数ポインタ持たせたいと思わないし、
ルールってどっちが持ってるものなの？ってのはCで書いたときも同じように、構造体を弄る側に持たせる派と、構造体を使う側が気をつけて使うかでそれなりにモメる所かと。
構造体へのアクセスをすべてラッパで包む→一部の奴らがメンバが読めないじゃないかと言い出すが最終的におちつく
までは多分同じなんだけど、細かいプロジェクトだと
構造体へのアクセスをすべてラッパで包むし、そのラッパ関数があまりにも逸脱した操作はエラーにする
→喧嘩の後「『あまりにも逸脱した操作』を明文化せよ、そして常にメンテナンスせよ、そして業務フローやシステム改修時には無限に対応せよ」
のおふれが出て、言いだしたやつが泣き、保証はすべてそいつがする。
構造体へのアクセスをすべてラッパで包むが、ラッパは薄皮に留める
→喧嘩の後「各サブシステム屋はステートと分岐に対して100%の網羅度で試験せよ。さもなくば本系接続禁止」
のおふれが出て、全体が少しずつ泣くが、保証は各サブシステム屋が担保する
と、だいたいの流れがある。
後者の方は、保証する範囲や、データの整合性に関して、自然と疎になるので、いい意味でも悪い意味でも足切りしやすい。
もうちょっと具体的に言うと、
「注文」への「ある操作」が「無効」ならば例外とする、ってのは、注文が持つべきルールで良いと思う。
ただ、「注文へのある操作」を「無効」にするのは、注文の役目ではない。だから、「発注されたらキャンセルできない」はルールみたいだが、厳密にはルールじゃない。
『「発注」すると、「キャンセルすると言う操作」を無効にする』ってロジックが居て初めて、注文はキャンセルを無効と自分で判断できる、では無いか？
「キャンセルできなくする」は「発注」ロジックの役目で、注文が自発的にやるべき事じゃ無いと思う。
単に、「できる状態ならば、する」だけになる。
やるべき処理が小さくなればなるほど、作りやすいし試験しやすいし、変なデータできた時に追いかけやすいじゃん。
できない状態ではない=できる、では無くて、
「できない状態を定義した時点で、できなかった状態」ではない=できる
に過ぎないから、
「発注されている場合はキャンセルできない」と否定文で動作の可否を定義すると、仕様を拡張する時にどっかで漏れるよ。
手続き型システムの設計 1 [無断転載禁止]©2ch.net･
http://mevius.2ch.net/test/read.cgi/tech/1500282714/
自分の思ってるオブジェクト指向でなければ、よく知らないけど手続き型に違いない、は惨めだからやめといたら？
文書読みづらいんで帰ってください。
惨めな自演はやめた方がいいです
このまとめはその通りだよ
オブジェクト指向なら
データと処理は一体化させるのが基本
>>554
＞それなんのためのオブジェクトなの
おおむね同感
細かく言うとルールが複雑になったら
判定はルールオブジェクトにして
注文オブジェクトから委譲するけど
カプセル化されてるから構造化とは違う
パブリックリポジトリにコードうpして議論しろ
同意者数は意見の根拠として弱いよ
仮に数を根拠とするならその誰がみてもって根拠は？
お前が保証できる視点はお前の視点だけだよ
屁理屈こねてないで現実見ましょうね
そうだね
居もしないその他大勢を屁理屈で作り上げず現実見ましょう
自演てw
そんなことせんでも俺はずーっと同じこと言ってるぞ。
誰かに名乗れと言われたから仕方なく「あ」とつけてるくらい。
オブジェクト指向であれば、手続き型ではない、
これ変だよね。
オブジェクト指向か、コンポーネント指向か、アスペクト指向か、etc,etcのモデル化のパラダイムと、
手続き型、関数型、純関数型、etc,etcの、スタイルや値の扱い方のパラダイムは、どう組み合わせたらどうなんて問題じゃないと思うが。
オブジェクト指向で関数型、もあるし、
オブジェクト指向ではない関数型もあるし、
オブジェクト指向で手続き型もあるし、
オブジェクト指向でメッセージドリブンな関数型も
オブジェクト指向でメッセージドリブンな手続き型もある中で、
なにを突っ込まれてるかわからん。
自分の定義が狭すぎるのでは？
えらいねー。
これでいい？
誰かに褒めてもらいたいようにしか見えない。
ママのおっぱい離れして、小学校卒業するぐらいの文書能力がついたらまたきなよ。
褒めてもいらんし、むしろ間違ってたら指摘してほしいくらい（なので、>>566には割と納得感がある。最初からルールオブジェクト作ってるのと同じじゃん？と言う気持ちもあるが、そこは考え方と言うか俺が構え過ぎなのか、考えあぐねてる）
少なくとも、理解できないなら理解できない事を挙げてほしいが。
「小学校卒業するぐらいの文書能力」自体、無茶苦茶な日本語だと思うが。
文書は能力でないだろ。文書作成能力、もしくは文章力で、
能力に対して「ぐらい」って言うなら、前半は見込みや可能性、確度であるべきなんだから、「小学校卒業できるぐらい」にならなきゃいかんのでは？尤も小学校は日数で卒業できるが。
「ここに張り紙をするな」って張り紙みたいなみっともないのはやめてほしい。
揚げ足取りとか。
問題を解決したい訳でなく、議論ごっこをしたいだけに見えます。
だから、終わりがないし不毛です。
他のスレでも結局放置されてた
> 『「発注」すると、「キャンセルすると言う操作」を無効にする』ってロジックが居て初めて、注文はキャンセルを無効と自分で判断できる、では無いか？
ごめん、書き間違えたよ
正しくは、「発送されたらもうキャンセルできない」
あと、無効にする処理をどこに実装するかの話はしていないよ
ルールの実装をどこにするかの話
class Order {
public bool isCancelable() {}
public void cancel() {}
}
client:
order = new Order();
if (order.isCancelable()) {
order.cancel();
}
というコードの場合、以下の点がよろしくない
・cancelの正しい手続きを呼び出し側が知っておく必要がある
・その手続きに変更があった場合、Order::cancel()を呼び出している箇所全部を修正しなければならない
・誤った呼び出しをしてしまうと、データに不整合が発生する
class Order {
private bool isCancelable() {}
public void cancel() {
}
}
それに対して、オブジェクト自身がルールを持っていれば
class Order {
private bool isCancelable() {}
public void cancel() {
if (!isCancelable()) {
// エラー処理（例えば例外をthrow）
}
// 実際のキャンセル処理
}
}
client:
order = new Order();
try {
order.cancel();
} catch () {
}
クライアントは、
・cancelの正しい手続きを知る必要はなく、単に呼び出すだけ
・その手続きに変更があっても、呼び出し側は変更する必要がない
・誤った呼び出しもない
というメリットがある
なぜなら、cancelの呼び出し権限があるかどうかは、Orderオブジェクト自身は知りようがないから
チェックが可能なので、そう実装してもいい
class Order {
private bool isCancelable() {}
private string orderUserID() {}
public void cancel(string cancelUserID) {
if (!isCancelable()) {
// エラー処理（例えば例外をthrow）
}
if (orderUserID() != cancelUserID) {
// エラー処理（例えば例外をthrow）
}
// 実際のキャンセル処理
}
}
まあ大抵はロールによる権限管理とかのケースが多いだろうから、その場合はOrder自身は権限チェックできない
＞オブジェクト指向であれば、手続き型ではない
変じゃないよ
たしかに構造化に近いレベルでも
オブジェクト指向とされているのが現実だけど
手続きを隠蔽するのが本来のオブジェクト指向
考え方としては筋が良いけど
もっと突き詰めていくと
キャンセル可能かどうかの判断は
キャンセルオブジェクト自身の責務にしたい
つまり
＞if (!isCancelable()) {
はキャンセルオブジェクトの内部にあって
Orderクラスからは知らなくていいようにする
Orderクラスからcancelメソッドを呼ぶと
キャンセルクラスの内部で判定するように
コード書いて
class Order {
Canceler canceler;
void cancel() {
canceler.cancel();
}
}
class Canceler {
boolean isCancelable() {
}
void cancel() {
if (!isCancelable()) {
}
}
}
悪いけど、そのコードのデメリットだけ思いついて、メリットを思いつかない
君のレベルが低い
デメリットってどんな？
ないとは言わないが
メリットの方が上回ってるはず
>>585
データと処理が一体なのがオブジェクト指向
だけどあえて言えばデータが基本
注文されたかどうか
発送されたかどうか
振込されたかどうか
などの状態を持っていて
メソッドでその状態を変えられる
ただしそれらは委譲している場合もある
データと処理が一体化がオブジェクト思考？
馬鹿いうな。
オブジェクト思考は役割を小さくし、
疎結合を保つ試み。
データはデータの構造に着目しろ。
処理は処理クラスに任せろ。
注文データを作ったら、それを確定、キャンセルするのは処理クラスの役割だ馬鹿。
> デメリットってどんな？
「発送されたらもうキャンセルできない」という話の流れで出したコードだけど、それに沿って説明すれば
実際には>>583は
class Order {
Canceler canceler; // この結合も良くない
void cancel() {
calceler.cancel(this);
}
void processCancel() {
// 実際のキャンセル処理はOrderモデルしか知らない
}
}
class Canceler {
boolean isCancelable(Order order) {
// order.getState()でも呼ぶ？
}
void cancel(Order order) {
if (!isCancelable(order) {
order.processCancel();
}
}
}
みたいなヒドイことになるのだが
逆に、メリットってなんだろうか？
order.processCancel();
}
じゃくて、
if (isCancelable(order) {
order.processCancel();
}
だな
order.cancel()
dryの原則に反してるからcancelerクラスのキャンセル処理だけありゃいいだろ！
俺はどっちからキャンセル呼べばいいんだよ！
＞実際のキャンセル処理はOrderモデルしか知らない
違う、逆に実際のキャンセル処理はCancelerしか知らない
Cancelerのcancellなどのメソッドにキャンセル処理を書く
＞メリットってなんだろうか？
>>576
＞・cancelの正しい手続きを呼び出し側が知っておく必要がある
＞・その手続きに変更があった場合、Order::cancel()を呼び出している箇所全部を修正しなければならない
＞・誤った呼び出しをしてしまうと、データに不整合が発生する
>>577
＞・cancelの正しい手続きを知る必要はなく、単に呼び出すだけ
＞・その手続きに変更があっても、呼び出し側は変更する必要がない
＞・誤った呼び出しもない
この関係がそのまま当てはまる
Cancelerを呼び出すOrder側を
クライアントと考えればいい
実務では処理が複雑になるが
Orderだけに権限が集中すると
肥大化していくから委譲する
Orderだけで完結してるけど複雑ならcancel()からルールチェインを生成して移譲
Orderだけで完結してないならcancel()からdependencyにアクセス
クライアントはなにも考えずにorderをキャンセルしたいだけなのだからorder.cancel()以外のAPI(canceler)を知りたくない筈だ
同じ理由でクライアントがorderのデータにアクセスするなどもってのほか
IT Pro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060410/234873/
＞「プログラム（処理）とデータをひとまとめにして」扱えばよい。
オージス総研
https://www.ogis-ri.co.jp/otc/hiroba/technical/concept.html
＞カプセル化とは、データとそれらを操作する手続き群とを
＞ひとまとめにしてパッケージとしたものです。
少しは調べてから物を言えよ……
データと処理の一体化（カプセル化）は
オブジェクト指向の基本だぞ
Orderがクライアントになるというのはつまりこういうこと
class Order {
private Canceler canceler;
public Order(Canceler c) { canceler = c; }
public void cancel() { canceler.cancel(this); }
Orderのクライアントは常にorder.cancel()だけを知っていればおk
cancel()の中でなにをやってるかは問題ではない
委譲を知らんのか
DRYの原則には反しない
Orderにキャンセルの実装は書いてないからな
＞canceler.cancel(order)
こうはしない
＞どっちからキャンセル呼べばいい
今回のケースでは
Orderから呼ぶことを想定してる
>>596
＞クライアントがorderのデータに
＞アクセスするなどもってのほか
＞Orderのクライアントは常に
＞order.cancel()だけを知っていればおk
その通り
使用側は最小限のAPIだけ
知っていればいいのが
オブジェクト指向のメリット
注文は人がウェイターにするの。
だから、注文それ自身は処理を持たない。
データなんだから。
わかる？
ウェイターが注文を受け取って、それを受理するの。
なんか色々勘違いしてるけど。
注文クラスの責務はなに？
答えてみて
>なんか色々勘違いしてるけど。
自己紹介乙
＞それ自身は処理を持たない。
＞データなんだから。
だからオブジェクト指向のオブジェクトは
たんなるデータじゃなくて処理もできるんだよ
＞なんか色々勘違いしてるけど
じゃあそういう解説してるところを
>>595みたいにソースあげてみ？
あげられないでしょ？
オレオレの我流だから
＞注文クラスの責務はなに？
注文（の情報と処理）
ウェイターは客からの問い合わせをシステムに移譲するディスパッチャーです
ここでいうシステムとは端末はもちろんマニュアルなども含みます
彼らは自らが複雑な判断をしているわけではありません
ディスパッチャーというよりはユーザー・インターフェースですね
ウェイターは人型のユーザー・インターフェースです
いずれにせよ彼らは複雑な判断はしません
キャンセルを指示されたら笑顔でかしこまりましたとメッセージを返し、所持する端末にキャンセル指示を移譲します
それだけです
それは、メソッドはステップとして分割不能なものでしか構成されていない、
手続きは一切入っていない、という理解で良いのか？
Cで言えば、文は一つだけ、と。
であれば、なるほど突き詰めるとそうなるか、となるな。
注文がどのように展開されてどんな処理をするか注文クラスは知っているの？
そもそも注文クラスって何？
ある注文(例えば、野菜炒め)に特化したクラスなの？
それとも汎用的な注文伝票を扱うクラスなの？
キャンセル処理は誰が受け取るの？
料理さんがバカヤロー料理できちまったらキャンセルできねーよっつったら、誰が聞いて誰が返事するの？
注文で必要な処理は検証のみ。
注文を受け取ったらタスク(処理)クラスに移譲して、注文idで問い合わせる。
そうすれば、ウェイターは、非同期でタスクを監視し、できた順に成果物を返せるね。
statusは足せる列挙体持ってる言語ならその方が良い。
uint APPLY=1
uint CANCEL=2
uint XXXXX=4
class Order
uint status = 0x0
なんかプロパティ
bool isEnabledFor(proc)
return (this.status & proc)
bool isValid()
//dbと突き合わせるなり
class QueueOrder
Order order
uint Operation
class OrderProcessor
void exec(QueueOrder qo)
if(qo.order.isValid() && qo.order.isEnabledFor(qo.Operation))
//Operarionごとに処理とstatusの更新
return order
else
ログに残すやらなんやら
みたいになるんじゃないの？
OrderProcessorのrerurn 、値返してるの間違いだわ。ごめん。
＞手続きは一切入っていない
もちろん手続きは入ってるよ
たいてい関数型でも入ってる
ただ関数型が参照透過性を重視するように
オブジェクト指向ではカプセル化を重視する
高レイヤーではIF文やFOR文を
追い回さなくてもいいように抽象化する
今の文脈で言えばオブジェクトの使用側は
「Order.cancel()」だけ知っていれば使えるようなこと
＞注文クラスって何？
今の文脈だと汎用的というか
集約的なクラスかな
注文の情報や処理は
注文クラスでできるようにする
ただし具体的な実装は委譲する
Order.cancelでキャンセルできるけど
何日までキャンセル可能みたいな
具体的な条件や実装までは知らない
それはCancelerの責務
ウェイターは自分で料理作るわけじゃないけど
注文は取れるでしょ？ それと同じ
正直、構造化っぽいコードだと思う
べつに構造化で組んじゃいけないわけじゃないけど
少なくともオブジェクト指向らしいコードではない
時間の無駄は極力減らすべき
なら、方法論が手続き型でも、そうでなくてもどっちでも良いんだから、
オブジェクト指向であれば、手続き型ではない、ってのはやっぱ変になるんじゃん。
>>571の通り、オブジェクト指向であるかないかと、中身が手続き型か関数型はまったく違う次元の話かと。
そういう意味で、
>>611で言う「たいてい関数型でも」に対しての「純関数型」まで挙げてんのに、なんで？
カプセル化と、抽象化は似てるけど違うでしょ。
a+bが、ベクトルでも複素型でもできるのはカプセル化ではないけど抽象化でしょ。
Order.cancelだけ知ってれば、って、Cancelが闇鍋になんじゃん。
オブジェクト指向を広く捉えたとして、物をモデル化したものをインスタンスとして扱うものとするならば、
自分からひとりでに意味を持つ注文書なんか存在しないじゃん。
切手だって勝手に有価証券になるわけでも、使用済みになるわけでもないぞ。
郵政省が刷って有効になって、手紙に誰かが貼って使えて、郵便局が消印押して無効になるんだから。
車の販売管理システムで車の物理的構造をモデル化するバカはいない
飲食店の注文管理システムでウェイターをモデル化するバカは…
あ、このスレには1人いたか
どっちでもいいわけじゃなくて
メソッドの中身は手続き型でも
隠蔽されていることが重要なの
カプセル化されているかどうかの違い
「STATUS = 1」みたいなフラグを知らないと
関数やメソッドを利用できないのは構造化的な世界で
オブジェクト指向の世界ではそれは隠蔽する
外部からは最低限のAPIだけで利用できるのがメリット
＞Order.cancelだけ知ってれば、って、
＞Cancelが闇鍋になんじゃん。
隠蔽が闇鍋ってのはそういう面もあるけど
キャンセルの責務がCancelerに限定されてるから
キャンセルでバグがあるならCancelerだけいじればいい
対して構造化的なデータと処理で分けて
フラグのバケツリレーみたいなことだと
影響範囲がどこまであるのか分からなくなる
つまり闇鍋の中身がどこまでも拡散していっちゃう
だからある程度の規模になると相対的に
オブジェクト指向の方が保守しやすい
ウェイターも食券販売機も一緒だろ。
窓口のサービスを起点になって、
手続き的に内部で処理されるわけ。
ウェイターもなしで、いきなり注文して、
勝手に料理作られたら困るから窓口おいとくわけ。
設計したことあるかな？
標準化とか分かるかな？
運用とか考えたことあるかな？
ないんだろーなー。
人の仕事が機械に変わって行ってる現実
つまりモデル化できてるんだよ
オブジェクト指向のオブジェクトは
物理的な物じゃなくて責務なんだよ
飲食店の客から見たら誰が料理してるとか
厨房がどうなってるかとかは知らなくていいが
料理がちゃんと出てこないといけない
通販なら製造や流通の過程は知らなくても
注文したら発送されたり
キャンセルできたりしないといけない
その注文とかキャンセルとかが
責務でありオブジェクトの単位になる
人のレスはよく読んでね
ウェイターをモデル化したのが食券販売機だね。
どう違うか教えて。
うん、そのフラグ知ってるのは、OrderのCancelを呼ぶということを知ってるのに等しいんだけど？
だから、Cancelと言うメソッドは無いし、実質QueueOrderのOperationがそう。
最低限のAPIじゃん。exec。
キャンセルの責務はcancelに持ってるかもしれんが、その修正の影響範囲はcancelを呼ぶもの全部に波及するぞ。
バケツリレーの良いところは、明らかに守備範囲外、が明確で、かつ、その場合の処理方法が「バケツごと捨てる」の一択しかない所。
捨てられたなら、捨てた時点より以前がおかしい。単純明快。
デジャーナルして、もっかいジャーナルから流すのも簡単。
責務は、それぞれの責任範囲で行うこと。
それ自体は否定してない。
>>421でも言ってる。
ビジネスロジックは、データの持ち物じゃない。
逆。ビジネスロジックがステートを持つなら百歩譲って理解できるが、データがロジック持つのは責務で言えば越権行為じゃないの？
そうだね
よく読んでね
(両方できる奴も居るが)伝票に追記したり抹消線引いたりする奴と、料理の配膳や片付けする奴。
伝票があるから、注文を伝えた事が正しかったか証明できて、料理が正しいか、配膳されたか証明できて、そして会計できる。
伝票はひとりでに動いてない。ウエイターが書いてる。
食券の自販機なんかもっとわかりやすいな。金券かつカンバンそのもの。
存在する=金払った証明として有効
もぎれる=使用することができる
料理が出てきて食券渡して、もぎられると、もうもぎれないので、食券としては無効。
ただ、半券として金払った証明としてはまだ有効。
それでいて所持する役、もぎる役がそれぞれ別にいるってことか
レストランの物理的な構造に囚われてウェイターという物をモデル化しようとする人が居るってこと
注文クラスと聞いて紙の注文書を馬鹿正直にモデル化しようとする人も同じタイプだね
レストランシミュレーターウェイターモデルならそれでいいかもしれないが注文管理システムでは不適切だろ
ついでに言うとウェイターをモデル化したものが食券販売機という例は適切じゃない
ウェイターも食券販売機も同じインターフェースの実装でしかないよ
もぎる奴が居るから、存在するし、
使うやつが居るから、存在する。
その数は一対一でもない。媒介物。
もぎりのバイトは、ひたすらチケットもぎるだけで良い。
職務は「もぎれるかどうか判断して、もぎれなければ追い返す」
滅茶苦茶シンプルじゃん。
後工程で、映画の半券持ってたら一軒だけ飲食店で割引なんてのが突然増えても、
飲食店は、半券持ってるか、ハンコ押してないか見て、押して無かったらハンコ押して割り引くだけ。
飲食店の注文管理システムってのがえらく玉虫色してるな。
レストランシミュレーターウエイターシステム以外を指して言ったなら、かなり恣意的な運用な気がする。
あと、リアルウエイターは2つ以上のインターフェイスを実装することもあるとまで言ってるんだけど、割とスルーなのな。
なんせ、コード掲載必須をルールにしようと言ってる人が、ご高説しかくれないもんだからねえ。
同じことの繰り返しになるから
最後にまとめると
オブジェクト指向では
データと処理を一体化（カプセル化）する
それはネットの解説サイトでも入門書でも
だいたいそう書いてある
一体化してカプセル化することで
外側の利用者は簡潔なAPIだけ
知っていればいいから使いやすくなる
責務が限定されてるから保守もしやすくなる
データと処理がバラバラになってるのは
自己流だから他人に押しつけられても困る
もぎれてるか否か、ハンコの有無、といった状態をもとに各加盟店が判断をすると必ず間違いが起こる
後々ハンコ二つまで割り引くと仕様が変更になったとする
仕様変更に気が付かずハンコが1つ押してあるから割引なしと判断する加盟店が必ず現れる
？？
インスタンスを2つ作ればいいだけの話では？
ハンコ2つは筋が悪い。
一つだから押せば良いのであって、累積できるものはたとえ同じものでも、累積できるものであればもぎるごとく消費するか、予め2つ、ハンコ打つ欄を作るべき。
仕様変更に気が付かず、をなくすためのもぎりやハンコなんだから、先回りしろよ。
>>638
そういう問題じゃなくて、インターフェイスとするのはもっともだ、って話。
いちいち返しがズレてるなぁ
デザパタとか知らなさそうなガキが言いそうな台詞w
それはデザパタを深く理解してない意見だ
デザパタは基本的にカプセル化に沿ってるぞ
> 違う、逆に実際のキャンセル処理はCancelerしか知らない
> Cancelerのcancellなどのメソッドにキャンセル処理を書く
実際の実装では、キャンセル処理には注文のデータそのものが必要なので、「注文の中身を知らない
Cenceler」だとキャンセル処理はできない
なので、CencelerにはOrder自身を渡す必要があり、その結果相互参照するという結合になる
> 肥大化していくから委譲する
肥大化してから考えればいいこと
それとも、最初から「注文実行クラス」「注文内容変更クラス」「注文キャンセル実行クラス」に分割しとくのか？
そのコードだと、C(注文する)・R(注文を取得する）・U（注文を変更する）・D（注文をキャンセルする）の
D以外の目的でOrderクラスを使いたいときでも、常にクライアントはCancelerをインスタンス化する必要がある
さらに言うと、OrderがCencelerに依存しているということをクライアントが知っておく必要があり、
仮にCancelerのコンストラクタ引数に変更があると、Orderクラスのクライアントコード全部を修正する必要がある
> ビジネスロジックは、データの持ち物じゃない。
> 逆。ビジネスロジックがステートを持つなら百歩譲って理解できるが、データがロジック持つのは責務で言えば越権行為じゃないの？
実は、DDD（ドメイン駆動設計）ではそういう考え方に近い
だからといって、一般の「データ＋処理＋ルール＝オブジェクト」が間違いというわけではない
うん。そこは納得してる。
「処理」と「ルール」ってのはオブジェクトの責務上持ってて然るべきだけど、それはオブジェクトのインスタンス一つが自分でできる範囲って思ってる。
これ、実務以外では確かSOLIDとか言って定義した人の本で見た気がする。
ググった感じこんなのかな。
https://code.tutsplus.com/ja/tutorials/solid-part-1-the-single-responsibility-principle--net-36074
javaeeとか知らなそうなやつらばっかだな。
POJOとか、いやEntityであるべきだ、DTOだ、ってJavaだとホントいつやったかわからん議論だな、確かに。
バカなの茶？
＞相互参照するという結合になる
相互参照は不可避でもない
たとえば話を単純にして
注文日から何日以内という情報さえあれば
キャンセルできるとする
その場合、注文日オブジェクトを
OrderとCancelerが（コンポジションで）参照する
共通参照はするが相互参照じゃない
＞肥大化してから考えればいいこと
SOLIDの話が出てるからついでに触れれば
注文とキャンセルは異なる責務だと
分かっているので最初から分離したい
バカなの茶？茶茶茶おも茶ンの茶？
ドメインドライブ開発も知らん土方がイキっとんじゃないぞ！おう！
＞常にクライアントは～する必要がある
インスタンス生成の処理は
ファクトリに隠蔽すれば
クライアントは依存関係や
コンストラクタについて知らなくてもいい
>>646
＞DDD（ドメイン駆動設計）ではそういう考え方に近い
ええ……？ 逆でしょ？
DDDではドメインオブジェクトが
ビジネスロジックを持つ
データと処理をカプセル化する
OOの基本はDDDでも変わらない
あとついでに言うとDDDやるなら
（ドメイン層では）POJOね
才能ないね＾＾
ここは初心者が活発に意見交換して知識を共有するためのスレッドだよ
まともな人はこんなところに来ない
そうなの？
キャットドアとかいう欠陥問題を揉んでるスレかと。
なんともならないとなったら壊れる奴居るとこもどっかのスレと同じだなぁ。
注文日オブジェクトって何者なの？
正規化しすぎたRDBみたいな話じゃん。
そんな意味のあるようで無いデータ、共通参照したら死人が増えるだけでは？
「何日以内」って誰が持ってる設定値で、誰がそれ使って処理するの？注文日オブジェクト？
密すぎると思う。分離できてそうで、全くどれも単独で存在できないじゃん。
ドメインモデルなら、EntityとValueとServicesに分けたら、Orderはどこに行くの？
よろしく
if (order.cancelable()) {
order.cancel()
}
例外はなんにでもあるからそのことについてコメントはしないが、
この場合キャンセル可能と判明した直後にキャンセル不可能になる可能性がある。
if (order.cancelable()) {
sleep 1日
order.cancel()
}
とやれば理由がわかるだろう。
これが正しい書き方だからな
try {
order.cancel()
} catch(e) {
キャンセルできない場合の処理
}
＞「何日以内」って誰が持ってる設定値で、
＞誰がそれ使って処理するの？
たとえば注文日オブジェクトが
期限日を判定するメソッドの形で持つ
キャンセルがそれを参照する
もっとていねいにやるなら
注文日オブジェクトの値から
期限日オブジェクトを生成して
キャンセルは期限日オブジェクトだけ参照するとか
どれくらいの粒度でやるかは
実際の処理がどれくらい複雑かによる
＞密すぎると思う
それはたんにひとつのクラスで
何でもやることを密だと思ってない感想
＞共通参照したら死人が増える
逆、逆
構造化だと修正に弱いから
仕様変更に対応できなくてデスマになる
OrderはEntity
注文日とかはValue
>>661
もちろん実務では例外処理が重要になるが
サンプルコードとしては複雑になるので省略してる
回答まだ？
期限を判定するメソッドには注文日オブジェクトが必要、
期限日は別にオブジェクトとして期限日オブジェクトが必要。
それCOBOLなんかでよくあるメタテーブルとかわらんくない？
一つのクラスでやらんよ。ジョブランナーはひとつだが、例で挙げたOperaionごとに、は別クラスというか、タスクとしてアクター最初から作る。
どのOperationだとどのアクターか、ってのはジョブランナーしか本来は知ることができないものでしょ。
毎年会計周りは変わるシステムだったけどデスマ起こったことほとんどないよ。
会計屋は、会計する以外のタスク持ってないんだから。
>>663
注文がEntityなのがわからん。何故？
注文日をValueにしたからでは？
> ファクトリに隠蔽すれば
わざわざ結合度が高いクラス同士に分割して、簡単にインスタンス化できなくなり、
なのでファクトリメソッドを用意する？
>>577のように実装すればシンプルなのに、そうやることでなにかメリットがあるのか？
> データと処理をカプセル化する
> OOの基本はDDDでも変わらない
Entity, ValueObuect, Serviceの話だよ
>>662
> たとえば注文日オブジェクトが
> 期限日を判定するメソッドの形で持つ
> キャンセルがそれを参照する
まぁ俺なら文字列比較で一行で終わらせるだろうが、無駄に複雑にして何がうれしいんだか
>>577はシンプルそうに見えて闇が深くないか？
例外をThrowするなら、外のCatchは本来は型指定でCatchしてるはずじゃん？
例外の種類増えないって保証も無いし、事実上はCancelを変えると、一旦全体の動作が保証できない状態に陥るかと。
そこからテストするんだろうけど、まず全体のテスト定義書き換える事になるから、全体のテスト定義の定義にあたる要件定義からテスト起こし直しでは？
自動テストかけられる方向で修正したくない？
> 例外の種類増えないって保証も無いし
例外クラスは基底クラスでcatchできるということは理解してるか？
> 事実上はCancelを変えると、一旦全体の動作が保証できない状態に陥るかと。
Order自身は、正しくキャンセルできたかできなかったかのどちらかでしかないから、
全体の動作は変わらないと思うが
> そこからテストするんだろうけど、まず全体のテスト定義書き換える事になるから、全体のテスト定義の定義にあたる要件定義からテスト起こし直しでは？
> 自動テストかけられる方向で修正したくない？
ちょっと意味がわからない
基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。
>>559でいったような、否定文での条件定義と同じく、そのときに定義されていたもの、でしかない。
Orderが正しくキャンセルされたか、って、キャンセルすることができるか以上に正しくが未定義すぎる。
自動テストのくだり。
今までのロジックに一切手を加えていなくて、かつ、お互いが疎であれば、今回分の増分のテスト作って実施しつつ、過去のテストをそのまま実行すりゃ良いじゃん。
呼び出す、みたいな形だと、呼び出してる側のテストまで作り直しじゃん。
全段落含めて言うけど、実務でやらんの？
> 基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。
いやちょっと根本認識が違いすぎて、何をいいたいのかよくわからん
君のソースには、catch () {}が10個くらい並んでるのか？
> Orderが正しくキャンセルされたか、って、キャンセルすることができるか以上に正しくが未定義すぎる。
キャンセルが完了するかしないかの二択でしょ（それ以外に致命的な以上による例外を含めれば三択だが）
キャンセルできないパターンが多少増えても、全体で見れば変わってないでしょ
> 自動テストのくだり。
> 今までのロジックに一切手を加えていなくて、かつ、お互いが疎であれば、今回分の増分のテスト作って実施しつつ、過去のテストをそのまま実行すりゃ良いじゃん。
> 呼び出す、みたいな形だと、呼び出してる側のテストまで作り直しじゃん。
まじで何を言っているのかわからんのですが
コードで説明して
例えばSOLIDの原則とかがあるんだろ
なんでCancelを変更したら、全体に影響するんだよ
そりゃ設計が悪いとしか言えんわ
勝手に既存の例外クラスツリー/群と全く関係ない例外クラスなんか作るなよ
Validatiorライブラリ作ってるんなら、
class ValidatorException extends RuntimeException {}
を継承したOutOfBoundsValidatiorExceptionを追加しろ
で、Validatorライブラリのクライアントは、基本的にはValidatorExceptionかRuntimeExceptionをcatchしろ
え？どー言うこと？Exceptionなんかでトラップしたら静的解析にすら怒られるだろ。
FileNotFoundExceptionなのか、とかトラップして、定義外はアプリケーションレベルのハンドラまで飛んでプロセス殺すよ。
それでも既に3択じゃん。
キャンセルには、キャンセル後に承認が必要になった、なんてときには、キャンセル呼んでる所全部直してくの？
キャンセル出来た訳ではなくなるよ。キャンセル処理は完了したんだろうけど。
そもそも正常系を例外で処理すんな。
テストの事。
....cancel()が、メソッドで、かつ、例外を吐くならば、
呼び出し元のtry-catchやってる、例えばCartやらUserやら、そのクラスも必ず再試験でしょ。
CardやらUserを再試験するならば、システム全体の結合試験もやり直しだわな。
かつ、その試験仕様は、要件が変わったんだから、試験仕様やソース以外からつくる他ないだろ。
サブシステムやデータクラスの問題が、システムの問題になる。
例外吐くんだから。例外って端的に言えば大域ジャンプだぞ。
>>673
アホか。
モノによったらゼロは難しいかもしれんけど外に迷惑かけたらやばい
プログラムの例外を逃がすだけでリアルの俺が殺される
同じことの繰り返しになるから
ひとつだけ言うと
＞Entity, ValueObuect, Serviceの話だよ
Value Object はメソッドを持つよ
データと処理をカプセル化する
Services は処理専門だけど
Entity と Value Object だけで扱いづらいものだけ
Services を例外的に適用するのであって
Value Object をメソッドを持たない
たんなるデータの入れ物にして
Services から処理するのは
手続き的なアンチパターンで
DDDのやり方ではない
ファクトリに隠蔽すれば
クライアントは依存関係や
コンストラクタについて知らなくてもいい
これ意味わからん
コード書いてみてよ
orderオブジェクトはそのメンバにシステムへのリンクを持ってるってことか？
class order
{
system s;
void cancel()
{
s.cancel( this );
}
};
↑これなんかすごく筋悪くね？
system.cancel(order);
で良くね？
cancelの処理がオーダーだけで完結するとは思えんし
俺の中でorderがレシーバーとなってcancel処理っていう発想がない
で、order.is_cancelable(); も何か変で、キャンセルできるかどうかは
orderクラスだけで決まることではないし、キャンセルできるかどうかのフラグを
orderに持たせていちいち更新するのも変な話だな
そもそも、orderが何でそんなこと知ってるんだ
ただ、キャンセル中かどうかなどのステート値はorderに持たせて良いと思うけど
他に置き場ないし
プログラムは明確にトップダウンなほうが読みやすい
手続き型プログラムにはデータ構造と制御構造の二要素しかないんだから
それぞれ組み立てたうえで、それらをどのように割り振るかってことだけ
考えとけば変なことになりようがないと思うんだけど
あと「誰が処理するべきか」って発想がダサくて、そりゃ誰かと問われれば
処理するのは何時でもコンピュータだわな
そうじゃなくて、本来は 「どこへ書くべきか」 だろ？
発想の転換というか、本来のあるべき考え方を取り戻すというか
現実を正しくとらえないとな
俺オブジェを作ろう
ore.god
誰が処理するか、とかワケワカランことは考えなくてよし
これで大体迷子になっている人が多い印象、2chみてる限りはね
そのオブジェは邪魔なのでお片付けしちゃいましょーね～
そうやって君はコントローラーやセービスにたくさん手続き書くんだろう？
それじゃオブジェ志向にはなれないだよ
カプセル化としても大切なポイントなのに
でもよ、書かなきゃならないコードの総量は決まっているわけよ
必要な機能を削るわけにはいかないからな
とにかく、それは、決まってるから、初めから
それを分割してどこへ書くかってだけの話で
無理に小さなオブジェクトへ不必要にコードを押し込んでも意味無いっつーか
自然な形で実装できればそれでよし
自然が一番
「末端のオブジェクト」でおねがい
日本の未来は明るいな
> 必要な機能を削るわけにはいかないからな
> とにかく、それは、決まってるから、初めから
これ読んだだけで程度がしれるからすごい
プログラムのメイン部を4つも用意するのはマジ勘弁なんで
その辺も含めてコンパイラのループのSIMD展開に頑張ってもらうしかないと思う
何言っても無駄なのは知ってるし
囚われてる的な何か
自分で気づくまではどうにもならない類
迷路を自分で作って自分で解くのには飽きた
ただそれだけ
↓
でもよ、書かなきゃならないコードの総量は決まっているわけよ
必要な機能を削るわけにはいかないからな
とにかく、それは、決まってるから、初めから
ガイジか？
そして毎回同じテストをしているのだろうか
クソコードクソ重複が
お前にとっては「書かなきゃならないコード」
ってことかい？ｗ
>>676
> DDDのやり方ではない
ルールをどこに実装するかの話で、あ氏はデータがルールを持つのに納得できないというので、
DDDではServiceにルールを実装することもあり、DDDの話を持ち出したまで
> そもそも正常系を例外で処理すんな。
ケースバイケースだしポリシーの話でもあるね
>>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
> アホか。
何がアホなのか全くわからない
君と会話する意義がゼロに近づいてるぞ
おそらく基底クラスの認識がズレてる
例外をスローってのは、もうどうしようもない場合だろ。
ServiceExceptionに新しい小クラス作ったなら、それは元のServiceExceptionではないんだから、テスト範囲膨大になんじゃん？って話。
前提として変わってるよ。....NotAllowed....で拾ってたなら、具体的にはNotAllowedのうちのあれとこれとそれを拾ってた訳なんだから。
大きくCatchして、その中で各サブクラスごとの処理してた時に、新しいサブクラスのハンドリングはすべきか否か、ってのが、仕様として考え直しだろって話。
APIとしてシンプルが売りって、それ呼ぶときだけで、ハンドリングは全然シンプルじゃないじゃん。
大雑把にしか取らなくて良いのと、大雑把にしか取れないのは全然違う。
未来の定義を含んでるから大きく取る他無い、って設計として柔軟なんじゃなくて、設計としてあやふやなんじゃん。
ある意味、そいつが責務として無責任な返事をしてて、その後始末を使う側に押し付けてるように見える。
こういう風にかくも脱線するのがOOPなのかしらね
平たく言えば、もともとは
メソッドが正しくないタイミングで呼ばれたら、どう対処すべき？
って質問だったろう
で、明確な答えなんかないだろう
例えば、a=10; b+=a; って書くべきところを順番を間違えて b+=a; a=10; って書いたら
正しくないタイミングで処理したといえるわけだけど、コンパイルエラーも実行エラーも出ないし
それが我々の日常で、ただのバグであって、手続き型言語というのは何時でも順番が大事で
正しいタイミングで処理が走るように気を付けて書くものだったろう
一方で、順番を間違えたためにバグってヌルポやdiv0が発生することもある
ただしこれはどうしても続行が不可能だから例外を飛ばしているわけであって・・・
あとほか、初期化前の変数を参照しようとして怒られるとか、もあるが
基本的には手続き型言語は処理の順番の権化なので
処理する順番を間違えたとか、変なタイミングでメソッドを呼んだとか
それはプログラマのポカ、バグ、なんだから、テストで炙り出すしかないだろう
こんなことを全部が全部丁寧に例外なんかで対応していたら
手続き型言語はすべての個所で順番が重要なわけだから、全てでチェックが必要になる
順番やタイミングを誤って良い場所など、無いと思ったほうが良い
明らかにおかしなタイミングやおかしな順番で呼ばれたら例外を投げるのは有り
ただしそれはプログラマがミスをしたことを早期に伝えるためであって
そこで条件分岐などして通常フローに組み込んだらまたおかしなことになる
まぁほどほどに
っていう程度の話なのに、それが何故
何処でキャンセル出来るかどうか判断するか、とか
キャンセル処理は何処でするか、とか
認可がどうのこうの、ジョブがどうのこうの
とかって話に派生するのが謎だわ
ある意味では面白い問いかけでは有ったと思うよ
手続き型言語で「手続き」を間違えた場合、どう対処するか？っていう
そのままバグるのか、例外投げるのか、エラーコード返すのか、何もしないのか
好きなのを選べ
「呼び出し元のプログラムがバグってて誤ったタイミングや順番でメソッドが呼ばれた場合
どう対処すべきか」
っていう問題と
「仕様上、今現在キャンセルできる状態なのかどうなのか、また、どこで判定するのか」
という別問題を混同して一度に扱おうとするから
話がややこしくこんがらがっているのではないか
> 例外をスローってのは、もうどうしようもない場合だろ。
トランザクションをコミットできないような事象は全て例外でハンドリングするというポリシーもありえる
> ServiceExceptionに新しい小クラス作ったなら、それは元のServiceExceptionではないんだから、テスト範囲膨大になんじゃん？って話。
だから基底クラスでcatchしろって話なんだが
> 「呼び出し元のプログラムがバグってて誤ったタイミングや順番でメソッドが呼ばれた場合
> どう対処すべきか」
そんなこと話してた奴いたか？
> 前提として変わってるよ。....NotAllowed....で拾ってたなら、具体的にはNotAllowedのうちのあれとこれとそれを拾ってた訳なんだから。
> 大きくCatchして、その中で各サブクラスごとの処理してた時に、新しいサブクラスのハンドリングはすべきか否か、ってのが、仕様として考え直しだろって話。
全く意味がわからん
コードで説明して
> 大きくCatchして、その中で各サブクラスごとの処理してた時に、
ちょっと待てよ、そんなこと誰もしないぞ
つか、君、SOLIDのことはわかってるんだろうな？
まさかとは思うが、ポリモフィズムすら知らないなんてことはないよな？
>>412を100回読めばわかるが
もともとは
「実行できない状況でメソッドが呼ばれたら、どう対処すべき？」
って話だろ
で、実行できない、処理を続行できないので、例外投げてますよ、というだけの
実際彼は
> ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
> ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
とも言っているわけで、呼ばれてはいけないタイミングで呼ばれたら、どう対処すべき？って話なんだよ
呼んではいけない状況で呼ぶな、バグるから呼ぶな、は手続き型の基本であるが
まぁ安全のために例外でも飛ばしておこうと
それを>>416が
> 値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
と余計なことを言うから話がややこしくなって脱線したわけだが
実際には cancel() がどこに実装されていても関係ないわけよ
本質は、キャンセル出来ない状況で cancel() 呼ばれたらどうすんの？例外飛ばすの？
例外であふれかえるんだけど？
って質問なんだから、どこに実装されていても関係ない
そしてこんなことは手続き型プログラミングではありふれている一般的な話題であって
(手続き型なんだから手続きを守ってもらわないと困る)
ジョブとか認可とか、以降の話は、まるで脱線
「初期化メソッドが呼び忘れられている状態でオブジェクトの他のメソッドが呼ばれたら
どう対処すべき？例外飛ばしとくべき？例外であふれかえるんだけど？」
っていう質問と同義なんだよ
> もともとは
> 「実行できない状況でメソッドが呼ばれたら、どう対処すべき？」
> って話だろ
そうだが、バグってそうなったらという話じゃないと思ったが
> って質問なんだから、どこに実装されていても関係ない
そんなことないって延々話が続いてたわけだが
まー、理解できないなら仕方ないわ。
DTOオブジェクトにメソッド持たせたりとか、過去やった事として悪手だと言ってるんだが、
多分使いたくて仕方ないんだろ。
> っていう質問と同義なんだよ
俺は全然違うと思うけど、OOに詳しくないと同じに見えるのかもね
画面上のキャンセルボタンは無効になっているか表示されてないか
ともかくキャンセルのオペレーションは実行できなくなってるはずなんだよ
もし無理やり飛んできても、どこかの段階で弾く
それなのに cancel() が呼ばれるってのは基本的にプログラムがバグってるんだよ
だからキャンセルできない状態なのにcancel()呼ぶな、バグるから呼ぶなって事になるが
それでもプログラマの不注意で呼んでしまうかもしれないので
安全のために例外でも飛ばしておきましょう
そうすれば早期に気づくでしょ、ってこと
だからassert()みたいなものだな
>そうだが、バグってそうなったらという話じゃないと思ったが
バグらずにそうなるってどういう状況だよ
実際にcancel()呼んでみて例外が飛んできてから
「あぁ今キャンセルできない状態みたいだからゴメンって画面に表示しとくか」
ってプログラムあり得るか？
キャンセルできる状態かどうかは事前にチェックしてて
それに合った画面表示になってるだろ
それでもcancel()で例外が飛ぶことはあるだろうが
それは本当の実行時エラーだ
少なくともキャンセルできない状況というのが事前に判明しているにもかかわらず
実際にcancel()呼んでみて例外が飛んでくるかどうかで判断とかあり得ないだろ
だからキャンセルできない状態でcancel()が呼ばれるってのは単純にバグってるんだよ
その辺をケアするかどうかの話だろ
> 画面上のキャンセルボタンは無効になっているか表示されてないか
> ともかくキャンセルのオペレーションは実行できなくなってるはずなんだよ
そんなことないから、どこで/誰がキャンセル可能かどうかを判断すべきかって話になってるんだが
・ブラウザで注文一覧を見る
・見ている間に発送処理が完了する
・注文キャンセルを行う
・サーバが注文キャンセルリクエストを受け取る
みたいなときとか
厳密に言えば、
if (isCancelable()) {
doCancel();
}
がアトミックでなければ、「発送」が途中に滑り込む可能性もある
ここはできるだけヒューマンエラーを排除するための考え方を話す場所なのにね
それは本当に防ぎようのないことだから例外投げるなりなんなりすればよいが
もともと質問者はそんな質問はしていないだろ？
そんなことをどうにかしてくれって言ってるわけじゃないだろ？
>>412のコードを見てもそうだし
>>417でも
> ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
> ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
って言ってるだろ
「呼んではいけない処理を容易に呼べてしまう」
って書いてあるだろ？
これは要するに、「呼んではいけない状態の時に呼んではいけないメソッドを呼べなくする方法はないものかね？」
って質問しているわけだよ
それが出来ればプログラマが呼び出しミスすることを原理上なくすことが出来て
ここが大事だが、「その類のエラー処理を書かないで済むので」
> ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
のを防げるんだけども？っていう質問をしているんだよ
呼んじゃならない状態ってわかりきってる時でも、呼んじゃならないメソッドが呼び出せちゃうから
それに対するエラー処理書かなきゃなんねーメンドクセーなんか良い方法ない？って質問なんだよ
だがそれは手続き型言語に対する挑戦でもあるから程々にって俺は思うが、そのことはまぁどうでもよい
それで>>453なんかは質問者の意図を理解してスレの流れを元に戻そうとしているし
>>706なんかも質問者の意図を理解しつつ、探っているだろ
とろこが若干約二名は全然質問の意図と関係ないことを延々と長時間ものすごいレス数で
いったい何やってんだ？
こんなのがプロジェクトに交じってたら会議がいつまでたっても終わらないし
これがもし顧客の質問だったのなら、もうあいつは連れてくるなってなるだろ
全然違うこと言いだして知識をひけらかしあって何がしたいんだ？
そんなもん自覚できてるわけねえだろｗ
もししててもさすがに発表できないだろｗ
> 全然違うこと言いだして知識をひけらかしあって何がしたいんだ？
知識ひけらかしあってって、すげー低レベルな話しかされてないんだけど。
嫌なら飛ばせよ。
> それに対するエラー処理書かなきゃなんねーメンドクセーなんか良い方法ない？って質問なんだよ
結論としては、オブジェクトのメソッド内部でチェックをして、例外で（エラーコードでいいけど）
返せってことでしょ。
手続き型だって、正常時が戻り値0、異常時がマイナスの値だったら、
if (hoge() < 0) {
some_error_process();
return;
}
some_process();
と書いて、hoge()のエラーの種類が増えても大丈夫なコードにするだろ？
それと同じだよ。
そんな事言ってないぞ。
正常にキャンセルに失敗したならば、そりゃ例外じゃなくて結果だって。
引っこむ必要もわからん。
とりあえず、手続き型ではないオブジェクト指向であれば、ロジックは例外ありきで作るべきなのかってのは気になる。
例外ではなく、メッセージパッシングに使ってるなら、それは例外の濫用では？と。
やらんだろそれは。
if(hoge()==0){
some_process();
}else{
some_error_process();
}
return;
じゃねえの？
正常値があってのエラーなんだから。正常時は0なら、今も未来も正常値は0であるんだから、そっちを判断基準にすべきじゃん、って話。
もともとの>>412のコードよく見てみろよ
「assert」って書いてあるだろ
assertで投げた例外をトラップしてフローを切り替えるとか、あり得ないだろ
だから元々からして例外をトラップして処理を切り替えるって話じゃない
エラーコードが良いか、例外が良いか、も関係ないし
もしC言語だったならassertに引っかかったらabortして終わりの話
その後の後処理のことなんかまったく関係ないし、むしろ関係させてはいけない
assertに依存してその後の流れが変わるプログラムとかあり得ない、バグったことが分かればそれでよい
だから>>721も>>724も関係ない (しかも言ってることがどうでもよい)
assertで投げてるからにはこれはデバッグ用のコード
プログラマがクラスの使い方を誤ったときにassertで引っ掛けて知らせるのが趣旨
これを書くのが面倒だから、そもそも、呼ばれても困るときに、呼べないように出来ないか、と言っている
俺じゃなくて本人が>>417で言ってる
> ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
呼べてしまうから対応が必要になるので、呼べないように出来ないか、という話
呼ぶべきじゃない状態の時は、呼べなくしてしまってもかまわない、ということは、実行時エラーの話ではない
トライしてエラー捕まえる、そんな話ではない、元から呼べなくしてしまって構わないと、本人が言っている
Null 許容型とかそっち系の話
君らがしているのはNullチェックの仕方の話であって、質問者が言ってるのは
Nullを許可しないにはどうしたらよいか？のような話
話がおかしな方向に行ったのは>>416の
>値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
からで、その考えに賛同しないわけじゃないし、むしろ好みであるが
だが今は関係が無い、ここでおかしくなった
そして無駄に300レスを消費したわけだが、話している内容はOOPでは何時もの事だが
「何をどこに書くか」であるが、このような宗教的話題は、ひとまず今は関係無かった、趣旨ではなかった
レイヤーが全然違った、もっとプリミティブな質問だったわけだ
↑がまずまだ間違っている
問題の趣旨を全く理解していない
元のプログラムはassertで投げている
これをキャッチして分岐する処理を制御フローに組み込んで出荷するのはあり得ない
if (hoge() < 0) {
some_error_process();
return;
}
some_process();
↑こんな話ではない
例外が飛んで来たら、ああ、バグ仕込んだな、コードを修正しなきゃ、って話であって
キャッチして対処する話ではない、エラーコードで分岐する話でもない
assertレベルの話だ
それに対して>>724がまた本当にどうでもよいことを言い出す
会話を長引かせることしか考えてないのか？
要件に無い。無いことをむしろ書くな。
>>726
ああ、これは読み損ねてた。すまん。
assert出したら死ぬってことだな。そりゃそっちが正しい。
いや、呼べてしまうから、呼べないようにしたい、に対してをずっと言ってるんよ。
呼ぶんじゃなくて、呼びたいとキューなりなんなりしろ、と。
そしたら、呼びたいというのは自由になる。
そのタスクは、「呼ぶ人」一人がさばいて、呼べませんでしたよと端的に残す、と。それは呼ぶことのエラーじゃなくて、呼ぶ人の、呼びたいキューに対する結果だよ、と。
だから、データに生やしたメソッドでやるのは、そのデータ一人が対応できる処理に限ろうね、って話に行き着くから、データ自体でロジック書かないでおこうね、って話だよ。
お前が使ってるライブラリは例外飛ばしてくるだろ？
それはバグなのか？
お前が使うライブラリは例外を飛ばすのに
なんでお前が作るライブラリは例外を飛ばさないんだ？
例外の使い方間違ってるだろ
無理と言うかどっかで歪んでくる。
最初からそんなデータと処理を分割できなくなるような書き方するな。と。
結論「無謀」なの。
OrderRunnerとか、OrderQueueを作ることに何が問題なのかわからん。
横からだが、ライブラリが例外を飛ばすなら、ロジックではそれはトラップしてるべきかと。
どーしよーもないやつはトラップすべきでないので、最初からトラップしない。リスローもしない。では？
DiskFullやらOOMやらハンドルしても無駄でしょ。今現時点のスナップショットが正しく落とせるかすら不安な状態で無理に生き残っても意味ない。
ランタイムまで飛ばしてランタイムごと落ちるべきだと思う。
まさか21世紀になってABENDを見るとは思わなかったが、割と業種によってはあると思う。
お前がどれだけライブラリの例外を知っているのか知らんが、
例えばデータベースに接続できないとか
ファイルが無くてオープンできないとか、
そういうのも例外だからな
> DiskFullやらOOMやらハンドルしても無駄でしょ。
え？ DiskFullだったら「ファイルを消して再実行してください」
って表示するべきじゃないの？ｗ
だから、そんなのオープンするときにハンドリングしろよ。
オープンできなけりゃ死ぬなら、死ねばいいんだし、
リトライやらなんやらするならそいつがやれ。
gotoやらlngjmpの代わりに使うな。
なにをそんなに熱くなってるのか知らんが、
殆どの例外はやろうと思えば復旧可能
例えバグによって発生したものであっても
そのバグの間接的な原因（変な値を入れない）をユーザーが
取り除いて再実行できる。
あー、ごめん、それは例が広すぎたな。
ユーザがすぐにリアクションできる操作でそうなりゃ、問い合わせれば良いけど、ファイルを消して再実行が間に合わんままシステム動き続けて、メモリにも乗らなくなる可能性があるなら、最初からCatchすんなと。
そう言う意味では上の方でDiskFullExceptionを握ってるやつが居たら死ねと思う。
ってか、容量ぐらい先に確保できるか確認して、確保できなければエラー、確保できれば確保してから書いてケツを整えたら良いんでないの？
それは、例外でやるべきじゃなくて、チェックロジックでやるものでしょ？って。
自分が壊れたもの自身が「自分はリカバリできました！」って言う事ほど信用ならん事はない。
（自分の都合がいい場合）は例外じゃなくていいって言ってる？
都合がわるい場合は例外とかダブルスタンダートはよせよｗ
> ってか、容量ぐらい先に確保できるか確認して、
はい。ダメなパターンｗ
> 自分が壊れたもの自身が「自分はリカバリできました！」って言う事ほど信用ならん事はない。
自分が壊れたものを、他人が直せるわけ無いだろ？
何を言ってるんだ。
実行時例外だっけ。OutOfMemoryErrorでCatchはできるけど。
お前何言ってんの？
都合が良いも悪いも、そんなもん、例外としてなげるんじゃなくて、ハンドリングしてからやれ、っていうライブラリ側の話と、
ユーザが、っていう業務ロジックの話を混同してるからじゃねえの？
>>741
当たり前だろ。
おもなしく死ねって言ってんだよ。
おとなしく死んだらまともな奴が代わりを立ち上げるし、
それでも死んだらデータが悪い。
まともな奴が判断しろ。
代わりを立ち上げるのなら、
そのまま起動し続けたほうがよくね？ｗ
ペチパーの人達が死にそうだねｗ
デスクが満杯エクスペクションになったら
エラーメッセじゃなくて
ショットダウンしていいのか？
PHPのベースとなってるのはC言語で、
そのC言語は0 = NULL だから
0は偽として扱う必要があるんだよね。
設計の粒度とか一貫性なくて、大規模で開発したら崩壊しそう。
> いや、呼べてしまうから、呼べないようにしたい、に対してをずっと言ってるんよ。
> 呼ぶんじゃなくて、呼びたいとキューなりなんなりしろ、と。
お前こんだけ話が続いてて一切進歩ないな。
呼べないようにするって話と、要求をQueueで管理するってのに全く関連性はないぞ。
> だから、データに生やしたメソッドでやるのは、そのデータ一人が対応できる処理に限ろうね、って話に行き着くから、データ自体でロジック書かないでおこうね、って話だよ。
だから、その範囲のビジネスルールはそのデータがもつmodelなんかに実装しましょうねってことだ。
実行するそのタイミングまでわからない場合が多々あるってことを無視すんじゃねぇ。
だから、「実行できるときだけQueueに入れる」なんてことはできない。
それは場合によりけりかと。
ちょっと特殊例だけど、担保できないなら止まってるほうがマシってやつ。
Javaじゃないけど意味わからん死に方してるの見たことあるよ。
最終的にわからんから立ち会ったら、近くですっごいモーター回った時にメモリ化けてた。
>>749
モデルに持ったら、業務ロジックの改修は全部モデルがやんの？
>>750
根本的に理解してない。
実行できるときにキューに入れるんじゃない。
実行したいとキューに入れる。
それができるかどうかは、本当にOrderを処理するロジックが考えるべき事。
http://education.yachinco.net/tips/java/08/3.html
> モデルに持ったら、業務ロジックの改修は全部モデルがやんの？
お前の表現でいえば「Orderを処理するロジック」がやんだよ。
俺の感覚だとassertでエラーチェックするのはゴミコードなんだが、Javaだと普通なのか？
> 元のプログラムはassertで投げている
> これをキャッチして
こんな話初めて聞いたんだが、何の言語だとこんなことできんの？
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もありえんってことだな。
俺の質問優秀だからね
Orderを処理するロジック、が、Orderのメソッドに依存してたら、全部改修だね。
って話。
いい加減バカなの？
注文の通貨がビットコに変わったり
伝票にユーザの証明写真電子透かしで入れる仕様になったり
したら、広範囲改修だろ
てゅか、改修の範囲も依存の仕方によるだろ
依存依存ってバカの一つ覚えのように言ってるが
おまえOrderクラスimportしたら依存だとでも思ってるのか
おまえのゆう「依存がない」って南南だよ
システムのためにナカ全部json stringでやり取りする気かバカなの茶？死ぬの茶？
>>726でも書いたが
元のコード>>412は「assert」で例外を飛ばしている
これが何を意味しているかすら理解できないのではどうしようもない
>お前が使ってるライブラリは例外飛ばしてくるだろ？
>それはバグなのか？
当たり前だが確認として、例外を飛ばしてきたライブラリがバグってるとか、そういう話ではない
ライブラリを使っていて、ライブラリ内でassertが発生したなら
ライブラリを使っている側のコードにバグがある、ということになる
当然ソースコードを修正する、ライブラリ内でassertが発生したら、呼び出し元のコードを修正する
当たり前のこと、そのためのassert、assertはデバッグ用
assertは通常、デバッグ時にのみ有効で、リリース時には消えてなくなる
assertでデバッグ時に飛んできてた例外は、リリース時には飛んでこなくなる
だからこれに依存した分岐など、してはならない
>>728
踏まえて、>>412のコードの例外は、プログラマがクラスの使い方を誤ったときに
assertを発生させて、ミスってるよ、直してね、って知らせるのが目的
これに依存してトラップして分岐とか、もともとそんな話ではない
呼び出せない状態の時は、初めからメソッドを呼び出せないように出来ないか、って話
初めから呼び出せない(例えばスコープ上見えなくなっている、など)のであれば
間違って呼び出されることもないし、そのことに関するエラー処理も要らなくなるから
>>412
> Stateパターン使うのかなとも考えたけど結局空のメソッドから
> not supported exceptionを投げるようになるだけで本質的な解決策にならない
>>417
> ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
という風なことを質問者は言っており
そんで>>425では
> せっかく静的な言語を使っているのだから動的言語のようなことはできるだけ避けたい
とも言っているので、静的型の型機能を使って、なんとかならないか？という質問なわけだ
コンパイラにチェックさせることは出来ないか？ということだ
Null許容型とかと同じようなことは出来ないか？と
>>762-763
は>>728へのレスじゃなくて
>>729へのレスであった
レス番を間違えてしまった申し訳ない
とっくにワイが答え出しとるゆうとるやろ>>429
おまえら、300レスも何しとったんや？カスか？
普通に考えても、状態チェックして例外投げるなりエラー返すなりassertするなりするより、手間がかかるからだ
ある状態の時、あるメソッドを無効化することを考える
状態をチェックして無効であることをプログラマに教えるコードを仕込む・・・①
状態に対応するインターフェースを定義して実装する・・・②
この時、ただでさえ①より②の方が手間がかかりそうなのに
これに加えて状態の組み合わせ爆発で訳の分からんクラスを大量生産する羽目になったら
何をしているのかもはやよくわからない
また、状態が変化してインターフェースAからインターフェースBへはどのように移行するのか
ここで、誰が移行させるのかは問わないが
今まさにインターフェースAからインターフェースBへ移行したとして
B b = nanika( a );
まだインターフェースAの変数aは生きているので
(しかも、どこでだれが、どれだけ握っているかは分からない)
状態にそぐわないメソッドを呼ぼうと思えば呼べるわけで
結局エラー処理は(するなら)必要だ、意味がない
もしくは、B b = nanika( a );を呼び出した瞬間から、aのオブジェクトを無効にしてしまう
aのコピーを作ってそれをBを満たす状態で返し、aは無効フラグを立てて、意味のないオブジェクトとする
以降aのメソッド呼び出しは全部無効
しかし、あちこちでaが握られていた場合、aが無効になってbになったことをどうやって各所に通達する？
このようなことを考えていくと、とても現実的じゃないんだわ
まぁうまくいく場合もあるかもだが、かなり限定的だ
そもそも手続き型言語は状態や順番やタイミングによって、呼んで良かったり、ダメだったり
正しく動いたり、動かなかったり、正常だったりバグったり、するものだから
根本的に解決したければ関数型言語でも使ってもらうしかないんだろう
手続き型言語で手続きそのものの誤りをコンパイラに検出させようってのは、かなり、なんというか
プログラムの並びが正しいかどうかコンパイラに調べさせる話だから、それ出来るならすごいよね～
数学板 ２つの封筒問題 Part.3 [無断転載禁止]©2ch.net
http://rio2016.2ch.net/test/read.cgi/math/1489358280/948-950
しかし、そっちの俺の書き込みの長文の方が、面白いと思うよ
なるほど。そりゃそうね。
B b= した時にはもうAは死んでる、を実現する(しても良い)ならば、Rustで書けば割と簡単。
ただ、俺はそういう扱いで色々書いてたから「お、賢いね。ありがとさん」と感心しながらRustかけたけど、
そう考えられない人にはRustはチェッカーがパラノイアじみてて使いづらいって印象を受けるとのこと。
なので、手続き型でも言語次第、書き方次第の問題ではあるよ。
あれには列挙型もあるから、カスみたいなマスク定数持たなくても良いしね。
misraに準拠してるかをよーわからんベンダのチェッカで確認しながらCで作るより余程使いやすいと思う。
> assertでデバッグ時に飛んできてた例外は、リリース時には飛んでこなくなる
> だからこれに依存した分岐など、してはならない
という意味で、>>412は最悪のコードですな。
> そもそも手続き型言語は状態や順番やタイミングによって、呼んで良かったり、ダメだったり
> 正しく動いたり、動かなかったり、正常だったりバグったり、するものだから
どういうプログラミングパラダイムだろうと、時間経過によって状態が変更しうるものの前には無力。
「事前にチェックして」「処理を実行する」が失敗するケースが発生しうる。
同時実効性や時間経過による変化、トランザクション分離レベルなどを考えないと、ベストな選択はできないだろう。
> 呼び出せない状態の時は、初めからメソッドを呼び出せないように出来ないか、って話
> 初めから呼び出せない(例えばスコープ上見えなくなっている、など)のであれば
> 間違って呼び出されることもないし、そのことに関するエラー処理も要らなくなるから
以上の理由で、上記のような実装を行えるのは、ごく限られたケースであることがわかったと思う。
今回はOrderを例にして話が始まったが、Orderは上記実装とは相容れないもの。
契約プログラムを知らない無知蒙昧なるゴミ屑なのかな？
CanceledOrder
DecidedOrder
は例が悪かったかも知れない
こうならどうだ
/** 予約系(チケットとか実体のない)注文 */
TicketOrder
/** 配送系(モノであり実体がある)注文 */
DeliveryHealthOrder
両者で、持ってるデータが大きく異なる場合は、
型で分けないとその「組み合わせ爆発」で状態の判定ifがそれこそ爆発する
「組み合わせ爆発」が嫌で汎用性が高いクラスを作りたいというなら
全てHashMap<Object, Object>で作ればいい
になるぞ
程度問題だ
「経過時間」の本質は「自分以外が触るデータ」であるか否かかと。
なので、データの分類は
自分だけが作れて、他人も見れるデータ（このデータは誰も編集禁止）
自分だけが作れて、自分だけが編集出来て、自分だけが削除できる、他人からは見る事が出来ないデータ
誰にでも作れるが、自分だけが見れて自分だけが削除できるデータ
の3つに切ると、やりやすい。
メールボックスみたいな仕組みがある言語なら要らん定義だけど。
Erlangは凄いわ。
アーアン言語ってたまに聞くね
その３つの仕組みをどういう仕組みで実現してるの？
プロセスかアトム ! メッセージ
の形でメッセージ送るだけ。
もらった方は
recieve
{pattern,match} ->
処理
って感じで処理する。
返事が要るなら、
recieve
{From,pattern,match} ->
処理
From ! 返事
みたいに返せる。
プロセス内の変数はもともと持ち出し不可。
自分が作れて云々は自分からのメッセージで、
誰にでも作れて云々は自分へのメッセージ。
それは言ってることが全然おかしい
今言ってるのは状態依存で呼べる機能が変わるものに
それぞれ別々のIFを用意するかどうかだ
EnableButtonClassとDisableButtonClassを用意しよう
で、ボタンが死ぬまで上記のどちらかで固定されるなら別に構わないが
実際にはボタンはEnableだったりDisableだったり動的に切り替わる
こうなってくるとディメリットがメリットを上回る
そのようなこと
ボタンクラスをどこかの処理に渡したいことなんてあるか？
オーダーとは全然別物だろ
抽象化が下手なやつはゴミみたいなPG書くって相場が決まっているもんだが
こりゃお里が知れるね
GUIフレームワークも自分で作る前提だろ
ただ、そんなこと自分ですることあまりないから例がアレとは思うが
それでもボタンを例を挙げたのは、既存GUIプレームワークのボタンクラスは
そうはなってないでしょ？って例になるからだけど
じゃなきゃ、また「俺はこうする、俺はこうする」って話になって
無駄に300レス消費するのは嫌だなぁと
>>429
リッチテキストとして成立しないものはリッチテキスト側で制御すべきだけど、
選択文字に打ち消し線を打つってのはリッチテキストのメソッドで、いつでも呼べる。
ただ、業務ロジックとして、この行には打ち消し線を打たせない、ってのをやりたいなら、フォームかラッパーにもたせるべきだけど、
そのラッパーを状態ごとに「無効:DisabledRText」とか「上長承認済の為スタンプのみ押せる:StampableRText」とか作るってんなら明らかに悪手。
最初から、コピー新規しかできなけりゃ何も問題は無いんだけど、編集って概念が出てくるととたんにSQLで言うSERIALIZABLEみたいなトランザクションにせざるを得なくなる。UIオブジェクトに。c#ならsynclockかなんかでできるんだっけ？
> なので、データの分類は
> 自分だけが作れて、他人も見れるデータ（このデータは誰も編集禁止）
> 自分だけが作れて、自分だけが編集出来て、自分だけが削除できる、他人からは見る事が出来ないデータ
> 誰にでも作れるが、自分だけが見れて自分だけが削除できるデータ
> の3つに切ると、やりやすい。
ほんと筋が悪いわ
それこそが、上の方の認可とか権限とかの話だろ
全然違う。カプセル化そのもの。
メモリ共有をせずにメッセージの受け渡しで処理を勧めていく。
あのさぁ。認可と同じとか、くだらんことほざく前に
Erlangでのメッセージの渡し方は見てきた？
技術力もなければ知識もなく、そして論理的思考力も無く、ソースの探究心すら無いならプログラマ辞めたらいいのに。
http://ideone.com/yvttId
あー、書いたねこれ。
> 技術力もなければ知識もなく、そして論理的思考力も無く、ソースの探究心すら無いならプログラマ辞めたらいいのに。
お前はそれに加えて文章力が壊滅的にない
うん、まぁ、これでちゃんと仕事して金もらえてるんだから、必要充分でしょ。
あんまり身の回りで通じなかったこと無いよ。文章。
よく読めば最初に言ってたりするのに、急いで斜め読みしてるように見えるが。
プログラムレベルは、ただのコーダーよりはマシだけど、リーダーにするには経験も頭も足りない微妙な人ばっか。
仕事の憂さを晴らすために、議論ごっこしてるだけw
終わってないね。
で結局キャンセルできるかどうかを判定する
メソッドはどこに作ることになったの？
まずキャンセルできるかどうかっていうのは
状態によってだけじゃなくて、権限によっても決まってくる。
でも状態の権限の２箇所で判定するのは面倒。
例えば、キャンセルボタンがenabledなのかdisabledなのかっていうのは
キャンセルできるかどうかで変わるわけだけど、
ビューに if (キャンセルできる？ && 権限がある？） などと書いてしまったら
こういうのがあちこちに散らばってしまう。ために権限の事忘れたりね。
だから if (キャンセルできる？) と条件一つにしないといけない。
このキャンセルできる？の中には権限のチェックなどすべてのチェックが入っている
キャンセルの「可能/不可能」と「許可/不許可」をいっしょにしてはいけない。
不許可だから不可能なのか、不可能だから不許可なのかは組み合わせだすとキリがないよ。
可能不可能と許可不許可だけで4つ、それに、結果的に不可能だった、とか過去形や未来形、次承認あれば許可みたいな新しい状態に対応するときに、累乗に比例していってしまう。
しかも結果はできる、できないの二択。
なら、最初からそのオペレーション自体を切り分けて、例えばキャンセルなら権限ごとのできるできないを、
前工程で作ってしまって、単純にそれを取得するだけにした方が責任範囲がはっきりする。
可能か不可能かは、注文のビジネスルールにより決定される。
許可か不許可は、権限管理のビジネスルールにより決定される。
（要件によっては、注文のビジネスルールとする場合もあるかもしれない）
最終結論は「{許可 or 不許可} & {可能 or 不可能}」だ。
なにをごちゃごちゃ言ってるのか理解不能。
例えばさ、ショップの管理者であれば、
すべての注文のキャンセルが可能でしょ？
一般の顧客は、通常は自分の注文しか
キャンセルできないよね？
これは権限？
権限だろ
権限だとしてその権限の条件は？
自分のIDと注文のIDが一致しているか？っていう
条件を何処かでやらないといけないよね？
○ 条件判定を何処かでやらないといけないよね？
その条件判定はどのメソッドにあるの？
× その条件判定はどのメソッドにあるの？
○ その条件判定はどのオブジェクトのメソッドでやるの？
違うんじゃねえの？
権限管理のビジネスルールで可能で注文のビジネスルールで不可能、は、結局どのビジネスルールに縛られてるのか、もう少し種類増えたら優先順位が出てくるはずじゃん。
許可されてるから可能なのか、可能だから許可されてるのかって話。
今2つだから単純な話で済んでるけど。
○○の、と頭につけずに、ルールの積によって可能か不可能で判断するほうがいいんじゃないの？
言い方を変えよう。
注文のビジネスルールによる可/不可を「可能/不可能」と呼び
権限管理のビジネスルールによる可/不可を「許可/不許可」と呼ぶとしたとき、
「可能/不可能」と「許可/不許可」をごっちゃにしてはいけない。
> ルールの積によって可能か不可能で判断する
そのように説明したつもり。
> 今2つだから単純な話で済んでるけど。
増えたとしても、「それまでの判定結果」×「新しいルールによる結果」でしかないので、
組み合わせ爆発のような問題は起こらない。
> ○ その条件判定はどのオブジェクトのメソッドでやるの？
権限管理オブジェクト
> 権限管理オブジェクト
権限管理オブジェクトが、注文の情報に依存するってこと？
具体的に言えば、権限管理オブジェクトが注文オブジェクトの
チェックメソッドを読んでいるってこと？
> 今2つだから単純な話で済んでるけど。
そうなんだよね。
今は権限、特定のユーザーの情報だけで決まる話ばかりしてるけど、
他人の注文は取り消せないが、自分の注文だけは取り消せるみたいな
権限＋ビジネススールの組み合わせで判定することもあるわけだ
> 今は権限、特定のユーザーの情報だけで決まる話ばかりしてるけど、
> 他人の注文は取り消せないが、自分の注文だけは取り消せるみたいな
> 権限＋ビジネススールの組み合わせで判定することもあるわけだ
だからこそ、「可能/不可能」と「許可/不許可」はごっちゃに考えてはいけないと何度言ったら。
「可能/不可能」の実装は注文オブジェクトに、「許可/不許可」の実装は権限管理オブジェクトに、だ。
いや、カプセル化の考え方からすると、
権限管理オブジェクトの中で何やってるかは隠蔽されてるものなので
権限管理オブジェクトの中でビジネスロジックを呼んでいたとしても、
使う側からすれば、同じようにみえるわけですよ。
そもそも権限管理オブジェクトっていうのは名前が間違いで
一つの「権限＋ビジネスロジック」管理オブジェクトとするべきなのですよ。
そしてその中で権限管理オブジェクトやビジネスロジックオブジェクトによる
チェックをするべきでしょうね。場合によってはここでどちらとも関係ない
チェックが入るかもしれません。例えばメンテ中で閲覧しかできないみたいな。
話が見えてきましたね。
あなたは全てを「権限管理オブジェクト」にごっちゃにしてはいけないと言ってる。
私は「権限管理オブジェクト」にごっちゃにはしてない。
ただし「権限管理オブジェクト」やビジネスロジックやその他を扱うオブジェクトを
統括する別のオブジェクトを作って、そこでごっちゃにしろと言ってる。
何かの処理ができない時、その理由がなにであるかを
意識する必要が無いということです。
理由は関係なく、単純な できる？できない？で表せるので
条件を書くところが少なくなって、コードがシンプルになります。
public Rule (Order o, Kengen, k) {/*いつもの*/}
public cancel(){}
}
これでドヤ？
ワイが一番頭良いと思った
違う、ごっちゃにしたくてしてる訳ではない。
考えるのがめんどくさいからでも、混同してる訳でもない。
逆に、同じものに対する力の強さを、言葉を変えて別定義するのがおかしい。本質的には同じ物なんだから。
列挙するとまるで別のように見えるし、実際そういうシステム見たことあるが、闇が深すぎて設定だけで何人日かかるんだよこれってシステム。
力の強さにするか、ビットマスクにするか、列挙としてたくさんの積や和が可能な型とするかはおいといて、
それらは全部同じ結論の「可能/不可能」を表していて当然だと思う。
増えたとして、って、おかしいよ。今までの判定結果が、今回の判定結果と優先順位が違えば、増えた分全部再テストだよ。
システム整合性
在庫
オペレーター
みたいな3層のチェック条件に、負在庫を許すマネージャーなんて層を足したら、それは今までのシステム整合性→在庫→オペレーターの3層のチェックのどこにどう挟む気なの？
正しい。
レス番間違えてない？
ワイだろ
うまく揶揄して笑えるコード書いてたらレスするが、そのネタ何回目やねん
天丼にわろたるほど暇ちゃうぞ。
日本語でおｋ
>>421で最初に言って、>>647で重ねたように、俺もそいつがそいつだけで行えるチェックに関しては混ぜろとは言ってないんよね。
やかましわ
> 権限管理オブジェクトの中で何やってるかは隠蔽されてるものなので
同じように、注文オブジェクトの内部のビジネスルールは隠蔽すべきではないですか？
> あなたは全てを「権限管理オブジェクト」にごっちゃにしてはいけないと言ってる。
違います。
注文そのものに対するビジネスルールと、それ以外（たとえば権限によるルール）をごっちゃに
してはいけないと言っています。
> ただし「権限管理オブジェクト」やビジネスロジックやその他を扱うオブジェクトを
> 統括する別のオブジェクトを作って、そこでごっちゃにしろと言ってる。
注文オブジェクトには、一切のビジネスルールの実装をしないということですか？
それには同意できませんね。
>>822
> 本質的には同じ物なんだから。
いえ、違います。オブジェクトの責務の話です。
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通りです。
組み合わせ爆発は起きません。
プログラムもそのモデルを模倣すればよい
Ningenクラスを作ろう
Ningenクラスを継承して
EigyoやKeiriクラスを作ればよい
ドヤ？
組合せ爆発はどうあっても起こります。
重要なのは、テストするコストと価値を比べて
コストをかけてまでテストする価値はないという
コードにしてしまうことです。
テストしなくていい（する価値がない）コードが増えれば
テスト数の組合せ爆発を減らすことができます。
テストをしないためにはどうするかという話です。
> の4通りで済みます。
それはホワイトボックステストであることが前提となっています。
なぜなら、チェックしている順番が1,2,3の順であることを
知っているからです。
チェックしている順番が1,2,3であるならば、
4通りで済みますが、ブラックボックステストであれば
どの順番でチェックしているかわからないので、
そのテストの個数では足りません。
check1, check2, check3が直交してたらの話だよ
ここにさらに直交するcheckが増えても、組み合わせ爆発は起こらないことの説明
直行しているかどうかは
ブラックボックステストではわからない
要件が直交しているかどうかだよ。
・自分の注文しかキャンセルできない
・発送済みならキャンセルできない
これは直交した条件。
だから、ホワイトボックス・ブラックボックス関係なく、チェックの順番も関係なしに
・自分の発送されていない注文をキャンセルする
・自分の発送済みの注文をキャンセルする
・他人の注文をキャンセルする
というテストをすればいい。「他人の発想済みの注文をキャンセルする」テストは不要。
これが組み合わせ爆発が起こらない理由。
10個の条件があるときに、11個のテストでカバーできないようなコードを書くチームは、
もう何をしても無駄だと思うよ。
> というテストをすればいい。「他人の発想済みの注文をキャンセルする」テストは不要。
残念ながらそうとは限らないんだよね・・・
if (自分の注文か？) {
if (発送済みか？) {
return キャンセル可能
} else {
return キャンセル不可能
}
} else {
if (発送済みか？) {
return キャンセル不可能
} else {
return キャンセル可能 // バグ 本来はキャンセル不可能
}
}
これは「他人の発送済みの注文をキャンセルする」場合にバグが有るコード
自分も同じツッコミをしようとしたんだけど、視点によっては>>837も正しいなと気づいた。
システムテスト視点だと>>837で良い。
単体テスト視点だと>>840だよね。
「バグがないという前提において不要だと判断されたパターンはテストしなくて良い」
という考えは正しいかどうかって話だよな
ただ、システムレベルだと、禁則にあたる項目が多いのも事実で、そもそもテスト出来なかったりするじゃん？
その事を指して、テスト数爆発は無い、って言ってるのなら、まあわからなくもないかなと。
それは認識しないといけない。
爆発してしまうテストを現実時間でどう扱うかというと
テストしないという選択肢を選ぶしか無ない
重要なのはそのテストしないという理由で
「バグがないという前提において不要だと判断されたパターンだから」は
バグを見つけるのが目的のテストとしては、テストしない理由としては適切ではない。
俺の理由は「テストする価値がないぐらい単純なものだから」
テストしなくてもバグがないのは明らかなものを作る
だからそういうものはテストしない
途中returnして何が積なんだよ。
そうじゃなくて、この権限ならばできる、をあとから足せる構造にせなばって言ってる。
ちなみに、普通はそれは2*2*2のテストをする。
何故ならば、どちらも、影響しないという担保を行うために。
たまにあるからね。ポインタや参照先が同じとこ向いてる不具合とか。
要はテストケースはその四通りでは足りない。
お前実務経験無いんじゃねえの？
こういう思考で間違ったオブジェクト指向を流行らせようとしてる奴こそが、本来のオブジェクト指向をディスってるような気がするわ。
横から入った自分にも、その点に異論反論は無いよ。
その上で、禁則を増やしてテスト爆発を小さく抑えるってのは有効だと思うけど、その点にも同意できないの？
その禁則をコードにする時にバグがでるんだろうが
禁則ってのは、テスト不可能な条件のこと。
もちろんテスト不可能な条件とやらがバグってる
可能性も忘れずに答えてくれ
明らかに正しくないと思うよ。
思い込んで、そう動く事を意図して作ったものを、そう動くだろう、とテストする事は滅茶苦茶簡単だけど、
そう動く事を確認するなんて、そう動く事を意図して作ってるんだから当たり前の話。
意図せざる動きをしないかどうか、渡せるパラメータ全部渡して確認するのがテストだよ。
じゃあ>>840の例でいいかな。
例えば、このシステムのUIが、web系のGUIだとしたら、システムレベルだとGUI部品分の要素しかテスト出来ないじゃん？
そうすると、他人の注文にアクセス出来るのか？ってなるよね？
要件としてアクセス可能ならもちろんテストしなければならないけど、アクセス不可能ならテストしようがないでしょ。
これが禁則。
この場合、アクセス出来ないことを真っ先にテストしておけば、他人に対するテストは全部端折れる。（というか、やりようがない）
って話なんだけど、おかしい？
テスト出来ない状態、であるというテストは要るだろ。
そういう意味ではテストケースは減らん。
もちろん。
でも、テスト項目を消化する作業を一気に減らせる、って意味。
おかしい。
挙げたように、ポインタや参照が被ってるみたいな挙動を見つけられない。
ある事をするとあることが出来なくなる、という状態を持つのであれば、さらに、状態と入力条件を全てテストするしかない。
>>853
減らない。
波及範囲の推定はその方法では不可能。
えっ？
だって、テスト出来ないんだよ？
むしろ、単体レベルで爆発してるものを使うべきではない。
モジュール化できてない事の証左でしかない。
なら、最初からクラス分けろ。
いや、その話がすでに単体テストの話だよね？
話が噛み合ってない気がするんだけど。。。
いや、総合試験の話。
禁則とか言葉で誤魔化さんと、素直に、単なるルールの優先順位と気づけよ。
それはゴッドクラスでしかない。
だから、クラスとか関係ないんだってば。
最終的なシステムレベルでのテストの話なんだけど。。。
うーん、噛み合ってないな。
総合試験を作るとき、網羅度はどうやって出すの？
それが本当にやらなくても、そのメソッド呼ばれようがない、という判定は誰がどうやるの？
そして、呼ばれなかった、という悪魔の証明をどう担保したいの？
そうだよね。
ごめん、自分が間違ってたよ。
想定された使い方をしている限り動く
変な使い方をしなければ動く
ことを保証するテストなんだな。
想定外の操作をして問題が起きたら
それは間違った使い方をしたユーザーの責任
バカで低脳で使われるだけのユーザごときが偉そうにするな
ゴマスリしか能の無い、ちょっとコミュ力がSEより高いだけでプログラム1行も書けない下級生物は
大人しくしてろゴミ
ID:sarQXHNa
ID:8lDGGI0L
はトラブルメーカー
言ってることは正しい
しかし、そんなことは当たり前すぎるので、更にその上の議論をしようとしている人間に対して、全く話を理解せず頭ごなしに罵倒
狭い世界でお山の大将気取ってるコーダータイプ
多分、自分は悪くない、頭の悪い周りが悪いと思いこんでいる
んで、お前の意見は？
人に難癖だけ付けて終わんなよ
そのシステムは扱いたくないなぁ
その上の議論を成り立たせるためには、その下の暗示されている条件を明示する必要がある。
そして事実、勘違いしてる奴が居た。
何かそれ以上あるの？
それに対して、俺のコミュニケーション能力の問題だと思うほうが問題だと思うが。
なぜ理解できないのか、とか思わないのかな。
867 名前：デフォルトの名無しさん[] 投稿日：2017/07/30(日) 02:54:09.22 ID:Vcbd8R0/
ひどいコミュ障の自演を見てるようだ
↓
870 名前：デフォルトの名無しさん[sage] 投稿日：2017/07/30(日) 10:22:01.39 ID:KXbv0POf [2/2]
>>867こいつが一番コミュ障でFA
↓
872 名前：あ[sage] 投稿日：2017/07/30(日) 13:06:56.26 ID:yy9Kp6PA [2/2]
それに対して、"俺の" コミュニケーション能力の問題だと思うほうが問題だと思うが。
さて問題です。"俺の" が指す俺とはどれのことでしょう？
>>874
何を言うとるかわからんが、870の指示代名詞が単数であることから、
>>867で挙げている二人ではなく、>>867自身を>>870は挙げていると捉えたが。
だから2レスにわけてんのに。
せめてコードで殴り合え
前からそれ疑問に思ってたんだけど、公式言語なんなの？
なんか、難癖に見せかけた、難癖つける為の前フリに見えるわ。
コードで殴り合えと言っても、多分理解及ばんだろ。コードのほうが。
十分殴り合えるだろう。
いい感じに振り回すと先端は音速超えるしな。
10年ちょい前に論文読んだけどクソ真面目にやってて面白かった。
ヒュンヒュンなってるのはコードの速度が
音速を超えたために発生したソニックブームだったんだな
Javaだよ
JavaがOOPerの実質公用語
Javaすら読めんゴミはそもそもOOPなんて語る資格も価値も無いから
無視してよい
そこまでは風切り音で、そっから手首を返したときに起こる破裂音だね。
牛追いムチを観測してソニックブームが起こってることを確認したって古い論文を出してきてものすごく真面目に検証、考察してた。
全然オブジェクト指向っぽいが、必ずしもオブジェクト指向ではないでしょ。
Objectから綺麗に出てきてない型も居れば、演算子も定義できず、プロパティも持てないし。
べき論はおいといて、ダイヤモンド継承も出来ない、実装を持つインターフェイスも書けない、ただJVMってスタックマシンで動く物を作るための言語じゃん。
ダイヤモンド継承はそれが出来るからって自慢するもんじゃないだろう
ぜひ
見せて見ろ
カス
はよ！
師ね
見せて！
べき論はおいとくって言ってんのに何言ってんだよ。
まぁ、出来ると便利よ。
デフォルトメソッドで菱形継承はできるだろ
現状でJavaの最大の問題のひとつは高階ジェネリックが無い（型クラス相当が実現できない）ことだよ
> 全然オブジェクト指向っぽいが、必ずしもオブジェクト指向ではないでしょ。
こういうのがわけわからんって言われてるんだ
> Objectから綺麗に出てきてない型も居れば、演算子も定義できず、プロパティも持てないし。
> べき論はおいといて、ダイヤモンド継承も出来ない、実装を持つインターフェイスも書けない、ただJVMってスタックマシンで動く物を作るための言語じゃん。
このスレで語られるレベルのことは、Javaで表現できるだろ
デフォルトメソッド同時喧嘩するじゃん？再定義してやらないとならん。
呼ぶ方が決めたいとか思う。
形クラスが無いのと、あと、インライン展開無いのは痛いと思う。
今はあんのかな？
>>898
だから何なんだ。
片手落ちで、このスレで語られてるレベルの事はと後付されても。
未来永劫このスレではjavaの限界超えないみたいじゃん。
訳わかってないのはお前の理解力足らんだけだろ。普通にレス返せてる奴が居てどの口が言ってんの？
これは・・・
全然関係ないことで300レス消費した理由がはっきりしたわ
「Javaにデフォルトメソッドがあるなんて今まで知りませんでした無知な発言>>885を許してください」でおｋ
知っとるよ。しつこいな。
>>902
暇なときは暇よ。
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
一応ここはプログラミング板なんだけどな
だからこそ>>887には期待してる
(obj1, obj2, obj3) . method ( obj4, obj5, obj6 );
どうだ！
それの意味は？
引数obj4,obj5,obj6で
methodを呼び出す
すまん
それはどんな動きをするんだい？と聞いたつもりだった
俺の知識不足で申し訳ないんだがその書き方は見たこと無い
そのうちの一つの引数だけを特別扱いしてレシーバーとするのは
理屈の上では不自然なのでは？と考えただけ
http://nyamtech.blogspot.jp/2012/06/clojure_29.html
https://japan-clojurians.github.io/clojure-site-ja/reference/multimethods
メンテ性ゴミ
ブレファ並のギャグ
期待外れ
帰っていいよ
これはシングルディスパッチのOOPが悪いとかそういうことではなくね
OO以前はもっぱら関数を中心軸にして考えていたのを
第一引数を中心軸にして考えるとどうなるかっていう
そのときの適切な設計とその手法はどうなのか
ってことだから
ただしあまり深入りしたくないのは、第一引数を中心に考えるってのが
割と経験則みたいなところがあって、必ずしもいつも適切かどうかは分からん
だからOOP万能ってことにはならないし、やはり銀の弾などないってありきたりな結論なわけだが
その意味で「本物のオブジェクト指向」ってのはかなり笑える表現だと思う
「本物のオブジェクト指向」とやらがあったとして、それが使いやすいかどうかは別問題っていう
まぁそういうことが言いたいのではないかね>>887は
それか全く何も考えてないか
OO原理主義みたいな人が書いたプログラムは読みにくいって相場は決まってるしな
ちなみに俺は>>887ではないよ
複数ある関数の引数はどれも同じ重みで扱われることになるから
むしろOO以前の考え方に先祖返りすることになる
第一引数だけを特別扱いしてそれを軸足にして考える
ってのがOOの独特の世界観なわけで、全部の引数を等しく扱うなら・・・
第一引数だけを特別扱いしたときに経験的に上手くいくことが多いけど
そのやり方がどの範囲まで通用するかの実験みたいなもんだと思っとけば良いんじゃね？
無理やりにでもそうするやつと、初めから割り切ってるやつと、2パターン居るよね
え？ちがうの？
じゃあまだ>>887への期待は捨てなくていいの？
でもお前はもういらない
姿慎めよ
アラン・ケイのメッセージングのオブジェクト指向は、設計・実装・実行・運用・保守とあらゆる局面における
「遅延結合」（…という表現だと実行時のみにひっぱられる人がいるので「決定の遅延」の方がベターか）を
メッセージングというお題目を通じて実践・徹底・サポートするアイデア
http://d.hatena.ne.jp/katzchang/20080807/p2
http://metatoys.org/oxymoron/oxymoron.html
いろいろやり残した事はあるけど、ケイも興味を失っているし、このアイデアを試す実験自体、彼がSqueakを離れた時点で終了している
一方でC++発の抽象データ型のオブジェクト指向は、例えば型推論や型クラスといった関数型のコミュニティ発の優れたアイデアを
取り入れた賢い型システムを構築してどんどん進化していて、「本物」を語るならむしろこっちをちゃんと勉強して突き詰めた方がいい
長くなったけど伝えたいことは一つだけ。
“「本物」のオブジェクト指向を知りたいなら、「メッセージ」のことはもう忘れろ”
あ、うん、それは書いたな。ごめん。
>>917
本物じゃなくて良いとは思うけど、何より型って話をしだすと長い割に、最終的には扱う側の問題だなって思うよ。
いわゆる「Javaで言うオブジェクト指向」とかその辺に行き過ぎるのも微妙かと。
定義したあと変化する変数なんか要らなかったんだ、すべての源は原始再帰関数だみたいな話とか、Forthみたいな、手続きとスタックがあればそれで良かったんだみたいな話も、今更見直されてるし。
>>918
自覚としては薄い。
あ、うんって、お前、記憶ガイジなん？
さながらチューリングの泥沼にはまって身動きとれなくなったロートルだな
同じこと何回も繰り返すやつ程度には。
>>921
機械がチューリングマシンで動いてる限り仕方ないよ。
今更オペアンプみたいなアナログコンピュータやら、メカニカルな物理計算機使うわけにもいかん。
乱数コプロとかDSPを数珠つなぎにするならそれも良いと思うし、全部マイクロカーネルに乗せてそいつらには目をつぶってシステムはそのイベントシステムで組むのなら、関数型とかアクターモデルを真に名乗っていいと思うけど。
そんな機械がこの世のいったいどこにあるんかね
もしかしてチューリングマシン自体がオブジェクト指向とおなじ程度に抽象化産物ってことわかっとらん人？
さもなくば定式化されてないアイデアはこの世に存在しないも同然とか考えてる数理科学系気取ったバカ？
やっぱり日本語不自由だから理解できてないんだな、文脈
宗教戦争みたいなものだよ
で、ここはその戦場だからガンガン話題出して下さいな
うーん。オペアンプでのアナログ計算機も見てるし、ハーバードアーキテクチャのMPUも見るし、それらの機械はチューリング完全とは言えない場合が多いから、
逆説的にチューリングマシンであるとみなせるものに対しては、既に抽象化されていると思う。
その上で、何指向で書くかは実装者次第だって話。
何指向で書いても言語の限界はあるんだし、最終的にcould not be writtenなんてメッセージ出す時点でメモリを意識しないことは不可能なんだから、やるなら少なくともMFC一切使わない、libc一切使わない言語で語るべきなのかなと。
望む答えが返ってこないからって相手をけなしてるようじゃ進まない
通じないと思うなら理解しようと歩み寄らなきゃ
双方通じる程度に近付いたところで足を止めて激しく殴り合えばいい
何事にも限度ってもんがある
一度や二度の話じゃないからなこいつ
他者の不勉強を罵倒して悦にいるのが目的でここにいるので
議論はおろかコミュニケーションをとる試みすら時間の無駄
Javaのインターフェースに対する認識不足とそれに対する指摘のやりとりを追えば明らかなように
たとえ知識の古さやそれに伴う主張の欠陥を指摘されたとしても
しらばっくれたり話題を関係ない方向に持っていって誤魔化す事を常としているみたいだから
議論を正常に進めるための歩み寄りやすり合わせなんて現実からはほど遠いよ
ひけらかし、とか好きだなぁお前ら。
どう考えても筋が悪いことを筋が悪いと言うと「あいつはわかってねえ」「時間の無駄」とか言って話自体を聞こえない話だから聞くだけ無駄、とかポリに注意されて10mぐらい離れるDQNと精神性全く同じじゃん。
言っても無駄でしょ対話する気ゼロだもの
はっきりいってスレ汚すだけだし消えて欲しいんだけど
あ はちゃんと会話してる
あ と価値観の違うヤツが勝手にさばいてるだけ
あ はそれがズレてようが明後日の方向向いてようが、何でもいいからとにかく反論して自分の主張を押し通したい
そういう幼稚な欲求だけしかない
それは対話とは言わない
だからってこちらまで幼稚に返してたらどうしようもない
このスレは言語関係なくアルゴリズムや設計がメイン
言語に対する知識は古いなら古い中で培ってきた経験を弾かず新しい知識を持ったヤツが糧にすればいいと思う
あんたも分からん人だな同じ穴の狢？
罠だよ、罠
「イチゴ味であるところのヨーグルトにおいては
どう考えても美味いのであるからして美味しいと言う」
みたいな感じで名詞中心、物中心、の文章になってて流れが悪い
もっと流れるように滑らかな制御構造の文章じゃないと
「あ、オタクだな」って一瞬でバレる
なんとなくそれとなく
物物物物物物名詞名詞名詞名詞名詞の物量で会話しようとするから
何言ってるか分かんね、誰か翻訳して、って言われるやつ
ただ、何故か、オタ同士だと通じるんだよな、思考回路が似ているのかね
俺はライターでも何でもないからよく知らないが
ひらくってテクニックがあるらしいよ
漢字ばかりだと物感が強まって、物物物物な文章になるから
適当にひらがなにするらしい
特に関係や動作や様子の部分をひらがなにするらしいよ
認めることは認めとるぞ。
ただ、一部の人間が、自分の理解できる範囲を超えてるから、それが認めてるか理解でないだけでしょ。
>>942,943
モノ中心だよ。当たり前じゃん。
定義されてない物を会話しようとする方がおかしいから、定義してってるだけじゃない？
それに、開いてる単語と開いてない単語は使い分けてるけどね。
開くのはルールがある。だいたい業界ルールだろうけど。
補助動詞は開く、とか。
品証の時にマニュアル書いたこともあるけど。
むしろ、「もって」、は「以って」、「もっとも」は「尤も」と閉じにかかってたよ。実務では。
2つ以上に読めそうなものは漢字使うのは大原則では？
2つ以上の意味に読めそう、でないとおかしいか。
>定義されてない物を会話しようとする方がおかしいから、定義してってるだけじゃない？
あ～それで一人浮いてりゃ世話ないな
納得
これで浮くって発想も極端だがな
すまんのか？
うん。
オブジェクト指向、なんだから、アクターでもメソッドでもデータのエンティティでも、オブジェクト指向として、オブジェクトが中心になるのは当たり前だとおもうんだけど。
その大前提を無視して、モデルかとはそうじゃない、これは全部こいつがやるべきだ、みたいなゴッドOrderクラスはおかしいじゃん？ってのが書き込みの発端。
オブジェクト指向はオブジェクトが中心なんじゃなく
メッセージイングが中心であって核心、本質、って言ってるよ
俺はアランケイは電波だと思うけどもこの部分は賛同する
アラン・ケイの言うメッセージングはお題目にして方便なので（そのような実装を妨げる物ではないけど）
本質は「決定や結合の遅延」の実践・徹底（と、それをシステムによりサポートすること）だよ
詳しくは>>917のリンク先をを読んでみて
少なくともオブジェクト指向“プログラミング”の主流は、ケイのメッセージングのそれよりは
長らくストラウストラップらの抽象データ型のオブジェクト指向の独擅場であり、さらに言えば
今世紀に入ってから作られた言語の型システムも急速に整備されてきている
ケイがSmalltalkでの実験を通じて目指した究極の動的性を必要とするならともかく
そこいらの普通の動的型言語が持っているダックタイピング程度の柔軟性でいいなら
最近の静的言語なら大抵対応できるので、いずれにせよメッセージングのことは忘れていいと思うよ
「メッセージがアレなんだぜ知らんけど」
とかもうね馬鹿かとアホかと
おまえ今までずっとマンマのおっぱいでも吸ってたんかボケ？
> その大前提を無視して、モデルかとはそうじゃない、これは全部こいつがやるべきだ、みたいなゴッドOrderクラスはおかしいじゃん？ってのが書き込みの発端。
全部そいつがやれなんてことは誰も言ってなかったと思うが
最初から、オーダーに関するビジネスロジックと権限などによる制限はわけろって論調だったわけで
流れが追加されてるのを忘れないように
そんな流れあったか？
え？
そんなバカなこと言ってたのは名前を言ってはいけないあの人しかいないと思うが？
http://cjjc.weblio.jp/content/%E5%90%8C%E4%B8%80%E7%9A%84
中国人か？
とういつてき
の間違いだよ
中国語？詳しそうだね
ニーハオファッキュー
統一的に扱えなんて流れあったか？
> 書き込みの発端
のレス番書いてくれよ
>>412
ビジネスロジックはModelには実装しないだろといいだした奴が元凶
ViewModel InputModel DocumentModel DomainModel ServiceModel DataModel...
ロジックの集合体みたいなものから振る舞いを持たないDTOまでなんでもあり
オブジェクト指向を知ってるプログラマだと
、ビジネスロジックと言えば主にDomainModelなのでModelはビジネスロジックを持つ、となる
手続き型から脱却できていない人にとっては、ModelとはなんらかのDTOつまりただのデータ集合のことだからModelはビジネスロジックを持たない、ロジックはトランザクションスクリプトに書くものだ、となる
このスレの人間はオブジェクト指向信者が多いが、あの人を代表に敬虔な手続き型信者も紛れ込んでいる
え？
オブジェクト指向っていうのは構造なんで
処理は別にあるんだよ。
処理は手続き型 or 関数型の二種類が多く使われてる
オブジェクト指向 ＋ （手続き型 or 関数型）で
プログラミングするのが今の主流
> 手続き型プログラミングでは、プログラミングはデータ構造とルーチンの集合に分割される。
> 一方オブジェクト指向プログラミングでは、プログラミングはオブジェクトに分割される。
https://ja.wikipedia.org/wiki/%E6%89%8B%E7%B6%9A%E3%81%8D%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
その中の、「メソッド」まで見てみた？
あるクラスまたはオブジェクトに存在するサブルーチン、とあって、手続き的な指向までは排斥されてないよ。
お前とは会話できんわ
自分はアホですって自己紹介していたようなものって事だな
だってこういう場合、普通は手続きって言葉は使わない
パラダイムの世代を表したいなら「構造化言語」って言葉を使うのが普通だ
手続きって言った場合は、関数型に対する手続き型の意味合いがあるからな
アホみたいな発言を繰り返してしまうってのもあるだろうな
メソッドを呼びあって相互作用する「手続き」を「プログラム」する
ってのが分かってない
OOPだろうが結局バグを生まないために一番大事なのが「処理の順番を守ること」である以上
手続き型としか言いようがない
メソッド呼び出しの順番やタイミングを誤ったことをコンパイル時に知らせてくれる
な～んて事は無いので
結局手続き型の、手続きを守らなければならないという
一番の弱点が残っている以上はOOPも手続き型に違いないわけだ
呼び出してはいけないタイミングでメソッドが呼び出されたらどうする？
って話につながる、というか、戻る
副作用があって処理の順番にプログラムの結果が依存する
手続き型一般にありがちな問題といえる
これを言語仕様で克服できてないということは
JavaもC#もC++も手続き型ということ
手続き型の欠点をそのまま受け継いでいるから
欠点を受け継いでいる以上は無視できない
順番やタイミングといった動的なものを
コンパイルという静的な視点でエラーにするパラダイムがあるの?
コンストラクタとかあるタイミングで何かを保証するルールならわかるけど
無いから「手続き型」だと言ってる
欠点をそのまま受け継いでいるから
ただ、順番やタイミングから逃れられる方式もあって、それが関数型なわけだけど
逆にそれが出来る関数型が存在しているからこそ
順番やタイミングに依存する方式は、より一層、手続き型臭いといえるわけだ
その関数型の実装例を教えて下さい
意図的に排除する仕組みが言語仕様で用意されているといったほうがいいな
関数型って宗教だったんだ
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 395日 14時間 15分 19秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 岸田総理「誰ひとり取り残さない社会」実現へ [煮卵★]
- 【滋賀】いなり寿司を万引きしたとして誤認逮捕され、82時間拘束された女性、涙ながらに苦しい胸の内を明かす… ★4 [Hitzeschleier★]
- 【ドジャース】山本由伸、メジャー最長6回99球も4失点で降板...打線は大谷翔平のタイムリーなどから6回同点に追いつく [フォーエバー★]
- 【世帯年収2000万円以上の富裕層】「よく身に着ける洋服のブランド」…ダントツ1位は「ユニクロ」 [ネギうどん★]
- 慶應義塾長が国立大の学費増額を提言「年55万→150万に」 文科省の会合で ★2 [少考さん★]
- “消えない広告” ×マークが押せません!? 「ダークパターン」世界で問題に | NHK [少考さん★]
- NYM @ LAD ★7
- NYM @ LAD ★6
- NYM @ LAD ★854
- 【フジテレビ】2024 FORMULA 1【NEXT】Lap271
- 【フジテレビ】2024 FORMULA 1【NEXT】Lap270
- 【DAZN】フォーミュラ 【F1 F2 F3 P】lap1431
- ウニ好きなやつって頭おかしいよな
- 【速報】米、イクラに対して多数で攻め込む
- 猫に抱きついて全身にキスしたい
- 教習所の実技教習1回目でエンスト2回ってどんなもん？
- 【画像】妹がお前と2人で遊びに行くときにオシャレしてたらどうする？
- 【悲報】僕、ニュー速＋のクルド人スレでクルド人差別に反対した結果、どんぐりを枯らされまくる [347334234]