板検索:
オブジェクト指向システムの設計 172 (695)
まとめビュー
1
uy ◆e6.oHu1j.o []   投稿日:2016/07/09 00:35:13  ID:Mn3UGZ+O.net
前スレ
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
オブジェクト指向システムの設計 171


2
デフォルトの名無しさん[sage]   投稿日:2016/07/09 00:40:05  ID:DRCwnEUQ.net
スレ立て乙

今回はどうなるものやら

3
デフォルトの名無しさん[sage]   投稿日:2016/07/09 02:21:37  ID:GFJ5/r//.net
今頃流行ってんだなOOP
10年くらい前は否定派のオッサンが多くてめっちゃ肩身狭かったけど
コメント2件

4
デフォルトの名無しさん[sage]   投稿日:2016/07/09 02:35:54  ID:3DBY5ZwO.net
>3
お前の会社は可哀想だなw

5
名無しさん@そうだ選挙に行こう! Go to vote![sage]   投稿日:2016/07/10 09:45:08  ID:uQXCaqsb.net
>3

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

ってことで、「OOP否定」の流れにくみする人が多かったということだったのかも?
コメント1件

6
デフォルトの名無しさん[sage]   投稿日:2016/07/11 19:21:45  ID:X0XbLs9u.net
C#でコーディングしてるんだけど、呼び出した1メソッドずつtry~catchで囲め、共通化メソッド内での分岐じゃ読みにくいって言われたんだけどそんなに読みにくいの?
3分岐ぐらいしかないんだけど
1メソッドずつコピペで囲んだらなんかあったとき修正漏れとかあると思うんだけど
俺がおかしいの?
throwするとわかりにくいって怒られるし。
コメント3件

7
デフォルトの名無しさん[sage]   投稿日:2016/07/11 21:38:01  ID:qc/cfS6K.net(6)
>6
実際のコードがないと何とも言えん気がするが

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

8
デフォルトの名無しさん[sage]   投稿日:2016/07/11 21:42:08  ID:5tv/61n2.net
C界隈出身の先輩が言う事は話半分で聞いてりゃいいよ。

9
デフォルトの名無しさん[sage]   投稿日:2016/07/11 21:50:23  ID:qc/cfS6K.net(6)
>5
むしろ10年前にOOP否定とか
他に何やってたんだ、そいつは?
最高に見通しのいい伝説の1ファイルmain()1万行とか書いてたのか?

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

10
デフォルトの名無しさん[sage]   投稿日:2016/07/11 21:53:10  ID:aTiidMol.net(8)
職場の人がみんなそうで、毎日変数一つにまとめろとかクラス一つにまとめろとかいろんな人から怒られたりして気が狂いそう
javaから入ってオブジェクト指向学んだんだけど、javaと同じようにオブジェクト指向で作っちゃいけないの?
戻り値列挙型で定義したら戻り値二択にしてboolで返せって、戻り値によってswitch文で処理書いてたんだけどそれも全部捨てろって
俺そんなにおかしいもの書いたのかな?
共通化したりするとわかりづらい読みづらいって言われる


11
デフォルトの名無しさん[sage]   投稿日:2016/07/11 21:55:32  ID:aTiidMol.net(8)
>7
共通化メソッドって言うのは例外処理のことね
例外処理一つにまとめたら例外ごとにメッセージ出せって言われたからメソッドこしらえたら分岐とか読み辛いからやめろって
読みやすいように考えたのに、そんなダメだったかな。
コメント1件

12
デフォルトの名無しさん[sage]   投稿日:2016/07/11 22:01:49  ID:dAMIv9Pn.net(2)
>11
簡単にでいいから書いてみ↓
https://ideone.com/
コメント1件

13
デフォルトの名無しさん[]   投稿日:2016/07/11 22:09:20  ID:aTiidMol.net(8)
>12
書いたらrunて押せばいいの?
コメント1件

14
デフォルトの名無しさん[sage]   投稿日:2016/07/11 22:13:53  ID:dAMIv9Pn.net(2)
>13
Runでok
Runして表示されるページのアドレスをここに書き込めば、みんなが見れる

15
デフォルトの名無しさん[]   投稿日:2016/07/11 22:21:48  ID:aTiidMol.net(8)

16
デフォルトの名無しさん[]   投稿日:2016/07/11 22:23:16  ID:aTiidMol.net(8)
変なのだったらごめん。
あとクラス名間違えてるごめん。

17
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:27:03  ID:qc/cfS6K.net(6)
>15
わかりにくい(怒)

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するの?

おまえ向いてないよ
コメント4件

18
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:30:23  ID:qc/cfS6K.net(6)
レビューは的確に
誤解がないよう断定調で書く
反省を促すためにも積極的に人格否定などを織り込む
これ良いレビューの基本ね

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

19
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:33:42  ID:MJsMJlaT.net
>6
なんとも言えんなー
ぶっちゃけまるっとtry-catchで括っちゃうと不味い場面のが多い気がする
今の職場では「ハイ例外ハイ死んだーエラーログ出てるからオッケー」
なんてノリだけどな
途中で死んで処理切り上げて抜けました後片付けは知りません
落ちて死んだりもしたけれどアプリケーションは元気です!
ってそれ不良品じゃねーか!
って気がしなくもない
DB関連の処理ならロールバックあるけど
やっぱ真面目に作ろうとすると昔ながらのc言語スタイルかなと
コメント2件

20
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:36:48  ID:aTiidMol.net(8)
>17
返信ありがとう
createメソッドとかcopyメソッドとかが出現する場所全部に入れないといけないからそういう風にしてる
throwはするなって言われたからキャッチした場所でメッセージ出力して、場合によっては戻り値返してる
こうしたくてこうしたいんじゃないけど、現状非難は浴びてるから向いてないのかもしれない

21
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:37:44  ID:qc/cfS6K.net(6)
        .______
.        |    |    |
     ∩∩  |     |    |  ∩∩
     | | | |  |    |    |  | | | |  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    (  ,,)  |     |    | (・x・ )<おらっ!出てこい、 ID:aTiidMol
   /  つ━━"....ロ|ロ   . | l   |U \___________
 〜(  /   |    |    |⊂_ |〜
   し'∪  └──┴──┘  ∪

俺様が貴重な時間割いてレビューして下さったんだぞ?
涙の一つくらい流して感謝の言葉でも述べたらどうだ
お礼は三行以上
ついでに糞コード書いてごめんなさい、産まれてきてごめんなさいも言え、このビチグソが
こういう勘違いしたバカがリーダブルコード読んで利いたふうな口をきくからコードが糞臭くなるんだよ
PHPからやり直せ

22
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:39:31  ID:qc/cfS6K.net(6)
俺が悪かった
薬飲んで寝るよ
コメント1件

23
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:41:00  ID:aTiidMol.net(8)
>22
ちゃんと意見言ってくれただけでもありがたいよ。
薬飲んでるのか?
体は大事にな。
ゆっくり休んでな。
コメント1件

24
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:45:26  ID:jK3rCQ1d.net
精神不安定杉内
やっぱIT業界って頭やられちまう奴多いんだなw

25
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:48:51  ID:aTiidMol.net(8)
>19
そこまで複雑な処理じゃないんだ。
最初は下位で何かあったら共通処理から上がってきて、メソッド毎に○○処理中に〜みたいなメッセージ出力してまた投げて、メインで例外処理するだけのものだったんだけど、それじゃだめだって言われて
例外発生タイミングで例外処理しろって、投げるなって
じゃあチェック処理含めてcreateメソッド囲った共通処理作ってその中でメッセージ出力したらどうだって言ったら
ややこしいからコピペで一回一回囲めって言われたんだ
伝わるかな?

26
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:58:21  ID:EacXB/Ox.net
>23
ちなみにそういう時は、コードを2つ並べて書くものだ。
A. 俺はこう書いたんだが、
B. こう書けといわれて戸惑ってる
みたいに。どちらかは丸ごとコメントアウトしておけばいい。
>15がAで、>17がBであっているのか?

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

27
デフォルトの名無しさん[sage]   投稿日:2016/07/11 23:59:14  ID:c813o9It.net
>19
> やっぱ真面目に作ろうとすると昔ながらのc言語スタイルかなと
それはない。
C言語スタイルでは大規模アプリの例外処理は
大変すぎて手に負えなくなる。
コメント1件

28
デフォルトの名無しさん[sage]   投稿日:2016/07/12 00:14:23  ID:92wyFONm.net
using使え

29
デフォルトの名無しさん[sage]   投稿日:2016/07/12 00:18:40  ID:StomlD/Y.net(4)
C言語スタイルってなんぞ?

30
デフォルトの名無しさん[sage]   投稿日:2016/07/12 00:42:17  ID:M/oXbOZH.net(4)
>27
いやいや
だって例外を1番上で捕まえると
死ぬ箇所によって死に方が千差万別よ

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

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

31
デフォルトの名無しさん[sage]   投稿日:2016/07/12 00:45:40  ID:StomlD/Y.net(4)
Cって例外ないじゃん
C++は既にJavaに似た例外あるじゃん

C言語スタイルってなんじゃん?
コメント1件

32
デフォルトの名無しさん[sage]   投稿日:2016/07/12 00:48:43  ID:M/oXbOZH.net(4)
>31
だから例外ないからその場で処理するしかないだろ
コメント1件

33
デフォルトの名無しさん[sage]   投稿日:2016/07/12 00:49:55  ID:StomlD/Y.net(4)
健全でない言葉が含まれているため表示しません 内容を確認する

34
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:02:14  ID:4M8hLvVe.net(12)
>30
> だって例外を1番上で捕まえると
> 死ぬ箇所によって死に方が千差万別よ

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

困らないときがほとんどなんだから
困るときだけ対処すればよい。
コメント1件

35
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:03:49  ID:4M8hLvVe.net(12)
C言語よりもあとにできた言語では
ほぼ全て例外機構があって、例外を使うのが推奨されている。
(例外を使うなって意見聞いたことあるか?)

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

36
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:09:39  ID:umCvEWis.net(5)
>35
釣りか?
むしろ使うなという方が大勢だと思うが。
http://www.textdrop.net/google-styleguide-ja/cppguide.xml#%E4%BE%8B%E5%A4%96
コメント2件

37
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:11:50  ID:Vf+ZIi05.net(2)
C言語の例外処理はシグナルを使う方法だろ

38
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:17:32  ID:rBak2gB5.net(3)
>36
Googleは例外が使われていない大量のレガシーコードを抱えている
そのレガシーコードと例外を扱う今風のコードを混ぜることにコストがかかるから例外を使わないというルールになっている
新規にコードを書くなら例外でエラーするのが一般的

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

39
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:36:55  ID:4M8hLvVe.net(12)
>36
Googleは特殊な事例があるからってだけだなw

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

40
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:37:15  ID:M/oXbOZH.net(4)
>34
会社でどっちに倒すか?
ってなったら俺ならその場で対処だな

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

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

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

まあ、概ね大丈夫ってのはわかるけどね
コメント1件

41
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:38:38  ID:M/oXbOZH.net(4)
文中の例えばは間違い

42
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:38:41  ID:4M8hLvVe.net(12)
>40
> 例外大ジャンプは取り返しが
だからさ、例外小ジャンプすればいいだけだろ

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

43
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:45:58  ID:4M8hLvVe.net(12)
プログラミングやってて時たまいるんだが、
視野が狭いっていうか、何かをやれって言ったら、
それだけしかやらないやつな。

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

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

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

44
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:48:36  ID:umCvEWis.net(5)
>38
そこは俺も読んでるよ。
しかし俺は逆に「例外を使え」ってのを聞いたことないんだが、
日曜コードではなくて、マジの商用コードでそういう方針の所ってあるか?
コメント1件

45
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:55:35  ID:4M8hLvVe.net(12)
> しかし俺は逆に「例外を使え」ってのを聞いたことないんだが、

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

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

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

46
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:58:01  ID:4M8hLvVe.net(12)
まああれだ。C言語のしがらみがないライブラリで
例外を使っていないライブラリありますか?
という質問に答えてみればいい。

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

47
デフォルトの名無しさん[sage]   投稿日:2016/07/12 01:59:34  ID:rBak2gB5.net(3)
>43
エラーと例外の処理 (Modern C++)
https://msdn.microsoft.com/ja-jp/library/hh279678.aspx

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

48
デフォルトの名無しさん[sage]   投稿日:2016/07/12 02:01:08  ID:rBak2gB5.net(3)
ごめん、まちがえた
>47>44

49
デフォルトの名無しさん[sage]   投稿日:2016/07/12 02:01:24  ID:4M8hLvVe.net(12)
>47
レスする相手は俺じゃないだろw

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

50
デフォルトの名無しさん[sage]   投稿日:2016/07/12 02:21:04  ID:umCvEWis.net(5)
>47,48
情報ありがとう。頭だけざっくり読んだけど、詳細検討には時間がかかりそうだ。
googleのコーディングガイドでしれっと最後に
> Windowsのコードについては、このルールは例外です(シャレでなく)。
とあるのだが、Windowsで閉じている場合は環境が整備されているから
googleみたいな運用方法でも障害にはならないということなのかな?

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

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

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

51
デフォルトの名無しさん[sage]   投稿日:2016/07/12 02:28:01  ID:SKMsT/RZ.net
>6
tryで囲む領域が大きくなると、どこでエラーが起きたか、わかりにくい

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

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

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

52
デフォルトの名無しさん[sage]   投稿日:2016/07/12 02:33:58  ID:4M8hLvVe.net(12)
>50
そんな小さい処理で同じとか言われてもな。

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

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

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

53
デフォルトの名無しさん[sage]   投稿日:2016/07/12 02:36:15  ID:4M8hLvVe.net(12)
> throwはややこしい。
> 一々、これは内側、これは外側の関数で処理するとか、変わるのはややこしい

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

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

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

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

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

54
デフォルトの名無しさん[sage]   投稿日:2016/07/12 03:23:53  ID:umCvEWis.net(5)
>47,48
だいぶ読んだ。

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

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

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

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

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

55
デフォルトの名無しさん[sage]   投稿日:2016/07/12 04:39:01  ID:Vf+ZIi05.net(2)
Googleのスタイルガイドを読む限り、Windowsのコードの場合は独自性ガ強くて
どうにもならんところが多いからコーディング規則を逸脱しても仕方がないって感じだな
コメント1件

56
デフォルトの名無しさん[sage]   投稿日:2016/07/12 06:14:29  ID:4M8hLvVe.net(12)
>54
あんたが例外を使ったことがないから
例外がすごく使いやすいってことを知らないだけ。
何かと理由をつけて使いづらいってことにしたがってるだけだな。

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

57
デフォルトの名無しさん[sage]   投稿日:2016/07/12 06:16:12  ID:4M8hLvVe.net(12)
例えばC言語方式だと、
printfの戻り値までチェックしないといけない。

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

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

58
デフォルトの名無しさん[sage]   投稿日:2016/07/12 08:53:57  ID:3JVrmQRs.net
例外を「例外」だと思わないマが多すぎる
とくにJavaから来た人

59
デフォルトの名無しさん[sage]   投稿日:2016/07/12 10:05:30  ID:KWfKXhYB.net
ところでOOPと関係ある?

60
デフォルトの名無しさん[]   投稿日:2016/07/12 10:09:09  ID:3O9ex62E.net(2)
例外よりeitherの方が使いやすいよ
型安全だし
コメント2件

61
デフォルトの名無しさん[sage]   投稿日:2016/07/12 10:09:59  ID:ddtK31Ex.net
ここはOOだけやってんだろ?Pはスレ違いだしな。

62
デフォルトの名無しさん[]   投稿日:2016/07/12 10:10:01  ID:3O9ex62E.net(2)
例外よりeitherの方が使いやすいよ
型安全だし

63
デフォルトの名無しさん[sage]   投稿日:2016/07/12 11:43:29  ID:K7Zjf19C.net
>17はずれてるだろ

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

64
デフォルトの名無しさん[]   投稿日:2016/07/12 20:39:39  ID:cQbnp1H7.net(2)
>63
意図を汲んでくれてありがとう

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

66
デフォルトの名無しさん[sage]   投稿日:2016/07/12 22:51:05  ID:StomlD/Y.net(4)
う〜ん、PG歴2年目くらい?
コードをたくさん書きたいお年頃的な
なんつーかクドい

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

>予期せぬ値って何?想定があるの?必要?(笑)
同じ感想でワロタ
コメント2件

67
デフォルトの名無しさん[sage]   投稿日:2016/07/12 22:57:14  ID:aSzJV8SF.net
普通に書け
普通に
オリジナリティなんていらねえんだよゴミが

68
デフォルトの名無しさん[sage]   投稿日:2016/07/12 23:25:13  ID:umCvEWis.net(5)
>55
最後の「ルールの例外」からするとそんな感じだな。
夜はそこまで読んでなかったわ。

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

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

69
デフォルトの名無しさん[sage]   投稿日:2016/07/12 23:28:42  ID:VAaNpcds.net
>66
初心者であるとかお年頃であるとか
そーいうのじゃない可能性もあるな

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

70
デフォルトの名無しさん[sage]   投稿日:2016/07/13 00:20:45  ID:7t1kL6eB.net(2)
>68
Eiffelみたいな契約プログラミングによる保証か、
https://ja.wikipedia.org/wiki/契約プログラミング
もしくは、
C++11のnoexceptのような仕組みかな
http://cpprefjp.github.io/lang/cpp11/noexcept.html
コメント1件

71
デフォルトの名無しさん[sage]   投稿日:2016/07/13 00:26:34  ID:C7S+nyqs.net(2)
noexceptでヌルポったらどうなるん?
コメント1件

72
デフォルトの名無しさん[sage]   投稿日:2016/07/13 00:44:09  ID:yKl3ljrD.net
>68
>60のはHaskellのEitherモナドのことを言っていると思われ
http://itpro.nikkeibp.co.jp/article/COLUMN/20090210/324443/
一応、C++やC#でそれっぽいコードを書いている人はいるみたいだが……

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

73
デフォルトの名無しさん[]   投稿日:2016/07/13 00:48:21  ID:wcqcmuYS.net
>66
共通の例外処理を繰り返したくないと書かれてるじゃん
読解力がない上に自分の意見を押し付けるってさあ…

74
デフォルトの名無しさん[sage]   投稿日:2016/07/13 00:49:32  ID:uq0wU9fp.net(6)
>65
おー書いたか、ご苦労さん。
俺が想定したものとは異なるが、それ以上に情報を含んでいたので、
レビューの様子もよく伝わったぜ。

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

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

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

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

75
デフォルトの名無しさん[sage]   投稿日:2016/07/13 00:50:08  ID:uq0wU9fp.net(6)
多分勘違いしているのだと思うし、実際そういう奴も多い気もするが、
ベタに書くのが悪いとか、同じようなコードが2箇所に出現するのが悪いとか、
そういう単純な問題ではないんだ。
分かりやすく言えば、
「そのコードを初めて渡されて、ああこのコードはちゃんと動くだろうねと分かるまでに、何秒かかるか」
について最適化しろということなんだよ。
当たり前だが全く同じ内容がダブってたら読むのに2倍かかるから、
それはループなり多態なりして一つに減らせってことになる。
だけど無理に多態したりして「コードを追う手間」が増えるようでは駄目なんだ。

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

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

76
デフォルトの名無しさん[sage]   投稿日:2016/07/13 00:53:31  ID:2JhFq5Nw.net(11)
>65
まずMain関数はこれだけだ。
これ以外不要。

public class Test {
 public static void Main() {
  try {
    CreateTempFile("targetPath");
    MaggageBox.Show("一時ファイルが作成されました");
  } catch(XXXException e) {
    MaggageBox.Show(e.Message);
  }
 }
}
コメント1件

77
デフォルトの名無しさん[sage]   投稿日:2016/07/13 00:59:57  ID:2JhFq5Nw.net(11)
CreateTempFileの中身はこうだな

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

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

78
デフォルトの名無しさん[sage]   投稿日:2016/07/13 01:03:40  ID:2JhFq5Nw.net(11)
結局のところこの程度であればMainに全部入れてもよい良い

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のようにシンプルのままでいられる。

79
デフォルトの名無しさん[]   投稿日:2016/07/13 01:19:00  ID:OE4fGXcq.net(3)
なにこのキモいスレw

80
デフォルトの名無しさん[sage]   投稿日:2016/07/13 02:08:26  ID:uq0wU9fp.net(6)
>70,72
情報ありがとう。

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

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

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

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

81
デフォルトの名無しさん[sage]   投稿日:2016/07/13 02:16:26  ID:2JhFq5Nw.net(11)
> 当然STLや自前クラスがどの例外保証を持っているかすべて把握してないと駄目だし、

例外保証ってなんや?

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

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

82
デフォルトの名無しさん[sage]   投稿日:2016/07/13 03:23:41  ID:vjGvgzcz.net
>65
ディレクトリを作れない時に、throwして外のスコープに飛ばすのは、ややこしい。
そこでエラー処理できる

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

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

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

83
デフォルトの名無しさん[sage]   投稿日:2016/07/13 06:01:23  ID:QAw5IbxT.net
>65
的確な指摘じゃない?
どうみても下の方が出来がいい

84
デフォルトの名無しさん[sage]   投稿日:2016/07/13 06:22:04  ID:7t1kL6eB.net(2)
>80
>契約プログラミング
C++だとBoost.Contract
.NetだとSystem.Diagnostics.Contracts
があるね
使ったことないけど

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

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

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

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

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

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

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

85
デフォルトの名無しさん[sage]   投稿日:2016/07/13 07:23:43  ID:L2fL/y00.net
おはようございます!
ご回答ありがとうごさいました。
そうかー難しいのか。
難しいということはたまに言われますが、なにが難しいのかわからなくていつも悩んでいるので、自分は設計には向いていないのかもしれません。
下流で頑張ります。
皆さんも今日一日頑張ってください!
それでは!

86
デフォルトの名無しさん[sage]   投稿日:2016/07/13 09:37:32  ID:2JhFq5Nw.net(11)
>84
> .Netにも例外を投げるInt32.Perseと投げないInt32.TryPersreの2種類があるし

名前が重要なんだよ。(ちなみにParseな)

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

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

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

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

87
デフォルトの名無しさん[]   投稿日:2016/07/13 19:05:13  ID:OE4fGXcq.net(3)
そんなに力説するほどの事か?w
コメント1件

88
デフォルトの名無しさん[sage]   投稿日:2016/07/13 21:38:19  ID:2JhFq5Nw.net(11)
>87
これは力説するほどのことだよ。
なぜなら可読性の話だから。

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

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

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

89
デフォルトの名無しさん[]   投稿日:2016/07/13 21:54:55  ID:OE4fGXcq.net(3)
それなら問うが
Parseが返すパーズした結果とは何ぞや?
TryParseが返すトライした結果とは何ぞや?
俺には名前だけではさっぱり分からんのだが
これがお前の望む適切な名前とはとても思えんのだがw
コメント2件

90
デフォルトの名無しさん[sage]   投稿日:2016/07/13 22:01:55  ID:lnUCd6s/.net
>89
友情努力勝利に決まってるだろ

91
デフォルトの名無しさん[sage]   投稿日:2016/07/13 22:31:57  ID:oLxbX2RO.net
正直TryParseで変換できちゃうのはちょっと気持ち悪い

92
デフォルトの名無しさん[sage]   投稿日:2016/07/13 22:44:01  ID:uq0wU9fp.net(6)
>84
例外をエラー通知として使う分にはその辺は知らなくていいんだよ。
ただ、例外で復旧させようとするのなら、その辺を全て把握する必要がある。
そして彼等はそれにも耐えられるようにSTLを整備しようとしている。
それは無駄なコストを発生するから、それについて彼等も議論しているわけだ。

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

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

93
デフォルトの名無しさん[sage]   投稿日:2016/07/13 22:44:36  ID:uq0wU9fp.net(6)
> 必要があれば戻り値のエラー通知を部分的に使うのはかまわないと思うよ
個人的にはTryParseをよく使っている。それで十分だから。
必要性はない。try/catchでも書ける。

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

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

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

94
デフォルトの名無しさん[sage]   投稿日:2016/07/13 22:45:05  ID:uq0wU9fp.net(6)
生Cはある意味世界がno-fail保証されている。
そして失敗した場合は上記のように自前で戻すか、諦めるしかない。単純な話だ。
ロールバックする気なら、この点については例外で処理した方がコード的には楽だ。
しかし実行効率ではどうやっても生Cの方が上になる。何もしてないコードだからだ。
生Cは世界が単純に出来ている。あまり気にしたことはないが、これは大きな利点だね。
言語がシンプルな結果、シンプルな記述を強要され、結果的に65のようなコードを記述出来ない。
65みたいな「考えすぎておかしくなっている奴」には生Cギプスが効くかもしれない。

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

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

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

95
デフォルトの名無しさん[sage]   投稿日:2016/07/13 22:58:10  ID:2JhFq5Nw.net(11)
>89
> Parseが返すパーズした結果とは何ぞや?

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

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

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

96
デフォルトの名無しさん[sage]   投稿日:2016/07/13 23:09:44  ID:jyyAd6hv.net(3)
Int32.Parse だからといって、必ずInt32が返るとは限らないだろ
おまえは、human.age()で必ずhumanが返ると考えるか?
コメント1件

97
デフォルトの名無しさん[sage]   投稿日:2016/07/13 23:11:23  ID:2JhFq5Nw.net(11)
>94
> なおJavaScriptは0割は無限大になるというお気楽仕様だ。

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

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

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

98
デフォルトの名無しさん[sage]   投稿日:2016/07/13 23:11:30  ID:jyyAd6hv.net(3)
いっとくが、human.age()で必ずintが返るとは限らないからな
もしかしたらageオブジェクトが返るかもしれないからな

99
デフォルトの名無しさん[sage]   投稿日:2016/07/13 23:12:49  ID:2JhFq5Nw.net(11)
>96
> Int32.Parse だからといって、必ずInt32が返るとは限らないだろ
> おまえは、human.age()で必ずhumanが返ると考えるか?

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

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

100
デフォルトの名無しさん[sage]   投稿日:2016/07/13 23:13:53  ID:jyyAd6hv.net(3)
>human.parseだったら、human返すんじゃねーの?

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

101
デフォルトの名無しさん[sage]   投稿日:2016/07/13 23:18:25  ID:2JhFq5Nw.net(11)
>94
> 他の関数型言語の例外機構ってどうなっているんだ?知ってたらよろしく。

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

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

102
デフォルトの名無しさん[sage]   投稿日:2016/07/13 23:22:40  ID:2JhFq5Nw.net(11)
>100
> ヒューマンパーズオブジェクトが返るかもしれないだろ

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

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

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

103
デフォルトの名無しさん[sage]   投稿日:2016/07/13 23:36:52  ID:C7S+nyqs.net(2)
型を見りゃいいだろ

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

104
デフォルトの名無しさん[sage]   投稿日:2016/07/14 00:31:59  ID:4Ps/X1K6.net
>102
いやお前それ苦しいだろ

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

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

105
デフォルトの名無しさん[sage]   投稿日:2016/07/14 01:02:32  ID:9qkjMq+e.net
>104
言うと思ったw

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

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

106
デフォルトの名無しさん[sage]   投稿日:2016/07/14 01:31:15  ID:rhZMoeJF.net
>101
>関数型で戻り値でエラー情報なんか返したら
>エラー情報が返ってきたら、if式による分岐の嵐でもはや

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

107
デフォルトの名無しさん[]   投稿日:2016/07/14 06:27:39  ID:cfi8dg7p.net(2)
自分の思い込みの通りなら良い設計良いコードw

108
デフォルトの名無しさん[sage]   投稿日:2016/07/14 07:26:28  ID:xgZTwt3g.net
正しく意図した通りに騙してくれるなら
明らかに良いコードだろ
頭のてっぺんからケツのシワまで数え上げてようやく読解できるコードが糞じゃなきゃ何なんだ

109
デフォルトの名無しさん[]   投稿日:2016/07/14 07:44:38  ID:cfi8dg7p.net(2)
クソの主観によりクソ認定されたコード達w
本当は良い奴も沢山いただろうに不憫だわーw

110
デフォルトの名無しさん[sage]   投稿日:2016/07/14 08:31:57  ID:qme/E7bl.net
車輪の再発明しか出来ない人がいると聞いて。

111
デフォルトの名無しさん[sage]   投稿日:2016/07/15 23:14:34  ID:/IkQTUfk.net
DAO とかDTO ってのが出てくるアーキテクチャは手続き型であって、オブジェクト指向ではない

ってのが解る人ここにいるか?
コメント3件

112
デフォルトの名無しさん[sage]   投稿日:2016/07/15 23:20:25  ID:sS/v2c9e.net
そんな嘘ついちゃいけないんだお

113
デフォルトの名無しさん[]   投稿日:2016/07/15 23:39:15  ID:iR/HdeCl.net
今の日本人は>111みたいな馬鹿が普通なんだお
コメント1件

114
デフォルトの名無しさん[sage]   投稿日:2016/07/21 22:59:46  ID:6Fy4Bz7m.net
>113
やはり解る人はいないか
DAOやDTOってのはデータと処理を分離するから手続き的なんだがなぁ
コメント1件

115
デフォルトの名無しさん[sage]   投稿日:2016/07/21 23:36:49  ID:vaQfL518.net
オブジェクト指向なのはEntityを使ったタイプのO/Rマッパーだね。
Railsとかもそう。DAOやDTOなんてのは出てこないで
データベースがオブジェクトにそのままマッピングされる。

116
デフォルトの名無しさん[sage]   投稿日:2016/07/22 08:12:39  ID:OQdSZmk7.net
抽象化が過ぎて解る人がいないだけ

117
デフォルトの名無しさん[sage]   投稿日:2016/07/22 18:14:47  ID:fQzF4pQd.net
>111
主張が良くわからない。

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

118
デフォルトの名無しさん[]   投稿日:2016/07/30 00:56:46  ID:crIAC8Sk.net(2)
言いたいのは単純に

DAO/DTO

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

それだけだろ。
コメント1件

119
デフォルトの名無しさん[sage]   投稿日:2016/07/30 02:56:03  ID:YgaIk6dE.net
んなことゆーたら全部手続きですやんける
コメント1件

120
デフォルトの名無しさん[sage]   投稿日:2016/07/30 02:57:31  ID:6YLFMraq.net
>119
程度の問題

121
デフォルトの名無しさん[sage]   投稿日:2016/07/30 03:07:28  ID:crIAC8Sk.net(2)
単に>114が知ったかぶりしたいだけだろ。
>111の段階で明らかだし。

122
デフォルトの名無しさん[sage]   投稿日:2016/07/30 08:02:13  ID:gkAo/Cig.net
>118
逆だろ
使うのはオブジェクト指向にするためで
その実装の中身は程度の差こそあれ
DBを相手にする以上手続き的にならざるを得ない


123
デフォルトの名無しさん[]   投稿日:2016/07/30 08:03:21  ID:cz6waps9.net
知ったかぶりにすらなってなくて意味のない単語の羅列にすぎん

124
デフォルトの名無しさん[]   投稿日:2016/08/04 16:27:41  ID:pdTKskF+.net
クラスの中に別のクラスをコンポジットしてあり、
そのクラスの中にも別のクラスをコンポジットしてあり…という場合、

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

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

125
デフォルトの名無しさん[sage]   投稿日:2016/08/04 19:08:09  ID:w6fnMNqO.net
別に良いけど
innerClass.set_valueが呼ばれて値が変更されたときに
変更されたことをouterClassやmiddleClassに通知する仕組みが必要になるかもしれないよ
この場合、余計にややこしくなる

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

126
デフォルトの名無しさん[sage]   投稿日:2016/08/04 20:37:30  ID:jTAWnEUa.net
>124
O/Rマッパーを使うからそういう処理は
勝手にやってくれる。

127
デフォルトの名無しさん[sage]   投稿日:2016/08/04 22:17:26  ID:9BD7w8j0.net
>124
更に言えば
実装方法としても、set_valueは分かり難いし楽でも何でもない
あえてやるなら
outerClass.set_value(key, value)とか?
コメント4件

128
デフォルトの名無しさん[sage]   投稿日:2016/08/04 22:24:04  ID:dkWDRS+N.net(5)
>127
最低のやり方だな
そのk,vのMap、実行するまで完全なブラックボックスになるじゃん
死んで、どうぞ

129
デフォルトの名無しさん[sage]   投稿日:2016/08/04 23:34:15  ID:dkWDRS+N.net(5)
>127
くっせ〜なホント
こういうペチプ〜崩れの塵屑見ると延髄チョップからのバックドロップ食らわせてやりたくなるわ
まじな。死ね。

130
デフォルトの名無しさん[sage]   投稿日:2016/08/04 23:36:44  ID:dkWDRS+N.net(5)
なんでもarrayにしときゃいいと思ってるド低脳
チンパンジー以下のサルゥ
ほんとつっかえ・・・

131
デフォルトの名無しさん[sage]   投稿日:2016/08/04 23:37:05  ID:dkWDRS+N.net(5)
>127
血染めの赤にしてやる
死ね

132
デフォルトの名無しさん[sage]   投稿日:2016/08/04 23:46:15  ID:dkWDRS+N.net(5)
>127
おら何とか言えよゴミ
ID変わるまで逃げるのか?
ほんまつっかえゴミくずやな〜

133
デフォルトの名無しさん[sage]   投稿日:2016/08/05 07:18:34  ID:ZdrtHNhg.net
イコール代入するなら、最後は明示されたセッター呼ぶのは中途半端な気がする。

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

134
デフォルトの名無しさん[sage]   投稿日:2016/08/05 10:32:18  ID:VlcB2rw7.net
結論
余計なことはするな

135
デフォルトの名無しさん[]   投稿日:2016/08/10 22:14:29  ID:UWZg55pn.net
株式会社TOUAが2016年7月に破産
http://www.tdb.co.jp/tosan/syosai/4191.html
コメント1件

136
デフォルトの名無しさん[sage]   投稿日:2016/08/11 00:00:42  ID:0L+mrDki.net
>135
派遣会社ってピンハネしかしてないのに潰れるの?
コメント1件

137
デフォルトの名無しさん[]   投稿日:2016/08/11 00:16:35  ID:OU7OxTj6.net
>136
トウアは仕事をしない、仕事ができない人間を抱えすぎていたのと、資金がもともとないのにオフィスを分散させたり、複数社のグループにしていたせいで効率が悪かった。

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

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

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

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

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

138
デフォルトの名無しさん[sage]   投稿日:2016/09/10 13:15:16  ID:twqmh/TK.net
予想通り、誰もいなくなったのね。

139
デフォルトの名無しさん[sage]   投稿日:2016/09/10 15:03:56  ID:+QFLkWhC.net
static Koma.move() の頃がおまいら一番輝いてたね}

140
デフォルトの名無しさん[sage]   投稿日:2016/09/17 22:40:32  ID:hd6Wyy09.net
人の意見を聞かずにバッサリ切り捨てる、典型的な2ch脳な人が
のさばり出した時点で離れた。

141
デフォルトの名無しさん[sage]   投稿日:2016/09/19 10:09:43  ID:bJUofi69.net
それぞれに結論がでてる状態なんだろ?
俺も一連のやりとりでオブジェクト指向ってやっぱりクソだなって再認識した

142
デフォルトの名無しさん[sage]   投稿日:2016/09/19 11:03:13  ID:KUojTFe6.net(4)
やっぱり誰でもわかる手続き型がナンバーワン

143
デフォルトの名無しさん[sage]   投稿日:2016/09/19 12:18:29  ID:0K/woKyj.net
手続き型は誰でもわかるが工数が多すぎてな
ビジネスでやる以上工数は節約しなきゃ

144
デフォルトの名無しさん[sage]   投稿日:2016/09/19 12:59:11  ID:KUojTFe6.net(4)
誰でもわかる明朗なコードを書かなくてはいけない
ビジネスだからこそ、手続き型がナンバーワン
ビジネスは君の趣味ではない

145
デフォルトの名無しさん[sage]   投稿日:2016/09/19 13:02:51  ID:xTk+6xzH.net
ビジネスだからこそお荷物は解雇しなきゃならない
ある程度の能力のある人間が工数を減らせる手法で開発する
工数の掛かる手続き型しか書けない読めない人は解雇するべきビジネスだから

146
デフォルトの名無しさん[sage]   投稿日:2016/09/19 13:08:18  ID:KUojTFe6.net(4)
趣味をビジネスに持ち出すオタクはNGですよ、これ常識w

147
デフォルトの名無しさん[sage]   投稿日:2016/09/19 14:10:27  ID:VkQagIEW.net
成長しない新米プログラマをいつまでも傭い続けるわけにはいかない
ビジネスってさボランティアじゃないんだよね

148
デフォルトの名無しさん[sage]   投稿日:2016/09/19 14:18:05  ID:KUojTFe6.net(4)
で、君らはまたstatic final Koma.move(int kyori)すんの?

149
デフォルトの名無しさん[sage]   投稿日:2016/09/19 14:29:03  ID:AFsKEmAF.net
回り将棋ならいいかもしれない

150
デフォルトの名無しさん[]   投稿日:2016/12/27 23:00:43  ID:DbM4OtJE.net(2)
ViewModelってどのレイヤーに属するんだ?
Viewに関する知識はないからUIレイヤーではないだろう
ビジネスルールに関する知識は必要だからドメインレイヤー?

151
デフォルトの名無しさん[sage]   投稿日:2016/12/27 23:06:49  ID:+TUrL10Q.net(2)
UIレイヤーの中のドメインレイヤーとの境界面、じゃないの

152
デフォルトの名無しさん[sage]   投稿日:2016/12/27 23:10:35  ID:+TUrL10Q.net(2)
あ、あとViewModelに必要な知識はビジネスルールじゃなくて
ドメインレイヤーのインターフェースだけじゃないのかな?
ビジネスルールに関することはモデル内で処理するべきだと思って作ってるけど…
コメント1件

153
デフォルトの名無しさん[sage]   投稿日:2016/12/27 23:37:51  ID:DbM4OtJE.net(2)
>152
俺も最初はそう思ってたけど現実にそれではうまくいかなかったんだ

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

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

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

154
デフォルトの名無しさん[sage]   投稿日:2016/12/28 00:02:52  ID:KMmXCa3M.net
自分は個人で作ってるだけで好きなようにやれるからだけど、
そういう場合、自分はxもyもそのままモデルに投げてその処理はいったんそこで終わり。
モデルで値をチェックしてエラーならエラーイベント発生
→入力用ViewModelがそのイベントを受け取ってViewに伝えるDataErrorイベント発生
→Viewが変化

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

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

155
デフォルトの名無しさん[sage]   投稿日:2016/12/28 20:24:38  ID:b06lzq40.net(4)
限界あるな
xにうんこって入れられても一旦は保存するってことだろそれ
まさにクソまみれ

156
デフォルトの名無しさん[sage]   投稿日:2016/12/28 21:08:30  ID:YF6A9Wev.net
ViewModelが勝手に「これはうんこだ!捨てておこう!」「これはうんこじゃない!大丈夫だ!」
なんてやってる方が、いずれシステムがうんこまみれになる危険が高い気がするが…

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

157
デフォルトの名無しさん[sage]   投稿日:2016/12/28 21:55:12  ID:b06lzq40.net(4)
>156
じゃあ超長い文字列とかも一旦は保存するんだろ?
思想に限界があるって気付けよ

158
デフォルトの名無しさん[sage]   投稿日:2016/12/28 22:03:00  ID:b06lzq40.net(4)
そもそも画面仕様が専用であるはずなのに
データ型のみModel依存ってこだわりがうんこ
画面なんか内部も含めて作り捨て上等だろ

159
デフォルトの名無しさん[sage]   投稿日:2016/12/28 22:06:08  ID:b06lzq40.net(4)
次の変更は一度にたくさん入力したいのでExcelかcsvから読み込んでもらえますか?
だったら一生懸命付けた汎用性もm9(^Д^)プギャー

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

161
デフォルトの名無しさん[sage]   投稿日:2016/12/29 00:14:19  ID:5yPVbf0y.net(2)
一切関知すべきじゃないな。
うんこかもしれないもの、としてVM以降に渡して、うんこではないものを貰うしか無い。
コメント1件

162
デフォルトの名無しさん[sage]   投稿日:2016/12/29 00:36:39  ID:BD9K+jOv.net(2)
それだと使い勝手は悪くなるな

163
デフォルトの名無しさん[sage]   投稿日:2016/12/29 02:16:04  ID:ZpKqxRRa.net(3)
>161
小数じゃないのに小数点が入力できちゃったり
マイナス値なんて取らないのにマイナスが入力できちゃったり
全角なんて入力してほしくないのに全角で打てちゃったり
ファイルパスを入力して欲しいのにパスに入力できない文字が入る
その状態でファイルオープンダイアログ開いたら死ぬの?とか
素人丸出しアプリだな
visualstudioでプロパティいじれば解決する話をわざわざコードで記述してバグる超絶欠陥製品にしかならないだろうね
すべての値のチェックを入口で退治するんではなくて一度保持してしまうから問題を拡散している
undoしたらどこの値に戻るの?それ
コメント2件


164
デフォルトの名無しさん[sage]   投稿日:2016/12/29 02:36:25  ID:RruPXahs.net
>163
何を誤解してるかわからんが、それは、ビューモデル以外の場所で即座に否定されたり、是正されたり、これはは間違ってますよとエラーと判定されるから、
ビューモデルは、判定結果をおとなしく持って、ビューにレンダリングしてもらうだけじゃん。

お前がやってんのは、それはVMの仕事じゃない。
コメント1件

165
デフォルトの名無しさん[sage]   投稿日:2016/12/29 08:38:21  ID:ZpKqxRRa.net(3)
>164
だからさ
その構造を実現することになんの意味があるのって話
コメント1件

166
デフォルトの名無しさん[sage]   投稿日:2016/12/29 10:19:02  ID:BD9K+jOv.net(2)
>163
そういうのは大前提としてやった上での話だよ
整数入力コントロールには指定した桁数いないの数字しか入らない(アルファベットなどはキーを押しても入力されない)
その上でビューモデルにどこまでビジネスルールの知識を与えるか、ドメインモデルとの違いはなんだ、という議論をしている
コメント1件

167
デフォルトの名無しさん[sage]   投稿日:2016/12/29 10:37:25  ID:vPLPY1D6.net
>165
データを処理する処理に徹することができるのと
データを描画する処理に徹することができるんじゃん。
コメント1件

168
デフォルトの名無しさん[sage]   投稿日:2016/12/29 11:35:18  ID:3hi3YdfK.net(5)
>167
現実にはできなくて、やるメリットもあまりなくてって状況だと思うけど
コメント1件

169
デフォルトの名無しさん[sage]   投稿日:2016/12/29 11:43:36  ID:3hi3YdfK.net(5)
>166
だったら内部の仕様も画面にべったりなんでしょ?
今更分離して何がしたいの?
コメント1件

170
デフォルトの名無しさん[sage]   投稿日:2016/12/29 11:49:35  ID:3hi3YdfK.net(5)
はっきり言ってしまうと経験が浅いから掲げる理想が陳腐
大規模DBとそれを操作するインターフェイスを真似たモデルであれば
画面なんてプロジェクトごと作り捨て上等なんだよ
DBはもう誰も仕様変更を入れられない
画面は実現したい内容によって完全廃棄もありうる
これが現実なんだよ
コメント1件

171
デフォルトの名無しさん[sage]   投稿日:2016/12/29 12:03:50  ID:orpg8/1p.net(4)
>169
VとMVの分離のメリットなら2つ大きいのがある
1. UIの状態数の最小化
2. 手続型から宣言型への移行

172
デフォルトの名無しさん[sage]   投稿日:2016/12/29 12:23:28  ID:orpg8/1p.net(4)
>170
画面を使い捨てる前提ならますます分離した方がいい
ひと昔前はViewにビジネスロジックが当たり前のように書かれていた
こういう画面は本当に使い捨てていい画面なのか判断が難しい
画面を使い捨てる前にリファクタリングを行いビジネスロジックを抽出して分析しなければならなかった
必要なビジネスロジックは残して別の画面から利用するように変更しなければならない
この作業が全てうまくいけばようやっと画面を使い捨てる事が許される

173
デフォルトの名無しさん[sage]   投稿日:2016/12/29 13:00:59  ID:3hi3YdfK.net(5)
だからさ
現実にはできないじゃん
ちょっと突っ込まれるだけでボロボロ抜けが出てくんだから
コメント1件

174
デフォルトの名無しさん[sage]   投稿日:2016/12/29 13:23:47  ID:orpg8/1p.net(4)
>173
最近はちゃんと分離されているシステムが増えてきてる
コメント1件

175
デフォルトの名無しさん[sage]   投稿日:2016/12/29 13:26:05  ID:3hi3YdfK.net(5)
>174
誰の周辺の話なの?
コメント1件

176
デフォルトの名無しさん[sage]   投稿日:2016/12/29 13:36:40  ID:orpg8/1p.net(4)
>175
世界的に

177
デフォルトの名無しさん[sage]   投稿日:2016/12/29 19:34:31  ID:AIw2bcpm.net
>168
割と大規模やってるけど、気合でWPFに移行してからそこそこうまく行ってるよ。
出来なくて切った会社は沢山あった。
コメント2件

178
デフォルトの名無しさん[sage]   投稿日:2016/12/29 22:28:45  ID:ZpKqxRRa.net(3)
>177
そんな多大な犠牲を払ってようやくできたのか?(笑)
設計ってみんながわかりやすくするためにするもんじゃないの?
選ばれし者しかできない時点で失敗してるんだよ
わかる?
コメント1件

179
デフォルトの名無しさん[sage]   投稿日:2016/12/29 23:34:45  ID:5yPVbf0y.net(2)
>178
莫大な犠牲は下請けが払ったんだと思うよ。
選ばれしものしかできないとは思わないが、
選ばれしものが出来ないのはある程度あるんじゃないの?
馬鹿とか。
コメント1件

180
デフォルトの名無しさん[sage]   投稿日:2016/12/30 01:32:03  ID:JXfD++Nt.net(2)
>179
何のための画面と内部の分離だったの?
メリットが見えない
選ばれし者しか理解できないソースと組んだやつしか読めないソースの品質の違いが俺にはさっぱりわからないよ
コメント2件

181
デフォルトの名無しさん[sage]   投稿日:2016/12/30 08:31:43  ID:fHdmB1av.net(2)
>180
前者は選ばれしもの(といってもWPF程度なら並みのプログラマで十分なので選ばれしもというのは大げさだが)なら超低コストで保守できる
後者は書いた本人も含めて保守に膨大なコストがかかる
このようにコストが全く違うわけだけど何故同じと思ったのか理解し難いね
メリットが見えないんじゃなくて見えないフリしてるだけだろきみは
コメント1件

182
デフォルトの名無しさん[sage]   投稿日:2016/12/30 09:27:05  ID:0uD1Maua.net(4)
インスタンスメソッドは選ばれしものにしか使えないから
全てスタティックメソッドにしなさい
ってことですか?

183
デフォルトの名無しさん[sage]   投稿日:2016/12/30 09:41:15  ID:U2S2spdu.net
>visualstudioでプロパティいじれば解決する
あーダメダメ

184
デフォルトの名無しさん[sage]   投稿日:2016/12/30 09:55:02  ID:G92pvYFd.net(2)
できるヤツができないヤツに合わせる必要はない
退化する

185
デフォルトの名無しさん[sage]   投稿日:2016/12/30 10:07:30  ID:0uD1Maua.net(4)
スタティックお兄さん爆誕
古き良きプログラミングの時代、復活の刻

186
デフォルトの名無しさん[sage]   投稿日:2016/12/30 10:21:30  ID:JXfD++Nt.net(2)
>181
え?でもいまの状態で画面と内部の分離ができてないじゃん
値のチェック前に一旦値を保存するんだよね?
内部に問い合わせないとチェックする内容がわからんから
偉そうなこと言ってるけどできたもんはゴミじゃん
コメント2件

187
デフォルトの名無しさん[sage]   投稿日:2016/12/30 11:02:39  ID:fHdmB1av.net(2)
>186
保存ってどこから出てきたんだ?
コメント1件

188
デフォルトの名無しさん[sage]   投稿日:2016/12/30 11:28:27  ID:zvHkIzW0.net(2)
>187
このスレよく読んでからレスしてね

189
デフォルトの名無しさん[sage]   投稿日:2016/12/30 12:14:51  ID:tYlkXQKT.net
ViewModelからModelに入力値の通知を行うことを「保存」と呼ぶ頭のおかしい人が約1名いるだけ

190
デフォルトの名無しさん[]   投稿日:2016/12/30 15:13:10  ID:NIWDNqpS.net
なるほど
どうりで話が通じんわけだ

191
デフォルトの名無しさん[sage]   投稿日:2016/12/30 15:29:32  ID:7Zd5OH2Q.net(2)
>180
画面直すのかデザイナさんにもできる、
ロジック直すのが画面に一切影響しない事を謳ってプログラマだけで出来る。
これ大規模だと結構大きいよ。デザイナさんに動いてもらうのそこそこかかるし。

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

192
デフォルトの名無しさん[sage]   投稿日:2016/12/30 15:44:27  ID:zvHkIzW0.net(2)
>191
はぁ?
なんのこと喋ってるの?
ちゃんと理解してからレスしてね
コメント1件

193
デフォルトの名無しさん[sage]   投稿日:2016/12/30 15:52:05  ID:7Zd5OH2Q.net(2)
>192
>177
で発端にすらなってるから、理解はしてるが。
アホなのかな。

194
デフォルトの名無しさん[sage]   投稿日:2016/12/30 21:13:04  ID:0uD1Maua.net(4)
なぜオブジェクト指向の設計の話になると喧嘩になってしまうのか?
やはり関数型にすべきでないのか?
コメント1件

195
デフォルトの名無しさん[sage]   投稿日:2016/12/30 22:35:50  ID:VqDrYuY4.net
>194
モナドを許すか許さないか論、原始再帰関数の定義の喧嘩になるのがオチ。
手続きとしてCPUが処理している所に別のパラダイム持ち込むとこうなるし、
関数としてGPUが処理している所に手続きを持ち込むと同じように異論は出てくる。

196
デフォルトの名無しさん[]   投稿日:2016/12/30 22:36:08  ID:KB0M7zpX.net
喧嘩がなくなるなら関数型喜んでつかうわ

197
デフォルトの名無しさん[sage]   投稿日:2016/12/30 22:54:38  ID:G92pvYFd.net(2)
工数の少ない方を採用するなぁ
何が何でもオブジェクト指向!ってのは手段が目的になっちゃってるように感じる

198
デフォルトの名無しさん[sage]   投稿日:2016/12/30 23:59:17  ID:0uD1Maua.net(4)
感情をイミュータブルにしましょう

199
デフォルトの名無しさん[sage]   投稿日:2016/12/31 07:44:43  ID:XK+xRs9l.net(5)
工数最小マンって無責任だと思うよ
保守は他人がやるからラピッドでええやんってクズばかりだから業界全体が停滞してるんだよ
多少工数が増えてもエレガントなOOPで作るべきだ
というかそもそも工数ベースで見てもOOPの方が優位だけどな
コメント1件

200
デフォルトの名無しさん[sage]   投稿日:2016/12/31 08:26:58  ID:qTR6JDNw.net(2)
工数最小≠OOP
って、どっから沸いてきた式だよ
コンパイル通らないぞハゲ

201
デフォルトの名無しさん[sage]   投稿日:2016/12/31 10:34:26  ID:H2pBZ8ZG.net
>199
ん?でもさぁ
汎用性つけまくった挙句に次の変更が来なかったら汎用化にかけた工数は無駄じゃない?
コメント1件

202
デフォルトの名無しさん[sage]   投稿日:2016/12/31 11:05:14  ID:XK+xRs9l.net(5)
>201
汎用性と保守性を混同するのは初心者にはありがちだけど全く別のものだぞ
OOPはまず保守性を高めてくれるってのが主だ
結果として見ると汎用性もオマケで付いてくる場合が多いってだけだ
コメント1件

203
デフォルトの名無しさん[sage]   投稿日:2016/12/31 11:40:12  ID:I0WFUQzY.net(4)
>202
そもそもOOPだと何で保守性上がるの?
コメント1件

204
デフォルトの名無しさん[sage]   投稿日:2016/12/31 12:13:13  ID:3aGn9kAy.net
粗結合の徹底→モジュール化→単体テストしやすさ、古くなった部分の可換性
コメント2件

205
デフォルトの名無しさん[sage]   投稿日:2016/12/31 12:24:49  ID:XK+xRs9l.net(5)
>203
SOLIDを実践しやすいから
モデルを忠実にコードに反映できるから
コメント1件

206
デフォルトの名無しさん[sage]   投稿日:2016/12/31 13:03:52  ID:I0WFUQzY.net(4)
>204
OOPならではの部分を強調してほしかったが
疎結合とモジュール性についてまっさきに触れているので結果的に好感触

>205
聞いて損した
コメント1件

207
デフォルトの名無しさん[sage]   投稿日:2016/12/31 13:15:07  ID:XK+xRs9l.net(5)
>206
俺も答えて損した
馬の耳になんとかってヤツだね

208
デフォルトの名無しさん[sage]   投稿日:2016/12/31 13:18:39  ID:I0WFUQzY.net(4)
なんかごめんね…
コメント1件

209
デフォルトの名無しさん[sage]   投稿日:2016/12/31 14:00:22  ID:XK+xRs9l.net(5)
>208
反省しろよ
コメント1件

210
デフォルトの名無しさん[sage]   投稿日:2016/12/31 15:09:26  ID:2Xzfkrwi.net(2)
>209
おまえもな
コメント1件

211
デフォルトの名無しさん[sage]   投稿日:2016/12/31 16:41:13  ID:n5yZbU99.net
>210
消えろ
ぶっ飛ばされんうちにな
コメント2件

212
デフォルトの名無しさん[sage]   投稿日:2016/12/31 17:32:21  ID:2Xzfkrwi.net(2)
>211
おまえもな

213
デフォルトの名無しさん[sage]   投稿日:2016/12/31 17:32:59  ID:qTR6JDNw.net(2)
>211
あんまり調子こいてると手続き型にするぞ?

214
デフォルトの名無しさん[sage]   投稿日:2016/12/31 17:37:54  ID:I0WFUQzY.net(4)
もういいから

215
デフォルトの名無しさん[sage]   投稿日:2016/12/31 17:40:02  ID:YOFqYiBF.net
工数気にするのって完全受注型で自分とこで商品開発できないようなところだろうなと思うわ

216
デフォルトの名無しさん[sage]   投稿日:2017/01/01 00:00:05  ID:7qccLNYe.net
採算度外視で開発とかないわ

217
デフォルトの名無しさん[]   投稿日:2017/01/06 17:03:12  ID:rigfFBS6.net
オブジェクト指向の良書教えて
コメント1件

218
デフォルトの名無しさん[sage]   投稿日:2017/01/06 17:25:52  ID:A0+jLhsU.net

219
デフォルトの名無しさん[sage]   投稿日:2017/01/06 20:45:05  ID:8EHemPmg.net
ループかよ

220
デフォルトの名無しさん[sage]   投稿日:2017/01/07 11:22:42  ID:IG42UiTG.net
>204
手続き型でもできる。
というよりオブジェクトみたいに状態に注目するより
メッセージやメソッド、関数に注目するほうが自然な場合もある。
まあオブジェクト脳だとそういった処理をまとめたクラスを作るんだろうけど。
コメント2件

221
デフォルトの名無しさん[sage]   投稿日:2017/01/07 12:04:44  ID:kXk28A5p.net
>220
具体例は?

222
デフォルトの名無しさん[sage]   投稿日:2017/01/07 13:39:47  ID:u/YaKAHu.net
 サ ー ビ ス ク ラ ス

223
デフォルトの名無しさん[sage]   投稿日:2017/01/07 21:45:21  ID:6fDgBl5y.net
>220
> 手続き型でもできる

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

224
デフォルトの名無しさん[sage]   投稿日:2017/01/07 23:48:37  ID:8zzGw/ml.net
そもそもオブジェクト指向にメリットなんかないのにやり方がわからないとかさっさと廃業しろ

225
デフォルトの名無しさん[sage]   投稿日:2017/01/08 00:04:42  ID:MJfiP+Ss.net(2)
デストラクタは OOP でないと難しいね
え?ポインタの存在自体が邪道ですか?そうかもしれないですかね‥

226
デフォルトの名無しさん[sage]   投稿日:2017/01/08 01:57:35  ID:91a1aYUK.net
デストラクタってOOP以前からあるしOOPと直結する関係性もない
それになぜいきなりポインタ?もはや何が言いたいのか判らない
コメント1件

227
デフォルトの名無しさん[sage]   投稿日:2017/01/08 08:49:06  ID:FbXxDY90.net(2)
そう難しく考える必要はなく物事をシンプルに考えていくと自然とOOPにたどり着くんだけどね
OOPに拒否感を持つ人はその当たり前の感覚を持っていないアスペなんじゃないかな
子供の頃いじめられたりしなかったか?

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

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

228
デフォルトの名無しさん[sage]   投稿日:2017/01/08 08:58:29  ID:FbXxDY90.net(2)
なんていうかね
棍棒だと重いし動物殺しにくいけど木の棒の先っぽに鋭い石括りつけたら軽くてめっちゃ殺せるんだけどウホホwww
正直この程度の発想でしかないんだよ
OOPってそんなに高尚で難しいものじゃない
それをわざわざ難しい概念だと錯覚して悩むのは時間の無駄じゃないか?
OOPとはなにかOOPの存在意義はなんて哲学者みたいなことを考えてないでさ
自分の感覚に従ってOOPってよくわからんけど手続き型より楽だわウホホwwwって気楽にコーディングすればいいんだよ

229
デフォルトの名無しさん[sage]   投稿日:2017/01/08 09:38:52  ID:oIuk3BCz.net(4)
なんで人格攻撃に移るの?
自分の中で辻褄が合ってないから反論できないのに他人を叩くことでそれを解消しようとするのは間違ってる
お前は技術者を廃業しろ
コメント1件

230
デフォルトの名無しさん[sage]   投稿日:2017/01/08 09:50:56  ID:TXqGgIea.net(6)
ワイ「関数型最強ウホホwww」

231
デフォルトの名無しさん[sage]   投稿日:2017/01/08 10:35:35  ID:uhuLxfGv.net
> 物事をシンプルに考えていくと自然とOOPにたどり着く

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

232
デフォルトの名無しさん[sage]   投稿日:2017/01/08 10:35:39  ID:jdkn79Su.net
>229
残念ながらこれもOOPがらみでよく見られる光景
追い詰められてならまだしもわりと最初のほうからこれだもんね
さらにそれにしたってそれすらを長文でぐだぐだと…推して知るべし

233
デフォルトの名無しさん[sage]   投稿日:2017/01/08 11:28:11  ID:TXqGgIea.net(6)
2chの長文すら読めないオジサンって、普段技術書読まないんですかあ?

234
デフォルトの名無しさん[sage]   投稿日:2017/01/08 11:45:15  ID:kab+ZCih.net(4)
技術書ってクソばかりじゃないですか

235
デフォルトの名無しさん[sage]   投稿日:2017/01/08 12:53:03  ID:MJfiP+Ss.net(2)
>226
デストラクタはOOPと同時ですよ

236
デフォルトの名無しさん[sage]   投稿日:2017/01/08 13:04:04  ID:TNnQVUnB.net(2)
protectedっていつ使うんですかぁ?中途半端じゃないですかぁ?

237
デフォルトの名無しさん[sage]   投稿日:2017/01/08 13:07:40  ID:TXqGgIea.net(6)
継承やUTで簡単に使えるようにするため
privateは全てprotectedにしろと言われたことあったわ

238
デフォルトの名無しさん[sage]   投稿日:2017/01/08 13:23:09  ID:kab+ZCih.net(4)
継承っていう仕組みがクソ。疎結合とはなんだったのかって気分にしてくれる。

239
デフォルトの名無しさん[sage]   投稿日:2017/01/08 13:34:11  ID:kab+ZCih.net(4)
OOPのメリットとして吹聴される要素の8割はクソ。
カプセル化はクソ(めんどくさい)
継承はクソ(親子のねっとりしたつながりがキモイ)
多態は野ぐそ(多態のための汎化、インタフェース抽出とか勘違いも甚だしい。保守性に逆行している)
俺OOP使ってこんな曲芸できます案件多すぎクソ。
コメント1件

240
デフォルトの名無しさん[sage]   投稿日:2017/01/08 13:38:11  ID:tl4nBuMM.net(2)
葡萄に手が届かない狐さんのたわごと

241
デフォルトの名無しさん[sage]   投稿日:2017/01/08 14:08:24  ID:TXqGgIea.net(6)
>239
車輪的再発明すきそう

242
デフォルトの名無しさん[sage]   投稿日:2017/01/08 14:08:45  ID:XDbKIsfA.net(5)
OOPみたいな簡単な仕組みも理解できない人って可哀想
もっと体動かすだけとか根性あればなんとかなる仕事に転職しないの?

243
デフォルトの名無しさん[sage]   投稿日:2017/01/08 14:17:09  ID:+qBxgbmJ.net
OOPは本当に簡単で短絡的な思考のすえたどり着く結論だからね
オブジェクトに操作が内包されているというのは
まるで利権主義で、縦割り行政で、日本的といえる
自分の仕事しかしないし、利権はぜった他人に渡さない
利権という物質的なオブジェクトにすべてが紐づいていて整理されている

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

244
デフォルトの名無しさん[sage]   投稿日:2017/01/08 15:26:35  ID:TXqGgIea.net(6)
OOPを無くした人類はどこへ向かうのか

245
236[sage]   投稿日:2017/01/08 15:47:12  ID:TNnQVUnB.net(2)
オブジェクト指向を用いるメリット
「ラクして、楽しく、良いもの」を作れる

スッキリJavaより抜粋

246
デフォルトの名無しさん[sage]   投稿日:2017/01/08 16:12:47  ID:TXqGgIea.net(6)
「ラクして、楽しく、良いもの」を作れる
オブジェクト指向登場後のソフトウェア業界は
さぞかし良い世界になったんだろなあ

247
デフォルトの名無しさん[sage]   投稿日:2017/01/08 16:19:04  ID:kab+ZCih.net(4)
とてつもなく良い世界にはなってる。

248
デフォルトの名無しさん[sage]   投稿日:2017/01/08 16:46:50  ID:XDbKIsfA.net(5)
簡単になりすぎて捌ける規模が大きくなったから
逆に要求が膨れ上がって結局辛い世になってる気もするが
まあCOBOLとかやらされるよかマシかな

249
デフォルトの名無しさん[sage]   投稿日:2017/01/08 16:51:03  ID:hENayCqC.net
オブジェクト志向言語使っててもアホが考えた社内規約とやらとヘボいフレームワークで全く楽にならねえw
コメント1件

250
デフォルトの名無しさん[sage]   投稿日:2017/01/08 17:26:00  ID:XDbKIsfA.net(5)
>249
あーわかる
なぜか規約もフレームワークも手続型っぽいんだよな

251
デフォルトの名無しさん[sage]   投稿日:2017/01/08 19:34:42  ID:oIuk3BCz.net(4)
オブジェクト指向の利点って明確にならないね
コメント1件

252
デフォルトの名無しさん[sage]   投稿日:2017/01/08 21:51:12  ID:tl4nBuMM.net(2)
そういやこのスレって、どんな話題で始まったんだっけ?
「オブジェクト指向の利点を明確にする」
だったっけ?
コメント1件

253
デフォルトの名無しさん[sage]   投稿日:2017/01/08 22:30:47  ID:oIuk3BCz.net(4)
>252
まずメリットが明確にならないとやる意味もわからなくてさ

254
デフォルトの名無しさん[sage]   投稿日:2017/01/08 23:00:17  ID:iT+T8lZs.net
>251
俺も最近正直そう思うようになった

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

255
デフォルトの名無しさん[sage]   投稿日:2017/01/08 23:23:47  ID:XDbKIsfA.net(5)
そういう本質的に重要な事を記述しやすいってところだろ?
コメント1件

256
デフォルトの名無しさん[sage]   投稿日:2017/01/08 23:34:45  ID:oIuk3BCz.net(4)
>255
え?
全然意味わかんない
コメント1件

257
デフォルトの名無しさん[sage]   投稿日:2017/01/08 23:40:45  ID:XDbKIsfA.net(5)
>256
そのうちわかるよ

258
デフォルトの名無しさん[sage]   投稿日:2017/01/08 23:49:40  ID:Y13a86EN.net
でたw
「そのうち」としか答えない相手から聞き出せることはもう無い

259
デフォルトの名無しさん[sage]   投稿日:2017/01/08 23:58:45  ID:GQKjgtEl.net
>254
要するに編集方針の違いでしかないんだよ。
出来るやつが書けばどれでもどうとでもなる。
それだけ。
それよりOAOO/DRY/メトリックス(トポロジー)の方が重要。

260
デフォルトの名無しさん[sage]   投稿日:2017/01/09 00:35:10  ID:XasE0eMK.net(2)
ソースのどこに記述するか?って方式の話でしかないよね
ボタン1を押したときの処理Aはオブジェクト指向で記述しようがそれ以外で記述しようが
ソースのどこかに記述しなければならない
オブジェクト指向ってのはつまるところその様式美



別にどこだっていいじゃん( ´∀`)b

261
デフォルトの名無しさん[sage]   投稿日:2017/01/09 01:00:59  ID:Dm7q6S9e.net
そしてウンポコPのペチプァみたいなゴミ屑コードができあがる

262
デフォルトの名無しさん[sage]   投稿日:2017/01/09 07:16:32  ID:MB0kUoDj.net
そのボタン1は、UIコントロールの基底クラスを継承するというOOPで作られてるとは思うけど
まぁだからといって使う側がOOPに従わなきゃならん、ということにはならないな

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

263
デフォルトの名無しさん[sage]   投稿日:2017/01/09 07:18:15  ID:XasE0eMK.net(2)
>262
話の主旨もわからず回答とかおめでてーな

264
デフォルトの名無しさん[sage]   投稿日:2017/01/09 10:27:05  ID:VxLyi546.net
イベントハンドラの引数に押されたボタンのid渡すコード見るたびに
せっかくのオブジェクト指向が台無しになってる感はある。

265
デフォルトの名無しさん[sage]   投稿日:2017/01/10 22:51:34  ID:drzFW1uA.net
クソコードハラスメントって概念を提唱したい
書いた本人が意図する、しないにかかわらず、相手が不快に思い、
相手が自身の尊厳を傷つけられたと感じるようなクソコードを指します。

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

266
デフォルトの名無しさん[sage]   投稿日:2017/01/11 00:22:47  ID:GtOiWPCh.net(4)
大概書いた奴は既に現場にいないという現実

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

267
デフォルトの名無しさん[sage]   投稿日:2017/01/11 00:55:08  ID:t4W503XG.net(2)
自社で保守する仕事なら綺麗に書くけど
同業他社が保守するなら難解な方がいいだろ
足を引っ張って競争が優位になる
コメント1件

268
デフォルトの名無しさん[sage]   投稿日:2017/01/11 00:58:40  ID:p4WB0UzK.net
無駄

269
デフォルトの名無しさん[sage]   投稿日:2017/01/11 00:58:42  ID:GtOiWPCh.net(4)
>267
こんなんだから凋落してくんだよジャップランド土人が

270
デフォルトの名無しさん[sage]   投稿日:2017/01/11 01:03:37  ID:t4W503XG.net(2)
アベノミクスで不景気だしどこも余裕がない
毎日残業で安月給じゃそりゃ人格も歪んでくる

271
デフォルトの名無しさん[sage]   投稿日:2017/01/11 01:06:16  ID:1SbN3a75.net(2)
>265
その全てをパスしているが動かないコードと
その全てを満たしているが動くコードの
どちらを持っていくかと言われたら迷わず糞を持っていく俺
コメント1件

272
デフォルトの名無しさん[sage]   投稿日:2017/01/11 01:20:12  ID:GtOiWPCh.net(4)
>271
動くなんて大前提だよ
そんなんだから脳みそまで糞まみれなんだよボケナス
殺すぞ
コメント1件

273
デフォルトの名無しさん[sage]   投稿日:2017/01/11 06:50:15  ID:1SbN3a75.net(2)
>272
動いた上でさらに付加する価値だろ?
そんなの省かれるに決まってるだろ
いい加減テメェのこだわりは重要じゃねぇって気付けよ

274
デフォルトの名無しさん[]   投稿日:2017/01/11 12:29:20  ID:1hmax6h/.net
結論が出た様です
>265のセンスのない造語の使用は却下されました
妥当な結果でしょう

275
デフォルトの名無しさん[sage]   投稿日:2017/01/11 22:20:40  ID:R6uUA9rB.net
仕様が無いのになぜ動いていると言えるのか。
コメント1件

276
デフォルトの名無しさん[sage]   投稿日:2017/01/11 22:53:40  ID:SOQiv9G3.net(2)
動いてるとも動いてないとも言えない
これが波動関数ってやつさ

277
デフォルトの名無しさん[sage]   投稿日:2017/01/11 23:44:57  ID:GtOiWPCh.net(4)
>275
仕様がない=動作が正=動いている

278
デフォルトの名無しさん[sage]   投稿日:2017/01/11 23:53:04  ID:SOQiv9G3.net(2)
仕様がないつまり未定義
つまり何が起こってもおかしくない
パルプンテ状態

279
デフォルトの名無しさん[sage]   投稿日:2017/01/12 08:29:14  ID:D/kCxt4Z.net
Cの悪口はやめろ

280
デフォルトの名無しさん[sage]   投稿日:2017/01/14 20:38:16  ID:2kEkn3lr.net
初期化以降はリードオンリーとするフィールドint barがある場合
class Foo {
private int bar;
public Foo(int bar) {this.bar = bar;}
public int getBar() {return bar;} // ゲッターだけ公開
}
↑こうするより↓こうしたほうが色々気持ちよくない?
class Foo {
public final int bar; // C#ではfinalのかわりにreadonly
public Foo(int bar) {this.bar = bar;}
}
どうよ?
コメント1件

281
デフォルトの名無しさん[sage]   投稿日:2017/01/14 21:48:54  ID:YGCVk3Sf.net
>280
C#ならプロパティ使えばよくね
コメント1件

282
デフォルトの名無しさん[sage]   投稿日:2017/01/14 21:56:28  ID:rLoB6nGZ.net
>281
Java脳だから仕方ない

283
デフォルトの名無しさん[sage]   投稿日:2017/01/14 23:11:55  ID:/w8IJdhk.net
C#は、自動プロパティの初期化もできるようになったしな

284
デフォルトの名無しさん[sage]   投稿日:2017/01/15 09:41:20  ID:h+wxmfZm.net(2)
OOPでフィールドを丸出しなんてはしたないことはやめてください
コメント1件

285
デフォルトの名無しさん[sage]   投稿日:2017/01/15 19:09:57  ID:L9FFXvsx.net
>284
それに対する俺の考えはこう
・あるものが不変で良いなら不変にしておきたい
・不変であるのならメソッドを経由しなくていい
・フィールドをpublicにしておける言語がある理由もそこらへんじゃないのかなっ
どう?
「OOPで〜」に対する返事にはなってないかもしれないけど

286
デフォルトの名無しさん[sage]   投稿日:2017/01/15 19:25:01  ID:h+wxmfZm.net(2)
フィールドは実装
実装を晒しては行けない
コメント2件

287
デフォルトの名無しさん[sage]   投稿日:2017/01/15 19:43:31  ID:0NZmkTyB.net
オブジェクト指向的にはプロパティへのアクセスはメッセージに限定してカプセル化としたいんじゃないかなぁ?
って思う
コメント1件

288
285[sage]   投稿日:2017/01/15 20:03:27  ID:zmg1eHAc.net
元の主張はいったん置いとくけど

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

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

289
デフォルトの名無しさん[sage]   投稿日:2017/01/15 20:05:23  ID:kU0DmNyE.net
そういうOOPLってのは
フィールドをpublicに出来ない言語って意味ね

290
デフォルトの名無しさん[sage]   投稿日:2017/01/15 23:28:22  ID:W9Vj9w+K.net(2)
ま、はしかみたいなものだね
OOの美学みたいな考えがあるんだろうけど
よくよく考えると大した概念ではないし、本質的でもない
多くのOOPはマルチメソッドをサポートしていないので
二つのオブジェクトに跨る処理をどちらに書こうかという
問題にぶち当たるし、得てしてそういった複数のオブジェクトに跨がる処理が
そのプログラムの本質的な部分であったりもするからね
プログラムの簡単な部分に関しては簡単に書ける、それがOOP

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

292
デフォルトの名無しさん[sage]   投稿日:2017/01/16 00:16:59  ID:WtkYzKjH.net(2)
private Integer id;
private String domain;

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

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

293
デフォルトの名無しさん[sage]   投稿日:2017/01/16 06:36:24  ID:5GH26V/A.net
リフレクションでめんどくさいからやめろよ

294
デフォルトの名無しさん[sage]   投稿日:2017/01/16 10:25:44  ID:Keb10HxT.net
>292
それはじめると君の同僚たちもそれに倣って、
結果、画面にもSQLにも業務ロジックにも、至る所に文字列操作が書かれるぞ
連結してaccountId作ったり、accountIdを文字数や正規表現でidとdomainにバラしたり…

295
デフォルトの名無しさん[sage]   投稿日:2017/01/16 23:15:52  ID:WtkYzKjH.net(2)
class User {
private Integer id;
private String domain;

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

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

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

296
デフォルトの名無しさん[sage]   投稿日:2017/01/16 23:43:04  ID:7tn+c1o5.net
それだと至る所でハイフンでsplitされるって話だろ
AccountId値型を作ろう

297
デフォルトの名無しさん[sage]   投稿日:2017/03/25 12:41:38  ID:Hepb4FxQ.net
instanceおじさんをレイオフする会を発足します

298
デフォルトの名無しさん[sage]   投稿日:2017/03/26 09:22:55  ID:BMgG41Fb.net
本来であればフィールドメンバと引数とわずかばかりのシステムメソッドで処理を完結するのがベストなのだが、
それしようとすると、やりたいことをやるために必要な情報がなかったりして
親の親から引数を渡し直さないとけなくなったりしてそうこうしてるうちに
結局グローバル変数やシングルトン(instance)で便利になったと喜んでしまう性。

299
デフォルトの名無しさん[sage]   投稿日:2017/03/26 22:59:55  ID:EKCv78dE.net
>295
現時点でCallerには「domain-id」の文字列以外必要ないなら、それでOK
Callerもid or domainが単独で必要ならgetIdやgetDomainもつける

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

300
デフォルトの名無しさん[sage]   投稿日:2017/04/20 23:17:36  ID:nIwh3CMn.net
ワインと豆腐には旅をさせちゃあいけない
という山岡さんの名言がある

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

301
デフォルトの名無しさん[sage]   投稿日:2017/04/21 03:45:03  ID:vq22u+1l.net
漫画を引用する様な見識の狭い奴の言う事を誰が本気で聞くのか
語りたい事があるなら自分自身の言葉で語れ

302
デフォルトの名無しさん[]   投稿日:2017/04/21 12:33:54  ID:e2S2gBzR.net
旅をするのは変数ではなく値なんだけどね

303
デフォルトの名無しさん[sage]   投稿日:2017/04/21 21:12:23  ID:JwbSy4qm.net
グロバール変数やめました
シングルトンもやめました
結果、
オブジェクトをたらい回しにしまくりんぐ地獄

304
デフォルトの名無しさん[sage]   投稿日:2017/04/23 15:03:38  ID:jdVuS3ql.net(2)
郵便物が来たってメモはたらい回しでいいけど、
郵便物自体はたらい回しするなよ。

305
デフォルトの名無しさん[sage]   投稿日:2017/04/23 15:28:16  ID:mKAZq6VZ.net(2)
それは郵便物オブジェクトが人間オブジェクトにメッセージパッシングして言ってんの?

306
デフォルトの名無しさん[sage]   投稿日:2017/04/23 15:45:39  ID:jdVuS3ql.net(2)
郵便物オブジェクトは何もしないだろ。
メッセージをパッシングしているのはメッセンジャーさ。

307
デフォルトの名無しさん[sage]   投稿日:2017/04/23 16:15:44  ID:mKAZq6VZ.net(2)
メッセンジャーヴォーイズはどこで何をしてるんだい??

308
デフォルトの名無しさん[sage]   投稿日:2017/04/23 21:23:18  ID:mOY43HnC.net
staticおじさんは今日も元気でした
コメント1件

309
デフォルトの名無しさん[sage]   投稿日:2017/04/23 22:31:23  ID:HqNmAyPa.net(2)
>308
言葉に気をつけろよ
キャットドア問題の前にお前らはボロ雑巾のように敗れ去っているのだから

310
デフォルトの名無しさん[sage]   投稿日:2017/04/23 23:16:24  ID:fe+cTrdN.net(2)
勝ち負けだったのか
コメント1件

311
デフォルトの名無しさん[sage]   投稿日:2017/04/23 23:26:57  ID:HqNmAyPa.net(2)
>310
負けは認めるんだな

312
デフォルトの名無しさん[sage]   投稿日:2017/04/23 23:46:36  ID:fe+cTrdN.net(2)
ごめんやけど最近来たから勝負してたところを見たことない
どんな勝負だったの?

313
デフォルトの名無しさん[sage]   投稿日:2017/04/24 00:08:36  ID:ix3EvlHl.net(4)
あとキャットドアって初めて聞いたんだけど何なの?

314
デフォルトの名無しさん[さげ]   投稿日:2017/04/24 00:13:48  ID:ix3EvlHl.net(4)
>>キャットドア問題
ググってもAmazonしか出てこない、、、

315
デフォルトの名無しさん[sage]   投稿日:2017/04/24 00:51:34  ID:eKiX5mKm.net
google「オブジェクト指向 キャットドア問題」
で出るな
コメント2件

316
デフォルトの名無しさん[さげ]   投稿日:2017/04/24 01:00:29  ID:ix3EvlHl.net(4)
>315
まじか!
ありがとう、見てみるよ

317
デフォルトの名無しさん[sage]   投稿日:2017/04/24 01:02:48  ID:ix3EvlHl.net(4)
なんか別のスレがヒットするだけなんだけどあってる?
オブジェクト指向って自然な文法だな 3

318
デフォルトの名無しさん[sage]   投稿日:2017/04/24 06:42:37  ID:DtGFy1JY.net
キャットドア問題って何だよ
博識な俺様でも知らんぞ

319
デフォルトの名無しさん[sage]   投稿日:2017/04/24 19:56:51  ID:aju9PDoI.net
それを流行らせようとして必死なやつをどっかのスレで見たわ
放置推奨

320
デフォルトの名無しさん[sage]   投稿日:2017/04/24 20:17:16  ID:MN8pW2Am.net
なんだ
騒ぎ立ててるヤツが居るだけなのね

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

321
デフォルトの名無しさん[sage]   投稿日:2017/04/24 21:31:35  ID:Fbyj+dPJ.net
結局、キャットドア問題解決できなかったしね

322
デフォルトの名無しさん[sage]   投稿日:2017/04/25 10:33:30  ID:ibd4gvgd.net
>315
オブジェクト指向 "キャットドア問題"
9 件 (0.37 秒)

323
デフォルトの名無しさん[sage]   投稿日:2017/04/25 12:08:14  ID:5ILiyJO9.net
キャットドア問題が何を問題にしているのかわからない
合力できるように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
コメント3件

324
デフォルトの名無しさん[sage]   投稿日:2017/04/25 19:47:55  ID:sSL6z0RB.net
staticおじさんは今日も大勝利

325
デフォルトの名無しさん[sage]   投稿日:2017/04/25 20:11:32  ID:4og0+rzt.net
結局どんな勝負なの?
コメント1件

326
デフォルトの名無しさん[sage]   投稿日:2017/04/25 21:16:26  ID:qd1hD0YR.net(2)
>325
結局、キャットドア問題解決できなかったしね

327
[sage]   投稿日:2017/04/25 23:25:27  ID:RguWTiRy.net
キャットドアとやらが拠り所なのか…

328
デフォルトの名無しさん[sage]   投稿日:2017/04/25 23:46:03  ID:qd1hD0YR.net(2)
if cat door is open
human begining become
and we will we will goto heaven

329
デフォルトの名無しさん[sage]   投稿日:2017/04/25 23:57:29  ID:qaES5lmc.net
ごめん、それでは理解できない
どんな勝負だったの?
勝利条件やルールは何だったの?
コメント1件

330
[sage]   投稿日:2017/04/26 00:00:54  ID:R2CP97M0.net
何かの引用のもじりなんだろうか?
ひどい英語に見えるけどなんか意味あるのかな…

331
デフォルトの名無しさん[sage]   投稿日:2017/04/26 00:19:05  ID:9BTWZVlt.net
>329
逃げるのか?
コメント1件

332
デフォルトの名無しさん[sage]   投稿日:2017/04/26 00:35:26  ID:1c8kYD+M.net
ネコ用のドアって蚊やハエが入って来ないの?

333
デフォルトの名無しさん[sage]   投稿日:2017/04/26 06:46:17  ID:Ex4Hni8+.net(2)
>331
や、だから俺はそもそも勝負に参加してないっての
参加するにしても勝利条件とルールを聞いても誰も教えてくれないから参戦もできない
コメント1件

334
デフォルトの名無しさん[sage]   投稿日:2017/04/26 06:52:05  ID:LAzkzAvR.net(2)
>333
マヌケなヤローだ

335
デフォルトの名無しさん[sage]   投稿日:2017/04/26 07:00:16  ID:Ex4Hni8+.net(2)
ああ
これは会話させてくれないやつだ

放置推奨と言われた意味がやっとわかった
コメント1件

336
デフォルトの名無しさん[sage]   投稿日:2017/04/26 07:56:46  ID:LAzkzAvR.net(2)
>335
いいや、本スレに行って参戦宣言でもすれば即座に着火するよ
みんな内心納得してないからね

337
デフォルトの名無しさん[sage]   投稿日:2017/04/27 22:21:41
クラス階層をどう作るか、メソッドをどのオブジェクトに持たせるかっていう、大抵は主目的にならない部分の問題を、
現実世界の物理的な制約、言語学や分類学の観点から「〜であるべき」と主張しあうおバカな問題だよ>キャットドア問題
たまに出現してスレを白けさせる美少女クラス云々と同類。

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

338
デフォルトの名無しさん[]   投稿日:2017/04/28 12:21:14
それは抽象化ではないとだけ言っておこう

339
デフォルトの名無しさん[sage]   投稿日:2017/04/28 22:22:35
>337
おバカな問題だということが分からないやつがたくさんいるから
似非開発者をフィルタリングするのに便利だよ

340
デフォルトの名無しさん[]   投稿日:2017/04/29 00:17:16
頭が悪いという事実以外にどこに問題があるのか

341
デフォルトの名無しさん[sage]   投稿日:2017/04/29 01:10:48
まあな、お前らほど優秀な奴らがあの場にいたらキャットドア問題など発生すらしなかったんだろうなw

342
デフォルトの名無しさん[sage]   投稿日:2017/04/29 03:01:54
どんなに優秀なやつが居ても無理
自分の考えることが正解で他はダメみたいな考えしてるやつらの口論に出口はない

343
デフォルトの名無しさん[]   投稿日:2017/04/29 14:57:30
>323
俺はこんなコード書きたくないなあ
コメント1件

344
デフォルトの名無しさん[sage]   投稿日:2017/04/29 18:07:18
>343
お前が書かなくても>323が書いてお前に保守させるから問題ない
コメント1件

345
デフォルトの名無しさん[sage]   投稿日:2017/04/29 18:32:37
>344
> お前に保守させるから

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

346
デフォルトの名無しさん[sage]   投稿日:2017/04/29 22:20:18
>337
わかるわかる
美少女クラスがどうとかウンコがどうとか
そーいうので必死でレス稼いでる子がいるよな
自転車置き場議論の一端だよな
これならレスできる!って連中が集っちゃう

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

348
デフォルトの名無しさん[sage]   投稿日:2017/05/01 21:37:55
作業性?

349
デフォルトの名無しさん[sage]   投稿日:2017/05/01 21:59:16
我々生まれもって木構造が好きだから
クラス階層というもんのドキュメント性も何か
心惹いてたんだろうねえ
継承がもたらすポリモの便利さにくわえてね

350
デフォルトの名無しさん[sage]   投稿日:2017/05/01 22:04:47
実際、作業性なんだよ
作業性が良いと、仕事が早く終わるし、ミスも減るんだよ
そのために整理する仕事があるんだよ
どこの工場でもやっていることだ
工場に限らず仕事は全てそうではあるがな

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

351
デフォルトの名無しさん[sage]   投稿日:2017/05/01 22:12:12
まぁソフトウェアの設計といえば
どれだけの時間で処理が完了するか見積もったり
メモリ使用量を算出したり
そういう楽しいのはあるけども
OOはそういうのじゃ無いよね
OO設計は完全に整理整頓術以外の何物でもない
とりわけ、コードを、どこに、書くか、という問題
コメント1件

352
デフォルトの名無しさん[sage]   投稿日:2017/05/01 22:16:37
>351
普通にメンテナンス性、可読性、
複雑なものをシンプルにする技術とか
言えばよくね?

353
デフォルトの名無しさん[sage]   投稿日:2017/05/01 22:22:57
で、それって何?って言われれば
まとめて整理整頓術としか言いようがない

354
デフォルトの名無しさん[sage]   投稿日:2017/05/01 22:28:24
作業性って工場系の用語だと思うんけど定義を教えてくれ
作業のしやすさ=作業性?
それとも作業効率を高める性質=作業性?

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

355
デフォルトの名無しさん[sage]   投稿日:2017/05/01 22:51:43
> 整理整頓術

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

356
デフォルトの名無しさん[sage]   投稿日:2017/05/01 22:57:39
大体において、作業がしやすければ、作業効率は高まるもんなんだよ
ここで、ごく一部の例外とか、そういうのはどうでもよい
基本的な原則といって良いだろう
だから両方の意味でつかわれるし、両方同時に言ってるし
付け加えれば品質の意味も含まれる
作業しやすいほうが品質が上がるのは当たり前だからな

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

357
デフォルトの名無しさん[sage]   投稿日:2017/05/01 23:05:09
あと、整理整頓術も工場用語でも何でもないぞ

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

358
[sage]   投稿日:2017/05/01 23:10:42
工場での生産の作業性をぼんやりした形で適当に定義しないでほしいな。

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

359
[sage]   投稿日:2017/05/01 23:12:40
>357
お前が馬鹿なのか勘違いしてるのか、恣意的に混同してるのかわからんが、少なくともお前が言ってることが机上の崇高な理論で思想だよ。

360
デフォルトの名無しさん[sage]   投稿日:2017/05/01 23:15:56
>357
もうちょっと整理整頓して文章書こうな(藁干草)

361
デフォルトの名無しさん[]   投稿日:2017/05/01 23:17:09
吉野家は3件全立してると思ってた
コメント1件

362
[sage]   投稿日:2017/05/01 23:20:32
>361
高くはない、まずくはない、遅くもないものはなんとかなる。
その状態が、生産ラインの安定地点でもある。

363
デフォルトの名無しさん[sage]   投稿日:2017/05/01 23:46:27
>358
そんな細かな話は一切してない
彼方を立てれば此方が立たないって領域の話は、個々に対応する話であって
それ言い出すと、美女のウンコの話になる
つまり、対象とする要件がわからないのに、美女クラス作るのは無理
不毛だろ
ただ明らかに作業性の悪い状態で作業すると作業効率が落ちるのは確か
そのことしか言えない

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

364
デフォルトの名無しさん[sage]   投稿日:2017/05/02 00:18:05
POAやDOAは整理整頓術とは違うの?
整理整頓術は作業性を高めるためにあるとして
異なる整理整頓術があるのは重視してる目的が異なるからじゃないのか?

365
デフォルトの名無しさん[sage]   投稿日:2017/05/02 01:00:54
整理整頓じゃなくてモデリングだな
設計とも言う

366
デフォルトの名無しさん[sage]   投稿日:2017/05/02 04:16:06
オブジェクト指向って処理をソースのどこに書くかってだけの技術だしね
どんなにこねくり回しても直接的には1円にもならないんだよね
違うと認めないやつもいそうだけど
そろそろ自分が扱ってるモノの本質を見定めるべき
コメント2件

367
デフォルトの名無しさん[sage]   投稿日:2017/05/02 06:27:34
それをバカにしつづけた結果
メンテ不能なモンスターができあがり
ビジネスチャンスを逃す

368
デフォルトの名無しさん[sage]   投稿日:2017/05/02 08:01:47
>366
お前のその考えじゃ一円も生み出せないわな

369
デフォルトの名無しさん[sage]   投稿日:2017/05/02 08:32:01
>366
需要さえ見出せばいくらでもお金になるよ
小手先の技術より経済の本質を見定めればいいと思う

370
デフォルトの名無しさん[sage]   投稿日:2017/05/02 09:26:50
経済の本質?ロボットによる自動化かね?

371
[sage]   投稿日:2017/05/02 10:53:02
>363
個々に対応しない全体論なんてあるわけねえじゃん。
頭おかしいのか?

372
デフォルトの名無しさん[sage]   投稿日:2017/05/02 23:05:52
じゃあお前キャットドア問題解けるの?
コメント1件

373
[sage]   投稿日:2017/05/04 12:00:51
>372
次世代言語の前スレで単なるオブジェクト指向では無理でしょ的にGoで断片書いた。
コメント1件

374
デフォルトの名無しさん[sage]   投稿日:2017/05/04 13:02:33
>373
書いたじゃなくてその話をここでもう一度やれって言ってんだよ
コメント2件

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

376
デフォルトの名無しさん[sage]   投稿日:2017/05/04 14:19:13
>374
オレは>323に書いた
これだと駄目な理由を早よ書け
コメント1件

377
デフォルトの名無しさん[sage]   投稿日:2017/05/04 18:23:43
>376
323のプログラムは何の役に立つの?
コメント2件

378
デフォルトの名無しさん[sage]   投稿日:2017/05/04 19:20:07
>377
キャットドア問題が解けること

379
[sage]   投稿日:2017/05/04 20:17:32
砂上の楼閣が作れるスコップみたいな話か。

380
デフォルトの名無しさん[sage]   投稿日:2017/05/04 23:18:06
>377
分脈はおろかコードすら読めない奴がレスしてんじゃねーよ
コメント1件

381
デフォルトの名無しさん[sage]   投稿日:2017/05/04 23:44:26
>380
分脈!!

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

382
デフォルトの名無しさん[sage]   投稿日:2017/05/05 02:35:43
>381
さながらキミは文脈わかったつもり系か

383
デフォルトの名無しさん[sage]   投稿日:2017/05/07 08:39:23
文脈系男子は帰って

384
<塔eする役ね。成長はないけどまぁ食っていけてるならいいんじゃない。 []   投稿日:0000/00/00 00:00:00

385
デフォルトの名無しさん[sage]   投稿日:2017/05/24 21:18:50  ID:VdpFCLoQ.net
レッテル張りして、プンスカ怒ってるみたいだけど、そうとう図星だったか。
設計ミスるのも程々にしとき。

386
デフォルトの名無しさん[sage]   投稿日:2017/05/24 22:12:57  ID:krzOkTvb.net
>388
お前は設計ミスなんてしないもんな
なぜなら設計したことがないからw

387
デフォルトの名無しさん[sage]   投稿日:2017/05/25 00:25:16  ID:hLFywp3s.net
なんか、もういいや。建設的じゃねーし。

388
デフォルトの名無しさん[sage]   投稿日:2017/06/10 08:24:17  ID:F6bXk1dm.net(2)
オブジェクト指向言語って、構造体を拡張して作ったクラスに一事実一箇所の概念を持たせたものって認識で良いの?
コメント1件

389
デフォルトの名無しさん[sage]   投稿日:2017/06/10 08:30:29  ID:F6bXk1dm.net(2)
オブジェクトという概念を実現するために、構造体に操作を持たせただけなのに、古い人が構造化プログラムから転向できないのは何でだろう

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

390
デフォルトの名無しさん[sage]   投稿日:2017/06/10 10:15:22  ID:DbYsfAwS.net
>392
多くの人にはドメインのモデリングが難しいから
手続きを箇条書きする方が簡単だから
構造体がわかることと構造体を組み合わせて大きなシステムを構築できることは別物だから

391
デフォルトの名無しさん[sage]   投稿日:2017/06/10 11:08:36  ID:jC/WmgTy.net(2)
古い人もオブジェクト指向が理解できないわけではないんだろうよ
ただ、今までそれなりに書いてきてて
要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
あと、オブジェクトに着目するって発想がアホっぽくて嫌だとかかな
若い人は何も考えないからそのまま受け入れるかもしれないが
それなりの経験を積んできた大人からしたら
こういったアホっぽい発想に拒否反応が出ても仕方がないんじゃないかな

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

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

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

393
デフォルトの名無しさん[sage]   投稿日:2017/06/10 11:52:51  ID:0hQR51Tt.net
おっさん主導プログラミング
は根性駆動

394
デフォルトの名無しさん[]   投稿日:2017/06/10 15:17:22  ID:QncEdRe9.net
この業界はKKD法のシェアが一番
コメント1件

395
デフォルトの名無しさん[]   投稿日:2017/06/10 19:33:42  ID:cjBRJJZZ.net
根性って大切なんやで

396
デフォルトの名無しさん[sage]   投稿日:2017/06/10 19:48:23  ID:IZ7Qtzr9.net
大事かも知れんがそれで全部解決させようとするのは愚行すぎる

397
デフォルトの名無しさん[sage]   投稿日:2017/06/11 09:44:55  ID:odJVzTG1.net
オブジェクト指向を理解した上で採用しないオジサン居るのかな

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

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

398
デフォルトの名無しさん[sage]   投稿日:2017/06/11 12:07:19  ID:VhSPGZPs.net
>400
構造化もDOAも本当は理解してないから無理

399
デフォルトの名無しさん[]   投稿日:2017/06/11 15:04:37  ID:qjl5AbWq.net
構造化という言葉の意味を知らないとしても、いまどき構造化プログラミングから外れるようなコードってあまり見ないよね。

400
デフォルトの名無しさん[sage]   投稿日:2017/06/11 17:13:48  ID:djSLYxcn.net
構造化プログラミングは人類の至宝
制御構造、サブルーチン、ブロック
こんな大事なもんほかにあるか?
コメント1件

401
デフォルトの名無しさん[sage]   投稿日:2017/06/11 17:15:43  ID:xLXJwyhz.net
正しい名前付けとディレクトリ構造の方が重要

402
デフォルトの名無しさん[sage]   投稿日:2017/06/11 19:45:41  ID:rkOEfbG/.net
俺は>403に賛成なんだけど
面白いのは>403のように、動き、動詞、メカニズムに拘る人もいれば
>404のように、名詞、物体、に拘る人も居るってことだな

403
デフォルトの名無しさん[sage]   投稿日:2017/06/13 00:06:13  ID:vFhinRVt.net(3)
>394-395
意見について反対は無いが、俺の例で言うと、

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

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

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

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

ところでlinusってOOPさせないのか?知らんかった。
コメント1件

405
デフォルトの名無しさん[sage]   投稿日:2017/06/13 00:18:29  ID:8xDXZ/6F.net
せいぜい数十行のコードを書いて、あのメジャー言語よりみじけー!とか言って喜んでるのが関数型にわかだよ

406
デフォルトの名無しさん[sage]   投稿日:2017/06/13 00:53:29  ID:vFhinRVt.net(3)
ちなみにググッたら簡単に出てきた。結構有名みたいね。
https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html

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

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

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

407
デフォルトの名無しさん[sage]   投稿日:2017/06/15 07:29:14  ID:wue7VEQW.net
>403
オブジェクト指向は構造化プログラムを別に否定してないよね

408
デフォルトの名無しさん[sage]   投稿日:2017/06/15 10:19:37  ID:wH8Q5BS8.net
俺は本人じゃないが、そもそも元の文章は
オブジェクト指向は構造化プログラムを否定している
とは言ってなくね?
コメント1件

409
デフォルトの名無しさん[sage]   投稿日:2017/07/11 19:51:06  ID:ipR8z5Od.net(3)
状態によって実行できるメソッドが異なるクラスってどう実装する?
実直に実装すると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を投げるようになるだけで本質的な解決策にならない

410
デフォルトの名無しさん[]   投稿日:2017/07/11 20:01:43  ID:8ipoG7uk.net
状態によって実行できるメソッドが異なるクラスって実装しない

411
デフォルトの名無しさん[sage]   投稿日:2017/07/11 20:04:44  ID:ir0k8ftd.net
Stateパターンつうのはこの場合
キャンセル、保留中、決定済み
これらそのものをオブジェクト化して置き換えて運用するんじゃないんけ

412
デフォルトの名無しさん[sage]   投稿日:2017/07/11 20:29:26  ID:ipR8z5Od.net(3)
>414
その場合もorderからorder_stateに移譲するだけだから結局、例外出すだけのメソッドにならない?
コメント2件

413
[。sage]   投稿日:2017/07/11 20:52:36  ID:atBExrFz.net
>412
値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは?
値は値なんだし。
値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
しかも、何かさせられない状態すら持ってる。これヤバい。
何かさせられない、の定義が変わったとき過去データの扱いとかどうなるのか、すごい慎重にクラス作らないといけなかったり色々辛いと思う。

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

414
デフォルトの名無しさん[sage]   投稿日:2017/07/11 22:47:27  ID:ipR8z5Od.net(3)
>416
う〜ん
オブジェクト指向でやるか関数型でやるかは人それぞれだと思うので深入りしないでおく

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

415
デフォルトの名無しさん[sage]   投稿日:2017/07/12 00:06:27  ID:iO19g1+a.net(4)
interface IOrder
CanceledOrder implements IOrder
DecidedOrder implements IOrder

CanceledOrder cancel(DecidedOrder o) {}

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

416
[。sage]   投稿日:2017/07/12 12:04:37  ID:xgpaRPlM.net(2)
>417
関数型に見えるけど全然関数型じゃないよ。
オーダーってなんぞとモデル化した時に、
伝票と伝票処理する経理の人を浮かべただけ。

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

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

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

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

417
デフォルトの名無しさん[sage]   投稿日:2017/07/12 13:06:12  ID:ahqaJGrL.net
状態によってメソッドが異なるというのがオブジェクト指向と合わない気がするね
メソッドを呼ぶ側がオブジェクトの状態を気にするのは変だし
コメント1件

418
[。sage]   投稿日:2017/07/12 18:15:25  ID:xgpaRPlM.net(2)
>420
うん。もしくは、モデル化に失敗してる。
正確には、メソッドは呼んでもいいし、そこで例外を出しても良いけど、だいたいそういうのはトランザクションチェックとかになると思う。
掴んでるOrderが最新でなければどの行為も全てできない事、とか。
履歴が必要な類のシステムはそんな感じかと。

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

419
デフォルトの名無しさん[sage]   投稿日:2017/07/12 18:33:52  ID:zMmPnBY/.net
>412
> 状態によって実行できるメソッドが異なる

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

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

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

420
デフォルトの名無しさん[sage]   投稿日:2017/07/12 18:35:12  ID:LVxqEvY9.net
認可を各Modelに入れ込もうとするからややこしくなる
コメント1件

421
デフォルトの名無しさん[sage]   投稿日:2017/07/12 20:09:14  ID:P9HuPwNV.net(2)
とりあえず認可の話ではない
サービスレイヤーで認可を済ませた後
オブジェクトの内部状態によって呼べる呼べないを判断する
orderedのorderをdecideすることはできないしpendingのorderをcancelできないという事実に権限は関係ない
orderedのorderをcancelできるのは誰だといった問題は別のところで行う
orderは短い例であって実際の業務ではorderではないし状態数はもっと多い(5〜10程度)
それぞれの状態で実行できないメソッドが1つ以上ある
コメント3件

422
デフォルトの名無しさん[sage]   投稿日:2017/07/12 20:13:58  ID:P9HuPwNV.net(2)
すると、状態を確認して例外を投げる、という定型的なコードをあちこちに書くことになって精神衛生上良くない
Stateパターンを使えばクラス内部の定型文は排除できる
しかしその場合でもクラスの利用者が、状態を確認してメソッドを呼ぶ、という定型文を書くことを避けられない

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

423
デフォルトの名無しさん[sage]   投稿日:2017/07/12 20:25:05  ID:uz/DDJsp.net
お伺いを立ててからご用立てする社会みたいでめんどくさいな
よろしく!って軽い気持ちでブン投げたいわ

424
[。sage]   投稿日:2017/07/12 21:55:26  ID:LW66+r5t.net(2)
>424
だから、それぞれの状態で呼べる呼べないを判断するのは権限によるチェックと同じレベルの、ロジックであって、例外ではないじゃんって。
認可の話じゃないなら、Not Supportedはもっと違う。サポートされて無いんじゃなくて、その処理は許されてないから、サポートされてないんでしょ?

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

425
デフォルトの名無しさん[sage]   投稿日:2017/07/12 22:07:18  ID:iO19g1+a.net(4)
ワインゴの神設計コードをミロや


CanceledOrder implements IOrder
DecidedOrder implements IOrder

CanceledOrder cancel(DecidedOrder o) {}
コメント1件

426
デフォルトの名無しさん[sage]   投稿日:2017/07/12 22:10:26  ID:iO19g1+a.net(4)
まちがえたンゴ
こうンゴよ
どうンゴ?


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

interface IOrder {
public showOrder(){}
}

427
[。sage]   投稿日:2017/07/12 22:14:21  ID:LW66+r5t.net(2)
>429
Decidedで、かつ、何らかの理由でCancelに失敗した時、cancelがCancelledOrder帰してると詰む。

428
デフォルトの名無しさん[sage]   投稿日:2017/07/12 22:42:58  ID:iO19g1+a.net(4)
>430
それはどう考えてもthrows イレーガル何とかやろ
全部のOrderにisCancelSucseeded()やisValid()生やすおつもりか?

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

430
デフォルトの名無しさん[sage]   投稿日:2017/07/13 10:11:19  ID:ZjMlxgk7.net(3)
>424
> とりあえず認可の話ではない

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

431
デフォルトの名無しさん[sage]   投稿日:2017/07/13 11:36:43  ID:wYgqTfnm.net
>424
> オブジェクトの内部状態によって呼べる呼べないを判断する

ここで「判断」するのは誰(いつ)?

コンパイラ(コンパイル時)? ランタイムシステム(実行時)? オブジェクト自身(コール後)?
コメント1件

432
[。sage]   投稿日:2017/07/13 12:43:36  ID:gzfFo6hj.net(4)
>433
認可の話だよ。認可と「呼べる呼べない」は、本質的には同じだと言うとる。
「呼ばせられる、呼ばせられない」なんだから。
だから、データになるオブジェクト側が制御するのは悪手。相手方を意識しないと判断できないものを、相手方を持たないものが持つべきではない。

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

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

433
デフォルトの名無しさん[sage]   投稿日:2017/07/13 13:10:35  ID:ZjMlxgk7.net(3)
正直、日本語が下手すぎて、何を言いたいのかよくわかりません
コメント1件

434
[。sage]   投稿日:2017/07/13 18:08:28  ID:gzfFo6hj.net(4)
>436
要は、データはデータらしくしてろ、と。
伝票がペンを跳ね返すような真似すんな、書けていい。
単に正しい人間が正しく書いてない伝票が無効になるだけだ。書く書かない、書ける書けないは人間の問題だ。
って言ってる。

435
デフォルトの名無しさん[sage]   投稿日:2017/07/13 18:17:34  ID:CkZVVlnY.net(2)
interface使えばいいだけの話

436
デフォルトの名無しさん[sage]   投稿日:2017/07/13 18:22:51  ID:ZjMlxgk7.net(3)
>437
「注文が発送済みになったらもうキャンセルできない」は誰が判断すべきだということですか?
・注文自身
・キャンセルしようとした人
・その他
コメント1件

437
デフォルトの名無しさん[sage]   投稿日:2017/07/13 21:03:59  ID:B/Be78nl.net
>439
お前ほんと筋が悪いなぁ
コメント2件

438
デフォルトの名無しさん[sage]   投稿日:2017/07/13 21:50:56  ID:x/yyf+sv.net(2)
「保留中だとキャンセル出来ない」を認可の話と認識してしまうのはちょっとおかしい
「99レベルだとレベルアップ出来ない」を認可の話と認識してしまうのと同じようなものだよ
認可ってのは「申請者本人とスーパーユーザーは申請済みの注文書をキャンセルできる」とか「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」とかそういうこと

439
デフォルトの名無しさん[sage]   投稿日:2017/07/13 22:53:37  ID:CkZVVlnY.net(2)
言葉はわかりづらいので数学で示して
コメント2件

440
[。sage]   投稿日:2017/07/13 23:49:06  ID:gzfFo6hj.net(4)
>439
その他。
注文に対する処理を行うロジック。

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

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

441
デフォルトの名無しさん[sage]   投稿日:2017/07/13 23:56:23  ID:x/yyf+sv.net(2)
>443
もうめちゃくちゃだな
そのうち100円と20グラムを足し算できないのも権限の問題とか言い出しそうだ
コメント1件

442
[。sage]   投稿日:2017/07/14 08:44:22  ID:vN8eqjVV.net(3)
>444
それは逆に聞くが、各ステータスのOrderは100円と20グラムくらい違う単位系のアイテムなの?
足せないなら、それはデータ同士の問題でオペレーターの問題じゃない。

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

443
デフォルトの名無しさん[sage]   投稿日:2017/07/14 10:07:17  ID:RXZ2Hg3X.net(3)
>443
一貫性がないんじゃないの?

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

>443
> 注文に対する処理を行うロジック。
コメント1件

444
デフォルトの名無しさん[sage]   投稿日:2017/07/14 10:27:40  ID:RXZ2Hg3X.net(3)
まぁ、オブジェクト指向としては>424が正解だと思うんだが、なんで話が紛糾するのかわけわからんわ
コメント1件

445
[。sage]   投稿日:2017/07/14 11:07:29  ID:vN8eqjVV.net(3)
>446
人間の問題、の「人間」はそれぞれの操作をするオブジェクトのメタファだと理解してる?
だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
各「操作するオブジェクト」全部に同じ処理書く訳であるまいし。

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

446
デフォルトの名無しさん[sage]   投稿日:2017/07/14 13:29:02  ID:Wh3H5+5v.net
>448
> 古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃない

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

http://aokilab.kyoto-su.ac.jp/documents/MVC/page3.html
コメント1件

447
デフォルトの名無しさん[sage]   投稿日:2017/07/14 14:07:38  ID:OzYQCoXg.net
だな。ロジックにもいろいろあるが、
ビジネスロジックはMに入れるけど。
コメント2件

448
デフォルトの名無しさん[sage]   投稿日:2017/07/14 16:10:22  ID:RXZ2Hg3X.net(3)
>448
> だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
「注文書自体の状態を変える」主体が誰/何かを聞いているのではなくて、できるかできないかの判断は誰/何がすべきですかという質問です

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

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

449
[。sage]   投稿日:2017/07/14 19:32:40  ID:vN8eqjVV.net(3)
>449
確かに。smalltalkとイベントと言われたらモデルが持つべきか。
しかし、決定とキャンセルをモデルが勝手に自分で判断するのはちょっと素直に納得できんな。

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

450
デフォルトの名無しさん[sage]   投稿日:2017/07/14 20:52:39  ID:TBQIVSbV.net
拗らせちゃった感あるな

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

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

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

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

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

どう設計する?

451
デフォルトの名無しさん[sage]   投稿日:2017/07/14 23:21:15  ID:MTLV3Z4y.net
TodoTask型
DoingTask型
DoneTask型
を定義しろ
func(task : TodoTask)
にDoneTaskを渡そうとしたらコンパイルエラーで弾ける
これがオブジェクト指向だ
コメント1件

452
デフォルトの名無しさん[sage]   投稿日:2017/07/14 23:43:22  ID:iN4cnX21.net
>453
TODO以外の時にBeginTaskを実行するコードはコンパイルエラー?
コンパイルは通るけどコールする前に実行時エラー?
コンパイルもコールもできるけどオブジェクトが実行時エラー?(あるいは黙殺?)
コメント1件

453
[。sage]   投稿日:2017/07/15 15:14:08  ID:l4jBJff8.net
無駄過ぎるだろ。
結局そのタスク同士を変換(処理)する奴は、別のアクターでしょ
コメント1件

454
デフォルトの名無しさん[sage]   投稿日:2017/07/15 15:50:44  ID:MQgunk1n.net
public class TaskService : ITaskService {
private IRepository<Task> _tasks;
public TaskService(IRepository<Task> tasks) { _tasks = tasks; }

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

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

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

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

455
デフォルトの名無しさん[sage]   投稿日:2017/07/15 21:56:19  ID:rZ7c1Y9a.net
>457
気持ち悪いシンタックスだな
何言語?
てゆーかガイジ?

456
デフォルトの名無しさん[sage]   投稿日:2017/07/16 02:42:35  ID:1fICcUqx.net
>458
Javaしか知らない人には気持ち悪く見えるのかな??

457
デフォルトの名無しさん[sage]   投稿日:2017/07/16 03:08:15  ID:qSnPeHti.net(2)
>458
ガイジキタ━━━━(゚∀゚)━━━━!!
コメント1件

458
デフォルトの名無しさん[sage]   投稿日:2017/07/16 10:47:57  ID:ldCi3V7A.net
ScalaでもKotlinでもないよね
GaijiLangか?
コメント2件

459
デフォルトの名無しさん[sage]   投稿日:2017/07/16 10:51:14  ID:RX5Mjx4x.net(3)
c#

460
デフォルトの名無しさん[sage]   投稿日:2017/07/16 10:52:29  ID:e3NckIIY.net
C#じゃね?

461
デフォルトの名無しさん[sage]   投稿日:2017/07/16 11:01:10  ID:Unh0LZY1.net(3)
言いたいことはわからんでもないが、

>452
> 注文という行為は正常に行われたけど、在庫が無くて注文の確定は行われなかった
とか書かれると、こいつ何言ってんだ感が増す

462
デフォルトの名無しさん[sage]   投稿日:2017/07/16 11:34:00  ID:nvinih80.net(5)
今どきprivateを_ってどうなの
メソッド名頭大文字ってどうなの
それがC#流なの?

463
デフォルトの名無しさん[sage]   投稿日:2017/07/16 11:40:36  ID:nwmbN5p0.net(2)
>465
巣に帰りましょうね

464
デフォルトの名無しさん[sage]   投稿日:2017/07/16 11:45:59  ID:qSnPeHti.net(2)
>465
だから何?
コメント1件

465
デフォルトの名無しさん[sage]   投稿日:2017/07/16 11:48:22  ID:nvinih80.net(5)
M$のケツ穴舐めて忠誠を誓うような糞言語は使いたくないね
コメント2件

466
デフォルトの名無しさん[sage]   投稿日:2017/07/16 11:56:53  ID:6w5BkJrH.net
特定の会社の言語を使うだけで忠誠って大袈裟だなぁww

467
デフォルトの名無しさん[sage]   投稿日:2017/07/16 11:59:04  ID:nwmbN5p0.net(2)
君はそれでいいよ
バイバイ

468
デフォルトの名無しさん[sage]   投稿日:2017/07/16 12:00:26  ID:nvinih80.net(5)
ウィン鯖にチンパンジーのアイアイエスでM$にライセンス料払うのウレピィィイしてろ奴隷
コメント1件

469
デフォルトの名無しさん[sage]   投稿日:2017/07/16 12:07:46  ID:HsIBOF22.net
>471
たまにでいいから知識をアップグレードしたほうがいいぞ

470
デフォルトの名無しさん[sage]   投稿日:2017/07/16 12:32:39  ID:RX5Mjx4x.net(3)
>468
日本のケツ舐めて忠誠を誓ってるから日本語使ってるんだね!
すごいね!!

471
[sage]   投稿日:2017/07/16 12:50:28  ID:v455lTXc.net(3)
>464
変な言い方になったのは認めるわ…。
注文のトランザクションと、注文行為のトランザクションは別では、と言う感じ。
そこを疎にしておくと負荷上がってきたときに分割しやすいし、データの不整合起こしにくいし、不整合起きちゃった時に原因探しやすい。
注文行為自体はいくらでも上げれるけど、確定していくのはジョブが全部対応するとか。

物のオーダーじゃないけどオーダリングシステムでそういうの作ったときは、すべてのオペレーションはすべてジョブコントローラーへのキューイングで、結果はジョブコントローラーに全部に作らせてた。
コメント1件

472
デフォルトの名無しさん[sage]   投稿日:2017/07/16 13:01:42  ID:nvinih80.net(5)
>472
なになに
シーシャーパーのポジトーーーーーク始まっちゃう?
何が間違ってるか具体的に言ってみろよ




言えるもんならなw

473
デフォルトの名無しさん[sage]   投稿日:2017/07/16 13:06:11  ID:ZuJ+SqAA.net
>475
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ?

474
デフォルトの名無しさん[sage]   投稿日:2017/07/16 13:48:09  ID:nvinih80.net(5)
>476
ブーメラン自分の頭に突き刺して楽しいか?

475
デフォルトの名無しさん[sage]   投稿日:2017/07/16 14:20:49  ID:RX5Mjx4x.net(3)
>477
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ?
コメント1件

476
デフォルトの名無しさん[]   投稿日:2017/07/16 14:29:18  ID:u/+2FOpe.net
発注はしたけど受注は出来なかったって言いたいのだろうが
コーダーって一般常識がないからこういう些細なとこで詰んじゃうよね
コメント1件

477
デフォルトの名無しさん[sage]   投稿日:2017/07/16 14:32:34  ID:ksC8m8Yx.net
サンプルに粘着して延々と揚げ足取りする人って根本的な要件を理解する能力が著しく欠如してるんだろうね
判断力が必要な仕事を任せられないタイプ
コメント1件

478
[sage]   投稿日:2017/07/16 14:41:15  ID:v455lTXc.net(3)
>479
違うよ。

479
デフォルトの名無しさん[sage]   投稿日:2017/07/16 14:49:02  ID:TnyT7/ON.net
オブジェクトの状態管理に限界を感じた僕は状態を廃止してイベントを定義するのであった
コメント1件

480
[sage]   投稿日:2017/07/16 14:53:20  ID:v455lTXc.net(3)
注文って言葉が動詞にも名詞にもなるから話が散らかるんだが、
受注に対するのは発注でしょ。
発注も受注もキューイングする処理として作って、その可否はジョブが判断する。

名詞の方の注文は、独立して存在してて、それはジョブが淡々とキューされた処理に従って処理してったり、トランザクションエラーならそうマークしていく。
どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。

481
デフォルトの名無しさん[sage]   投稿日:2017/07/16 15:31:34  ID:J7GQwUvr.net(20)
>483
君がコマンドのキューイングが好きなのは伝わったけどそれ今は全く関係ないよ

そしてそもそもお題は認可の話じゃない
ドメインモデルに定義された不変条件の話をしているんだよ

不変条件を担保するのはドメインモデルの仕事であって認可システムじゃない
誰が何をできるかを管理するのが認可システムの仕事だ

君が大好きなジョブ(トランザクションスクリプト)の場合に当てはめても根本的なところは同じね
データの不変条件を担保するのはジョブの仕事
この場合でも誰が何をできるかは認可システムの領分だ

君の間違いは不変条件と認可という全く異なる次元の話をごちゃ混ぜにして一箇所で管理しようとしたことだよ

482
デフォルトの名無しさん[sage]   投稿日:2017/07/16 15:46:04  ID:J7GQwUvr.net(20)
認可システムを取り除いた状態のシステムを考えて欲しい
ゲストユーザーも一般ユーザーも特権ユーザーも存在しない
誰であっても全てのサービスを実行することができる

ならばこのシステムは全てのデータを自由に書き換えられるのか?
そうではないだろう
認可処理が全くないからと言ってなんの統制もなくデータを書き換えればすぐにデータは矛盾して壊れてしまうはずだ

認可とは別次元で「こういう場合にはこういう処理はできない」といった条件が存在しなければシステムが崩壊してしまう
この条件のことを我々の業界では不変条件などと呼んでいる

不変条件と認可は全く関係なく分離して扱える2つの世界だ
これを一緒くたにジョブなどと曖昧な名前をつけて管理してはいけない
不変条件は不変条件、認可は認可
これらは分けて管理しないとすぐに混乱してしまう

483
[sage]   投稿日:2017/07/16 16:28:44  ID:bf3wtQLD.net(3)
>484
うーん、認可って言葉に随分気持ちが持ってかれてるように見えるけど、
その不変条件自体が、システムの整合性を保つために設計者によって行われた「認可」そのものではないの?
ACLではない、と言いたいんだろうけど、俺の言ってるのもACLそのものじゃない。

>485
認可条件が全くないなら、システムは崩壊する、
システムが崩壊しないならば、認可条件は全くなくは無い、
と対偶取っても大丈夫なように、
不変条件自体が、システムから与えられた認可なんよ。
しかも、不変条件は変更できない、という不変条件でいとも簡単に実装できる。

ジョブとかタスクがあるようなシステムでシステム作った事無いのかな?
コメント2件

484
[sage]   投稿日:2017/07/16 16:54:43  ID:bf3wtQLD.net(3)
ジョブと名前を付けてジョブで管理してるってどういう事かまだイマイチわからん。

ジョブはジョブで、巨大で膨大なキューが積まれるようなシステムでもない限り2つも3つも立てない、むしろ立てたらロック周り辛くなるからやりたくない、いわゆるジョブなんだけど。

ジョブは、一つのキューに対して、一つのアトミックな操作をする。その入力がオーダーとオペレーションの組み合わせで、そのオーダーとオペレーションによって、処理を行う、行わない、エラーにする、と処理をして、新しい状態のオーダーを記録する。
ただそれだけ。

シングルユーザでも同じ設計でやっとったがなぁ。

ってか書きながら思ったけど、今JSの世界で流行ってるReactのデータ周りそっくりだな。
コメント1件

485
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:04:33  ID:J7GQwUvr.net(20)
>486
認可ではない
もしかして言葉が悪いのかな
「できる/できない」と表現すべきではなかったか
認可は「して良い/してはいけない」だな
して良い/していけないとは全く別の次元で、そもそもその処理そのものが成立するかしないかという判定があるだろう
それがモデルの不変条件だ
100円に20グラムを足すような処理は権限に関わらず成立しない
発注していない注文をキャンセルする処理は権限に関わらず成立しない

認可がなくてもシステムは成立する
全員が全ての機能を使用できるだけ
実際そういうシステムはいくらでもあるし作れるよ

認可がないとシステムが崩壊すると君が認識する理由はね
君の作るシステムは認可と不変条件がごちゃ混ぜになっているからだよ
コメント1件

486
[sage]   投稿日:2017/07/16 17:15:57  ID:bf3wtQLD.net(3)
>488
処理が成立しない事を、行っても良い、のであれば「認可ではない」と認めざるを得ないが、
「処理が成立しないからその処理を行うことは無い」のであれば、
処理を行うことがない理由は、「処理が成立しないから行ってはいけない」だけの話じゃん。
事実としては、100円に20グラムをどうしても足したいなら、そのロジック作るしかないんだから、もはやその置き場所が無いモデル化は余計に間違ってるとしか言い様が無いわ。
2ダース足して1個引くとか、単位系読み替え程度ならいくらでもホントにあるしな。
コード××100mgにコード○○を1アンプル足したものとかザラ。

俺のシステムは崩壊しないよw
そっちが「崩壊する」と言うから、対偶を取って見せただけなんだけど。

ごちゃまぜどころか、不変条件なのに変えなければいけない事すらあるんだから。運用では。
だから、不変条件は変更できない、なんて自己言及して定義してあるんだよ。

勝ちたいだけならもうやめとけよ。哀れだから。
コメント2件

487
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:23:09  ID:J7GQwUvr.net(20)
>487
わかってるよ
リクエストを受け取るとデータと処理のペアをキューイングする
ジョブがキューをポーリングして実際の処理を行う
っていう古臭いシステムの話でしょ

ぜんっぜん関係ないよね
キュー使おうがイベント使おうがAwait使おうが直列に処理しようが並列に処理しようが今の話題にとってはどうでもいいでしょ

488
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:28:10  ID:Unh0LZY1.net(3)
>483
> どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。
「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」をごっちゃにするなって
みんな言ってるのに、まだわからないかな
コメント1件

489
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:39:04  ID:J7GQwUvr.net(20)
>489
成立しないから行なっては「いけない」のではなくて
成立しないから行うことが「不可能」な

100円に20グラムを足すことは不可能なので実行しようがないので権限の問題ではない

ダースと個数は可換なので足し算引き算を定義することが「可能」で誰であっても実行「可能」だ
しかしそういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている

コードxx100mgにコードyyを1アンプル足すは「足す」の意味から違うじゃん
化学計算的な意味での足すじゃなく薬液を混ぜるの意味での「足す」
あるいは注文カートにxxとyyを足すといったようなパッケージング処理の「足す」
などそういった意味で「足す」だろう
そう意味での「足す」は実装可能で誰でも実行「可能」だ
そういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている

君のシステムは崩壊目前なので一度誰かにレビューしてもらった方がいい

490
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:40:22  ID:7YnVXBSW.net(17)
> 「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」をごっちゃにするなって

どの状態=ログインしているアカウントの状態
と考えれば、同じこと
コメント1件

491
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:50:14  ID:7YnVXBSW.net(17)
>486
> その不変条件自体が、システムの整合性を保つために設計者によって行われた「認可」そのものではないの?

違う。例えば構文が正しい場合のみコンパイラはコードをコンパイルするが
これは「コードが正しいと認可した」などとは言わない。
日本語の問題。日本語が間違っている。
コメント1件

492
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:52:11  ID:J7GQwUvr.net(20)
>493
それはアカウントと他のものをごちゃ混ぜにした考え方
まずはそれを分離して考えてくれ
アカウントのできるできないと他のもののできるできないは別に考えよう
その上で今はアカウントの話をしてないのでそっちについては忘れよう
ただそれだけなんだけどなんでわからないかなぁ
コメント1件

493
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:53:47  ID:7YnVXBSW.net(17)
呼んではいけないメソッド
存在しないメソッド
使用が許可されてないメソッド
バグが有るメソッド

どのメソッドであっても(コンパイルエラーにならない場合は)
実行エラーになるが、その全てが認可エラーではない。

実行した結果、認可エラーになるものはあるが、
それは実行時エラーの特殊な場合

実行時エラーを継承して認可エラーを作るのであって
認可エラーを継承して、その他の実行時エラーを作るわけではない
コメント1件

494
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:54:20  ID:J7GQwUvr.net(20)
そのうちE = mc^2はアインシュタインが認可した法則だ
などと言いだしそうだなこいつ

495
デフォルトの名無しさん[sage]   投稿日:2017/07/16 17:58:03  ID:7YnVXBSW.net(17)
>495
「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」
この2つを分離するのは間違ってる。

どの状態?という、大きな枠組みとして状態のチェックが有り、
 その状態チェックの中の一つとして
  ・数字チェック
  ・範囲チェック
  ・整合性チェック
  ・権限チェック

などがある。

誰が何をできる/できないというのも、
状態のチェックにすぎない。

496
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:06:19  ID:7YnVXBSW.net(17)
もちろん、100円に20グラムを足すことは不可能とかいうのは
状態のチェックじゃないぞ。


まあ無理やり考えれば、あるオブジェクトがあって、
そのオブジェクトが数値だけではなく単位まで状態として持っているのであれば、
オブジェクトとオブジェクトの加算で状態(単位が同じであること)と
みなすことも可能だがねw

497
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:08:20  ID:J7GQwUvr.net(20)
>498
つまり内容はともかく全部チェック処理だからチェック処理というグループを作ってそこにまとめてぶちこめ
権限のチェックもオーダーの状態のチェックも単位系のチェックも全てチェック処理だからチェック処理のグループでまとめて考えろ
そういうことを言いたいのか?
コメント1件

498
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:11:01  ID:7YnVXBSW.net(17)
>497
そういうこと。

カッコつけて「認可」なんて単語を使ってるのが悪い。
単に「状態チェック」と言えば良いんだよ。


状態チェックの中の一項目として認可が存在する。

なのに状態チェックを認可なんて
カッコつけて呼ぶから、みんなから突っ込まれてる。


ドヤ太郎「引数が数字であることを認可する!」
コメント1件

499
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:13:20  ID:J7GQwUvr.net(20)
>499
芝を付けるようなおかしな話か?
単位系を付けるパターンは珍しいことではない
特に金を扱うシステムで国際化する場合には量と単位を持ったお金クラスの使用は必須と言ってよい
プリミティブクラスをクラスでラップしろというプラクティスはあまりにも有名だが
それはこういった単位と量の取り扱いをより厳密に実践せよということだぞ

500
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:14:14  ID:7YnVXBSW.net(17)
>500
> チェック処理のグループ
チェック処理のグループってなんだよw


何かの処理(メソッド)を実行した時、
それが実行可能かどうかチェックするってだけだろ
その内容なんてどうでもいいわw


俺が言ってるのは実行可能かチェックすることを
「認可」って名前で呼ぶなって言ってるだけ

501
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:16:13  ID:7YnVXBSW.net(17)
>502
お前が言ってるのはドルや円といった変換可能な単位の話だろ
俺が言ってるのは、円やグラムといった変換可能ではない単位の話だ
コメント1件

502
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:19:22  ID:J7GQwUvr.net(20)
>501
そっち側から突っ込んでるの1人だけだぞ
みんなって…?
コメント1件

503
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:21:05  ID:J7GQwUvr.net(20)
>503
認証・認可はセキュリティに関わる事項
特別扱いするには十分な理由で常識だ
君の発言はシステム開発に関わる人間の発言とは思えない

504
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:24:33  ID:7YnVXBSW.net(17)
>506
セキュリティに関わるから
特別扱いするのはなぜでしょうか?
コメント1件

505
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:25:50  ID:7YnVXBSW.net(17)
特別扱いするというのなら、
セキュリティに関する部分は
単純な比較命令や条件分岐命令を使うのではなく
専用の機能を使うべきでしょう?


でも、コードからすれば何ら特別扱いは
されていませんよね?

506
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:40:06  ID:J7GQwUvr.net(20)
>507
セキュリティ事故を起こすと金もかかるし信用も失う
君も新人研修で習っただろ?
そんなバカバカしい疑問が出るってことは学生さんか?
コメント1件

507
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:42:18  ID:J7GQwUvr.net(20)
>508
君のコードからは特別扱いされてないだけ
認証・認可はそのためのモジュールで取り扱うのが一般的です
コメント1件

508
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:43:47  ID:7YnVXBSW.net(17)
>509
だからなんなんだよw

お前が言ってるのは重要なチェック処理と
重要でないチェック処理があるってだけの話だろ?

俺はどちらもやってることはチェック処理に
すぎないって言ってるだけ
コメント1件

509
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:43:48  ID:J7GQwUvr.net(20)
>504
可換不可でも発想は同じ
100円オブジェクトと20グラムオブジェクトを足そうとしたら実行時エラーないしその前にコンパイルエラーだ
コメント1件

510
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:44:50  ID:7YnVXBSW.net(17)
>510
> 認証・認可はそのためのモジュールで取り扱うのが一般的です

そのモジュールを使えば、メソッド一つでチェックできるようになるんだろう?

511
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:46:02  ID:7YnVXBSW.net(17)
>512
お金100円オブジェクトと金20グラムオブジェクトを足そうとしたら
価値がでるかもしれないぞ?
コメント1件

512
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:47:23  ID:J7GQwUvr.net(20)
>511
文字列のパターンマッチ検証と
認証サーバーへの問い合わせ
が君の目には同じ処理に見えるってことか?
世界観が違いすぎて会話が成立しないんだけど
コメント1件

513
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:50:37  ID:7YnVXBSW.net(17)
> セキュリティ事故を起こすと金もかかるし信用も失う

東証の誤発注事件、セキュリティとは関係なかったよなw

セキュリティでなければ、お金や信用は失わないと?

514
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:50:54  ID:J7GQwUvr.net(20)
>514
その処理にビジネス上のメリットがあるとは思えないが好きにすればいいよ

515
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:52:34  ID:7YnVXBSW.net(17)
>515
> 文字列のパターンマッチ検証と

文字列のパターンマッチ検証のバグで
大損害を起こすことも考えられるからな。

重要かどうかは、やってる処理内容ではない。
やっている場所だ。


どちらもチェック処理であることは明白
重要な箇所のチェック処理であるかどうかの違いがあるだけ

516
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:53:52  ID:7YnVXBSW.net(17)
>517
> その処理にビジネス上のメリットがあるとは思えないが好きにすればいいよ
それはお前が思いつかないってだけだろう?

例えば中古買取システムだと、衣類はグラム単位で買い取り価格が決まるとか
あるわけだが。
コメント1件

517
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:58:12  ID:J7GQwUvr.net(20)
>516
学生さんじゃないな
小学生か

どんな処理でも事故を起こせばペナルティの可能性はある
とはいえ事故の種類によって確率も被害額も異なる
セキュリティ事故は注意していなければ事故を起こしやすく被害額も大きい
つまり対策に投資する価値が大きな分野ってこと
コメント1件

518
デフォルトの名無しさん[sage]   投稿日:2017/07/16 18:58:44  ID:J7GQwUvr.net(20)

519
デフォルトの名無しさん[sage]   投稿日:2017/07/16 19:00:58  ID:7YnVXBSW.net(17)
>520
だからそれは否定してないってw

重要でも重要じゃなくても
処理自体はどちらもチェック処理
コメント2件

520
デフォルトの名無しさん[sage]   投稿日:2017/07/16 19:01:38  ID:J7GQwUvr.net(20)
>519
そういうドメインがあったとしても円とグラムの足し算を定義するメリットはない
混乱するだけだからエラーになるようにしろ

古着の重量から取引価格を問い合わせるサービスを書け
問い合わで得た価格を足し算しろ
その方がずっとわかりやすい
コメント1件

521
デフォルトの名無しさん[sage]   投稿日:2017/07/16 19:06:15  ID:J7GQwUvr.net(20)
>522
ビジネス上の価値が違うって言ってるの
処理の目的も実装も違う
チェック処理ってまとめ方は大雑把すぎる

飯を食ってくるから戻る前にレス溜めといてくれ
あとでまとめて返す

522
デフォルトの名無しさん[sage]   投稿日:2017/07/16 19:26:57  ID:Unh0LZY1.net(3)
そろそろコードでしゃべれ
コメント1件

523
デフォルトの名無しさん[sage]   投稿日:2017/07/16 19:54:32  ID:zK8m4Miw.net
白黒つけるなら、前提条件が分からんと何がベターか分からん。

要件定義書持ってこい。

524
デフォルトの名無しさん[sage]   投稿日:2017/07/16 20:04:35  ID:yM+ti3sc.net
「不可能」でも「状態チェック」でも「認可」でも何でもいいんで
それはコンパイラがコンパイル時に行うのか
それともコール自体を実行時に許さないのか
はたまたコールは許すけど結局弾くだけなのか

どれを想定するかで設計が変わるんで
出題者はそろそろ答えてくれまいか

525
[sage]   投稿日:2017/07/16 21:52:05  ID:bPx1MEIf.net(4)
やっぱ「認可」って言葉に振り回されてんのな。
「これが俺の言う「認可」。お前が言ってるのはこれだろ?」に、そう呼びたいなら呼べばいいやと思ってその言葉使ってるだけで、
単純に言えば>416でチェックって言うとる。

>490
古臭かろうが生きているのは、変な話絶滅すべき理由が無いというそこそこ大切な理由がある。

>491
ごっちゃにすべき話だよ。「この状態の時に何ができるか」は「誰が」をつけないと意味がない。
もちろん、「誰が」にも「この状態」にもワイルドカードが入ることもあるが。

>492
その状態では誰でも出来ないよ。薬剤に薬剤部の承認が降りてて、実施者は医師ないし医師から指示を受けた看護師か薬剤師しかできん。

崩壊目前と言われても、もう俺が知ってるだけで12年は動いてるけどな。
サーバ側のモジュールは1989年の見たことあるわ。

>527
コンパイル時に解決って発想がすごいな。
リリース時には、依存関係を一式リリースしないといかんのでは?と思ってしまう。

526
デフォルトの名無しさん[]   投稿日:2017/07/16 22:48:41  ID:X07S5niy.net(2)
絵に描いたようなレガシーおじいちゃん

527
[sage]   投稿日:2017/07/16 23:09:18  ID:bPx1MEIf.net(4)
>529
全然30代だけど、おじーちゃん扱いか…。
コメント1件

528
デフォルトの名無しさん[sage]   投稿日:2017/07/16 23:15:04  ID:2wo8gPgW.net(3)
認可処理が本質的に複雑なシステムでうまく体系化できていないんだろうね
認可処理が体系化されてないシステムってアドホックな認可検証処理があちこちにばら撒かれて他の処理に紛れてしまうものなんだ
それで紛れちゃったから区別がつかなくなってしまったんだろう(少なくともメンテナの彼は区別が付いてない)
昔から世界中で問題視されて来た典型的なアンチパターンってわけ
多くの失敗例を反省して改善してきた答えが認可システムと他のロジックの分離なんだけど
これはその成果を取り入れる前の実験台になった世代のシステムだったということだね

529
[sage]   投稿日:2017/07/16 23:19:58  ID:bPx1MEIf.net(4)
>531
まぁ、なんとでも言えば良いと思うけど、
アドホックな認証認可の検証を一切しないためのキューだよ。
取り入れるも何も、最初からしとる。

お前、全く理解できてないだろ。
コメント1件

530
[sage]   投稿日:2017/07/16 23:22:16  ID:bPx1MEIf.net(4)
要は、負けたくないんです、って言ってるんだよな?

オブジェクトとして、ステートフルで、操作の例外を自身がすべて処理するクラスは存在しても良い、と。

まーそれでいいよ。もう伝わんないだろうし。
無駄だわ。
コメント1件

531
デフォルトの名無しさん[]   投稿日:2017/07/16 23:25:25  ID:X07S5niy.net(2)
>530
レスからは年齢を感じる
30台ならまだもうちょいいけるから元気だして
コメント1件

532
デフォルトの名無しさん[sage]   投稿日:2017/07/16 23:29:13  ID:2wo8gPgW.net(3)
>532
他の検証処理と一緒くたにしてるんだろ
そういうのをアドホックっていうんだよ
そしてこのキューは関係ない
君の使ってるキューはジョブスケジューリングのためのものだろ
むしろこれに検証やロジックが結合しているならそれこそおかしな設計だよ

533
デフォルトの名無しさん[sage]   投稿日:2017/07/16 23:30:11  ID:2wo8gPgW.net(3)
>533
お前がそれをいうなよ

534
デフォルトの名無しさん[sage]   投稿日:2017/07/17 00:17:18  ID:Fkkap2CA.net(2)
何の話してるか3行でまとめろ
状態をコンパイルで安全に実装する話じゃなかったのか?
コメント1件

535
[sage]   投稿日:2017/07/17 01:02:43  ID:JcUUgs2I.net(2)
>535
ad hocの意味調べてこい

536
[sage]   投稿日:2017/07/17 01:04:43  ID:JcUUgs2I.net(2)
>534
大学生の時からフリーで仕事しとったから、職歴としては長いからな。

537
デフォルトの名無しさん[sage]   投稿日:2017/07/17 01:12:44  ID:ka/V7JjN.net(2)
何の話か分からないから仕切り直して、
議題をまとめて。
あと、ゴールも。

538
デフォルトの名無しさん[sage]   投稿日:2017/07/17 08:13:45  ID:1hPCwKm/.net(2)
よし議論を仕切り直すぞ

まず「認可」議論が何にこだわってるのか意味不明

100円と20グラムを足せないようにしたいなら
貨幣クラスと重量クラスを作って型チェックすればいい

品物を発送したら注文のキャンセル不可にしたいなら
ステートパターンとかで発送状態にして
キャンセル判定すればいい

ふつうは前者を実行したらエラーや例外にするし
後者はいちいちアプリごと落ちたらうざいので
「発送後はキャンセルできません」とか画面に表示する

んで、それだと何がダメで
じゃあどうしたらいいのか
さっぱり話が見えてこない

539
デフォルトの名無しさん[sage]   投稿日:2017/07/17 08:31:31  ID:1hPCwKm/.net(2)
おそらく認可君が言いたいことを察すると
不変条件は不変だから
認証系と混同するなよってことかな
それ自体はそうだよ

100円と20グラムを足すような処理は
100パーセントないと断言できるから
コンパイルエラーで100パー弾いても構わない

それに対してキャンセルの話は
発送後も不良品であれば返品できるみたいに
実務では複雑な条件になるし変更もありうる

だからその判定が複雑なら
キャンセルクラスを作って判定するかな

それよりもっと高度な何かを求めてるなら
説明してもらわないと分からない

540
デフォルトの名無しさん[sage]   投稿日:2017/07/17 08:49:02  ID:vyn2jib/.net
>541
その認識であってるよ
そこに「認証認可系とごちゃ混ぜにして処理しろ。分けて考えるな。キューイング!キューイング!」ってちょっと変な奴が絡んできたから「分けて考えるのが正解だし、そもそもそれ今関係ないだろ」って応酬を延々と続けていただけ
連休の2ちゃんではそういうことがままある

541
[sage]   投稿日:2017/07/17 11:33:50  ID:6lVfk8iG.net
だってなぁ。
ママゴト聞いてるみたいだもん。
コメント1件

542
デフォルトの名無しさん[sage]   投稿日:2017/07/17 12:56:51  ID:Fkkap2CA.net(2)
まーた論点が喧嘩になっちゃう
小学生か?ガイジか?
コメント1件

543
デフォルトの名無しさん[sage]   投稿日:2017/07/17 13:06:08  ID:orwW66DF.net(3)
>542
> だからその判定が複雑なら
> キャンセルクラスを作って判定するかな
複雑じゃない場合はどこに実装するんだ?

544
デフォルトの名無しさん[sage]   投稿日:2017/07/17 13:08:53  ID:H+ZLTTJY.net(2)
> それに対してキャンセルの話は
> 発送後も不良品であれば返品できるみたいに
> 実務では複雑な条件になるし変更もありうる

それ返品の話ですよね?
キャンセルじゃないですよね?

545
デフォルトの名無しさん[sage]   投稿日:2017/07/17 13:39:57  ID:ZHrINvVG.net
お互いに見下しあう口喧嘩に解のない無駄でしかないってのに
暇そうで羨ましいよ

546
デフォルトの名無しさん[sage]   投稿日:2017/07/17 14:34:06  ID:orwW66DF.net(3)
結局、"あ"氏にとってのオブジェクトの定義は、単なるデータスキーマでしかないということ

>416
> 値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは?
> 値は値なんだし。
> 値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
> しかも、何かさせられない状態すら持ってる。これヤバい。

で、対する一派は、オブジェクトは振る舞いを持っているしルールも持っているという認識

話は噛み合わないよ

547
[sage]   投稿日:2017/07/17 14:45:52  ID:ql0cyt0N.net(7)
俺も暇なのは確かだけど。
こんなに盛り上がるとはな。
まー、いにしえのナントカ、みたいなのは良くも悪くも「ちゃんと動く」から、いにしえのナントカとして未だに生きてるんだから、
無碍に否定してもきりがない。
ジョブシステムの致命的な欠点の「ジョブサーバが死んだら何も動かない」を突かれたら
「死なんように単機能なんだ。だから、どんな処理も「処理完了,処理結果:不正」という正常系でさばく必要がある」
としか言えないところだったのに、そこはスルーなのがわからん。


548
[sage]   投稿日:2017/07/17 14:48:06  ID:ql0cyt0N.net(7)
>549
オブジェクトの定義は、「単なるデータスキーマ」であるか「単なるタスクの実装」であって、それ混ぜると収拾つかなくなるよ、なので、
単にオブジェクト指向を否定してるわけではない事だけ伝わってほしい。

549
[sage]   投稿日:2017/07/17 14:51:10  ID:ql0cyt0N.net(7)
継承と移譲も、インターフェイスと実装も、そのデータたちや、アクターのクラスたちの中でやる分には効果的だけど、
その線を踏み越えたらすべきじゃないと思うから、否定してるのかな。どうなんだろう。
コメント2件

550
デフォルトの名無しさん[sage]   投稿日:2017/07/17 14:59:23  ID:ka/V7JjN.net(2)
あんまデータ自体に状態持たせないで、
状態に対応したテーブル用意して、キューで逐次処理する方がよくね。

そうすると、RDBとツリー階層で互換性もたせられて、色々対応づけるのに楽な場面があると思うんだよね。

発送前フォルダ、発送後フォルダとか。

キャンセルは発送前までの処理でしか受付ないし、返品は発送後2週間まで受け付けます。とか。

なんか商品に不具合あって返品したいなら、まずメールでやり取りすると思うし、その後の判断はメーカー側で行って、返品操作はメーカー側でやるでしょ。

で、返品の判断なんて難しいからシステムに組み込まないで、返品対応マニュアルをエンドユーザさんで用意してもらえば終わりでしょ。

551
デフォルトの名無しさん[sage]   投稿日:2017/07/17 15:03:51  ID:orwW66DF.net(3)
>551
> オブジェクトの定義は、「単なるデータスキーマ」であるか「単なるタスクの実装」であって、それ混ぜると収拾つかなくなるよ、なので、
> 単にオブジェクト指向を否定してるわけではない事だけ伝わってほしい。
(少なくとも俺は)そのオブジェクトには「ルール」が欠けていると思う
「発注されたらもうキャンセルできない」もルールの一つ
そのルールを、注文というオブジェクトの外側で担保するというのなら、俺に言わせれば、
それなんのためのオブジェクトなのってことになる
C時代の構造体+手続き型コードと何ら変わりないでしょ

まぁ、俺が言いたいのはそれ以上でも以下でもないのだが

552
デフォルトの名無しさん[sage]   投稿日:2017/07/17 15:11:58  ID:H+ZLTTJY.net(2)
> ジョブシステムの致命的な欠点の「ジョブサーバが死んだら何も動かない」を突かれたら

ジョブスが死んだらAppleは何も動かないって
話かと思った

553
[sage]   投稿日:2017/07/17 15:56:37  ID:ql0cyt0N.net(7)
>554
オブジェクト指向は方法であって、目的じゃないよ。
Cの構造体でも、構造体にそんな関数ポインタ持たせたいと思わないし、
ルールってどっちが持ってるものなの?ってのはCで書いたときも同じように、構造体を弄る側に持たせる派と、構造体を使う側が気をつけて使うかでそれなりにモメる所かと。

構造体へのアクセスをすべてラッパで包む→一部の奴らがメンバが読めないじゃないかと言い出すが最終的におちつく
までは多分同じなんだけど、細かいプロジェクトだと

構造体へのアクセスをすべてラッパで包むし、そのラッパ関数があまりにも逸脱した操作はエラーにする
 →喧嘩の後「『あまりにも逸脱した操作』を明文化せよ、そして常にメンテナンスせよ、そして業務フローやシステム改修時には無限に対応せよ」
  のおふれが出て、言いだしたやつが泣き、保証はすべてそいつがする。

構造体へのアクセスをすべてラッパで包むが、ラッパは薄皮に留める
 →喧嘩の後「各サブシステム屋はステートと分岐に対して100%の網羅度で試験せよ。さもなくば本系接続禁止」
  のおふれが出て、全体が少しずつ泣くが、保証は各サブシステム屋が担保する

と、だいたいの流れがある。
後者の方は、保証する範囲や、データの整合性に関して、自然と疎になるので、いい意味でも悪い意味でも足切りしやすい。

554
[sage]   投稿日:2017/07/17 16:10:16  ID:ql0cyt0N.net(7)
>554
もうちょっと具体的に言うと、
「注文」への「ある操作」が「無効」ならば例外とする、ってのは、注文が持つべきルールで良いと思う。
ただ、「注文へのある操作」を「無効」にするのは、注文の役目ではない。だから、「発注されたらキャンセルできない」はルールみたいだが、厳密にはルールじゃない。

『「発注」すると、「キャンセルすると言う操作」を無効にする』ってロジックが居て初めて、注文はキャンセルを無効と自分で判断できる、では無いか?

「キャンセルできなくする」は「発注」ロジックの役目で、注文が自発的にやるべき事じゃ無いと思う。
コメント2件

555
[sage]   投稿日:2017/07/17 16:13:19  ID:ql0cyt0N.net(7)
そうすると、発注ロジック作るやつも、キャンセルロジック作るやつも、相手の事一切考えなくて済むのでは、と思うが。
単に、「できる状態ならば、する」だけになる。
やるべき処理が小さくなればなるほど、作りやすいし試験しやすいし、変なデータできた時に追いかけやすいじゃん。

556
[sage]   投稿日:2017/07/17 16:18:33  ID:ql0cyt0N.net(7)
あと、
できない状態ではない=できる、では無くて、
「できない状態を定義した時点で、できなかった状態」ではない=できる
に過ぎないから、
「発注されている場合はキャンセルできない」と否定文で動作の可否を定義すると、仕様を拡張する時にどっかで漏れるよ。

557
デフォルトの名無しさん[sage]   投稿日:2017/07/17 18:13:03  ID:r495BSOU.net
スレ違いなのでまだ続くようでしたらこちらでお願いします

手続き型システムの設計 1 [無断転載禁止]©2ch.net・
手続き型システムの設計 1
コメント1件

558
デフォルトの名無しさん[sage]   投稿日:2017/07/17 22:08:52  ID:nNe3InXO.net
あ?どこがスレチなんだコラ

559
[sage]   投稿日:2017/07/18 01:37:33  ID:r9TddzbB.net(2)
>560
自分の思ってるオブジェクト指向でなければ、よく知らないけど手続き型に違いない、は惨めだからやめといたら?
コメント1件

560
[sage]   投稿日:2017/07/18 01:39:10  ID:r9TddzbB.net(2)
見に行ったら、あっちでも言われてんじゃんw
コメント1件

561
デフォルトの名無しさん[sage]   投稿日:2017/07/18 03:01:44  ID:tId1dkJr.net(6)
>562
文書読みづらいんで帰ってください。

562
デフォルトの名無しさん[sage]   投稿日:2017/07/18 05:47:26  ID:yansF8kz.net(2)
あさんあなたの方法論は誰が見ても手続き型ですよ
惨めな自演はやめた方がいいです
コメント1件

563
デフォルトの名無しさん[sage]   投稿日:2017/07/18 05:51:49  ID:j0qpHmEl.net(16)
>549
このまとめはその通りだよ

オブジェクト指向なら
データと処理は一体化させるのが基本


>554
>それなんのためのオブジェクトなの
おおむね同感

細かく言うとルールが複雑になったら
判定はルールオブジェクトにして
注文オブジェクトから委譲するけど
カプセル化されてるから構造化とは違う

564
デフォルトの名無しさん[]   投稿日:2017/07/18 05:59:46  ID:OEZUwdxD.net
おまえらは日本語が下手すぎてコードが想像つかん
パブリックリポジトリにコードうpして議論しろ

565
デフォルトの名無しさん[sage]   投稿日:2017/07/18 07:00:15  ID:H1BKDDhK.net(2)
>565
同意者数は意見の根拠として弱いよ

仮に数を根拠とするならその誰がみてもって根拠は?
お前が保証できる視点はお前の視点だけだよ
コメント1件

566
デフォルトの名無しさん[sage]   投稿日:2017/07/18 07:13:14  ID:yansF8kz.net(2)
>568
屁理屈こねてないで現実見ましょうね
コメント1件

567
デフォルトの名無しさん[sage]   投稿日:2017/07/18 07:14:37  ID:H1BKDDhK.net(2)
>569
そうだね
居もしないその他大勢を屁理屈で作り上げず現実見ましょう

568
[sage]   投稿日:2017/07/18 08:21:46  ID:zGBDd9F+.net(2)
>565
自演てw
そんなことせんでも俺はずーっと同じこと言ってるぞ。
誰かに名乗れと言われたから仕方なく「あ」とつけてるくらい。

オブジェクト指向であれば、手続き型ではない、
これ変だよね。
オブジェクト指向か、コンポーネント指向か、アスペクト指向か、etc,etcのモデル化のパラダイムと、
手続き型、関数型、純関数型、etc,etcの、スタイルや値の扱い方のパラダイムは、どう組み合わせたらどうなんて問題じゃないと思うが。
オブジェクト指向で関数型、もあるし、
オブジェクト指向ではない関数型もあるし、
オブジェクト指向で手続き型もあるし、
オブジェクト指向でメッセージドリブンな関数型も
オブジェクト指向でメッセージドリブンな手続き型もある中で、
なにを突っ込まれてるかわからん。

自分の定義が狭すぎるのでは?
コメント1件

569
デフォルトの名無しさん[sage]   投稿日:2017/07/18 09:07:26  ID:tId1dkJr.net(6)
色んな言葉知ってるんだ!
えらいねー。

これでいい?
誰かに褒めてもらいたいようにしか見えない。

ママのおっぱい離れして、小学校卒業するぐらいの文書能力がついたらまたきなよ。
コメント1件

570
[sage]   投稿日:2017/07/18 13:01:06  ID:zGBDd9F+.net(2)
なんだろう、この虚しさ。
褒めてもいらんし、むしろ間違ってたら指摘してほしいくらい(なので、>566には割と納得感がある。最初からルールオブジェクト作ってるのと同じじゃん?と言う気持ちもあるが、そこは考え方と言うか俺が構え過ぎなのか、考えあぐねてる)
少なくとも、理解できないなら理解できない事を挙げてほしいが。

「小学校卒業するぐらいの文書能力」自体、無茶苦茶な日本語だと思うが。
文書は能力でないだろ。文書作成能力、もしくは文章力で、
能力に対して「ぐらい」って言うなら、前半は見込みや可能性、確度であるべきなんだから、「小学校卒業できるぐらい」にならなきゃいかんのでは?尤も小学校は日数で卒業できるが。
「ここに張り紙をするな」って張り紙みたいなみっともないのはやめてほしい。

571
デフォルトの名無しさん[sage]   投稿日:2017/07/18 13:57:59  ID:tId1dkJr.net(6)
そういうところじゃね。
揚げ足取りとか。

問題を解決したい訳でなく、議論ごっこをしたいだけに見えます。

だから、終わりがないし不毛です。
コメント2件

572
デフォルトの名無しさん[sage]   投稿日:2017/07/18 14:07:15  ID:fE/UB1Gl.net
そいつは重度の知ったか自己弁護野郎だから放置が一番
他のスレでも結局放置されてた

573
デフォルトの名無しさん[sage]   投稿日:2017/07/18 16:08:09  ID:ECiix6T1.net(9)
>557
> 『「発注」すると、「キャンセルすると言う操作」を無効にする』ってロジックが居て初めて、注文はキャンセルを無効と自分で判断できる、では無いか?
ごめん、書き間違えたよ
正しくは、「発送されたらもうキャンセルできない」

あと、無効にする処理をどこに実装するかの話はしていないよ
ルールの実装をどこにするかの話

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() {
}
}

574
デフォルトの名無しさん[sage]   投稿日:2017/07/18 16:11:30  ID:ECiix6T1.net(9)
途中で書き込んでしまった

それに対して、オブジェクト自身がルールを持っていれば
class Order {
  private bool isCancelable() {}
  public void cancel() {
    if (!isCancelable()) {
      // エラー処理(例えば例外をthrow)
    }
    // 実際のキャンセル処理
  }
}

client:
order = new Order();
try {
  order.cancel();
} catch () {
}

クライアントは、
・cancelの正しい手続きを知る必要はなく、単に呼び出すだけ
・その手続きに変更があっても、呼び出し側は変更する必要がない
・誤った呼び出しもない
というメリットがある

575
デフォルトの名無しさん[sage]   投稿日:2017/07/18 16:14:53  ID:ECiix6T1.net(9)
一方、権限としての呼び出し可/不可の話はこれとは別
なぜなら、cancelの呼び出し権限があるかどうかは、Orderオブジェクト自身は知りようがないから

576
デフォルトの名無しさん[sage]   投稿日:2017/07/18 16:18:09  ID:ECiix6T1.net(9)
もちろん、「自分の注文のみキャンセルできる」という単純な権限チェックなら、Orderモデルの範囲内で
チェックが可能なので、そう実装してもいい

class Order {
  private bool isCancelable() {}
private string orderUserID() {}
  public void cancel(string cancelUserID) {
    if (!isCancelable()) {
      // エラー処理(例えば例外をthrow)
    }
    if (orderUserID() != cancelUserID) {
      // エラー処理(例えば例外をthrow)
    }
    // 実際のキャンセル処理
  }
}

まあ大抵はロールによる権限管理とかのケースが多いだろうから、その場合はOrder自身は権限チェックできない
コメント2件

577
デフォルトの名無しさん[sage]   投稿日:2017/07/18 16:22:38  ID:j0qpHmEl.net(16)
>571
>オブジェクト指向であれば、手続き型ではない
変じゃないよ

たしかに構造化に近いレベルでも
オブジェクト指向とされているのが現実だけど
手続きを隠蔽するのが本来のオブジェクト指向
コメント4件

578
デフォルトの名無しさん[sage]   投稿日:2017/07/18 16:32:17  ID:j0qpHmEl.net(16)
>576-579
考え方としては筋が良いけど
もっと突き詰めていくと
キャンセル可能かどうかの判断は
キャンセルオブジェクト自身の責務にしたい

つまり
>if (!isCancelable()) {
はキャンセルオブジェクトの内部にあって
Orderクラスからは知らなくていいようにする

Orderクラスからcancelメソッドを呼ぶと
キャンセルクラスの内部で判定するように

579
デフォルトの名無しさん[sage]   投稿日:2017/07/18 16:35:29  ID:ECiix6T1.net(9)
>581
コード書いて

580
デフォルトの名無しさん[sage]   投稿日:2017/07/18 17:17:22  ID:j0qpHmEl.net(16)
>582

class Order {
 Canceler canceler;
  void cancel() {
   canceler.cancel();
  }
}

class Canceler {
 boolean isCancelable() {
 }
 void cancel() {
  if (!isCancelable()) {
  }
 }
}
コメント1件

581
デフォルトの名無しさん[sage]   投稿日:2017/07/18 17:22:40  ID:ECiix6T1.net(9)
>583
悪いけど、そのコードのデメリットだけ思いついて、メリットを思いつかない
コメント1件

582
デフォルトの名無しさん[sage]   投稿日:2017/07/18 17:48:59  ID:bC2KM4MS.net(6)
order classがデータなのか処理なのかまったく分からない。
コメント1件

583
デフォルトの名無しさん[sage]   投稿日:2017/07/18 17:55:25  ID:egYflce+.net
>584
君のレベルが低い
コメント2件

584
デフォルトの名無しさん[sage]   投稿日:2017/07/18 17:57:51  ID:j0qpHmEl.net(16)
>584
デメリットってどんな?
ないとは言わないが
メリットの方が上回ってるはず


>585
データと処理が一体なのがオブジェクト指向
だけどあえて言えばデータが基本

注文されたかどうか
発送されたかどうか
振込されたかどうか
などの状態を持っていて
メソッドでその状態を変えられる
ただしそれらは委譲している場合もある
コメント1件

585
デフォルトの名無しさん[sage]   投稿日:2017/07/18 18:12:21  ID:bC2KM4MS.net(6)
>587
データと処理が一体化がオブジェクト思考?
馬鹿いうな。

オブジェクト思考は役割を小さくし、
疎結合を保つ試み。

データはデータの構造に着目しろ。
処理は処理クラスに任せろ。

注文データを作ったら、それを確定、キャンセルするのは処理クラスの役割だ馬鹿。
コメント1件

586
デフォルトの名無しさん[sage]   投稿日:2017/07/18 18:28:13  ID:ECiix6T1.net(9)
>587
> デメリットってどんな?
「発送されたらもうキャンセルできない」という話の流れで出したコードだけど、それに沿って説明すれば
実際には>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();
    }
  }
}

みたいなヒドイことになるのだが

逆に、メリットってなんだろうか?

587
デフォルトの名無しさん[sage]   投稿日:2017/07/18 18:30:27  ID:ECiix6T1.net(9)
ギャグなのか本気なのか荒らしなのか、判断に困るレス多数
コメント2件

588
デフォルトの名無しさん[sage]   投稿日:2017/07/18 18:33:41  ID:ECiix6T1.net(9)
if (!isCancelable(order) {
  order.processCancel();
}
じゃくて、
if (isCancelable(order) {
  order.processCancel();
}
だな
コメント1件

589
デフォルトの名無しさん[sage]   投稿日:2017/07/18 18:34:39  ID:bC2KM4MS.net(6)
canceler.cancel(order)
order.cancel()

dryの原則に反してるからcancelerクラスのキャンセル処理だけありゃいいだろ!

俺はどっちからキャンセル呼べばいいんだよ!
コメント1件

590
デフォルトの名無しさん[sage]   投稿日:2017/07/18 20:21:20  ID:j0qpHmEl.net(16)
>589
>実際のキャンセル処理はOrderモデルしか知らない
違う、逆に実際のキャンセル処理はCancelerしか知らない
Cancelerのcancellなどのメソッドにキャンセル処理を書く

>メリットってなんだろうか?

>576
>・cancelの正しい手続きを呼び出し側が知っておく必要がある
>・その手続きに変更があった場合、Order::cancel()を呼び出している箇所全部を修正しなければならない
>・誤った呼び出しをしてしまうと、データに不整合が発生する

>577
>・cancelの正しい手続きを知る必要はなく、単に呼び出すだけ
>・その手続きに変更があっても、呼び出し側は変更する必要がない
>・誤った呼び出しもない

この関係がそのまま当てはまる
Cancelerを呼び出すOrder側を
クライアントと考えればいい

実務では処理が複雑になるが
Orderだけに権限が集中すると
肥大化していくから委譲する

591
デフォルトの名無しさん[sage]   投稿日:2017/07/18 20:26:20  ID:JvbXhUfX.net(2)
Orderだけで完結してるならcancel()で普通に判定
Orderだけで完結してるけど複雑ならcancel()からルールチェインを生成して移譲
Orderだけで完結してないならcancel()からdependencyにアクセス

クライアントはなにも考えずにorderをキャンセルしたいだけなのだからorder.cancel()以外のAPI(canceler)を知りたくない筈だ
同じ理由でクライアントがorderのデータにアクセスするなどもってのほか

592
デフォルトの名無しさん[sage]   投稿日:2017/07/18 20:35:03  ID:j0qpHmEl.net(16)
>588
IT Pro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060410/234873/
>「プログラム(処理)とデータをひとまとめにして」扱えばよい。

オージス総研
https://www.ogis-ri.co.jp/otc/hiroba/technical/concept.html
>カプセル化とは、データとそれらを操作する手続き群とを
>ひとまとめにしてパッケージとしたものです。


少しは調べてから物を言えよ……

データと処理の一体化(カプセル化)は
オブジェクト指向の基本だぞ
コメント1件

593
デフォルトの名無しさん[sage]   投稿日:2017/07/18 20:40:02  ID:JvbXhUfX.net(2)
>593
Orderがクライアントになるというのはつまりこういうこと

class Order {
private Canceler canceler;
public Order(Canceler c) { canceler = c; }
public void cancel() { canceler.cancel(this); }

Orderのクライアントは常にorder.cancel()だけを知っていればおk
cancel()の中でなにをやってるかは問題ではない
コメント1件

594
デフォルトの名無しさん[sage]   投稿日:2017/07/18 20:41:36  ID:j0qpHmEl.net(16)
>592
委譲を知らんのか
DRYの原則には反しない
Orderにキャンセルの実装は書いてないからな

>canceler.cancel(order)
こうはしない

>どっちからキャンセル呼べばいい
今回のケースでは
Orderから呼ぶことを想定してる
コメント1件

595
デフォルトの名無しさん[sage]   投稿日:2017/07/18 20:50:14  ID:j0qpHmEl.net(16)
>594
>596
>クライアントがorderのデータに
>アクセスするなどもってのほか

>Orderのクライアントは常に
>order.cancel()だけを知っていればおk

その通り

使用側は最小限のAPIだけ
知っていればいいのが
オブジェクト指向のメリット
コメント2件

596
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:00:30  ID:bC2KM4MS.net(6)
>595
注文は人がウェイターにするの。
だから、注文それ自身は処理を持たない。
データなんだから。
わかる?
ウェイターが注文を受け取って、それを受理するの。

なんか色々勘違いしてるけど。
注文クラスの責務はなに?
答えてみて
コメント2件

597
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:08:22  ID:xem2YDug.net
>599
>なんか色々勘違いしてるけど。

自己紹介乙

598
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:10:01  ID:j0qpHmEl.net(16)
>599
>それ自身は処理を持たない。
>データなんだから。
だからオブジェクト指向のオブジェクトは
たんなるデータじゃなくて処理もできるんだよ

>なんか色々勘違いしてるけど
じゃあそういう解説してるところを
>595みたいにソースあげてみ?

あげられないでしょ?
オレオレの我流だから

>注文クラスの責務はなに?
注文(の情報と処理)

599
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:12:47  ID:DKde2YwO.net(2)
OrderはOrderに関する振る舞いを管理します
ウェイターは客からの問い合わせをシステムに移譲するディスパッチャーです
ここでいうシステムとは端末はもちろんマニュアルなども含みます
彼らは自らが複雑な判断をしているわけではありません
コメント2件


600
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:20:24  ID:DKde2YwO.net(2)
訂正します
ディスパッチャーというよりはユーザー・インターフェースですね
ウェイターは人型のユーザー・インターフェースです
いずれにせよ彼らは複雑な判断はしません
キャンセルを指示されたら笑顔でかしこまりましたとメッセージを返し、所持する端末にキャンセル指示を移譲します
それだけです

601
[sage]   投稿日:2017/07/18 21:20:27  ID:zovgvuTt.net(13)
>580
それは、メソッドはステップとして分割不能なものでしか構成されていない、
手続きは一切入っていない、という理解で良いのか?
Cで言えば、文は一つだけ、と。
であれば、なるほど突き詰めるとそうなるか、となるな。

602
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:24:59  ID:bC2KM4MS.net(6)
料理はどこで処理するの?
注文がどのように展開されてどんな処理をするか注文クラスは知っているの?
そもそも注文クラスって何?
ある注文(例えば、野菜炒め)に特化したクラスなの?
それとも汎用的な注文伝票を扱うクラスなの?
キャンセル処理は誰が受け取るの?
料理さんがバカヤロー料理できちまったらキャンセルできねーよっつったら、誰が聞いて誰が返事するの?

注文で必要な処理は検証のみ。
注文を受け取ったらタスク(処理)クラスに移譲して、注文idで問い合わせる。
そうすれば、ウェイターは、非同期でタスクを監視し、できた順に成果物を返せるね。

603
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:30:57  ID:bC2KM4MS.net(6)
あー検証っていうのは、セットの組み合わせとかね。

604
[sage]   投稿日:2017/07/18 21:39:20  ID:zovgvuTt.net(13)
うーん、疑似コードで良いかな。
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
   ログに残すやらなんやら

みたいになるんじゃないの?
コメント1件

605
[sage]   投稿日:2017/07/18 21:40:00  ID:zovgvuTt.net(13)
>607
OrderProcessorのrerurn 、値返してるの間違いだわ。ごめん。
コメント1件

606
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:44:57  ID:iYkT2ifC.net
あぁこりゃ話が通じんわけだわ

607
[sage]   投稿日:2017/07/18 21:48:47  ID:zovgvuTt.net(13)
そりゃどうも。
コメント2件

608
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:49:52  ID:j0qpHmEl.net(16)
>604
>手続きは一切入っていない
もちろん手続きは入ってるよ
たいてい関数型でも入ってる

ただ関数型が参照透過性を重視するように
オブジェクト指向ではカプセル化を重視する

高レイヤーではIF文やFOR文を
追い回さなくてもいいように抽象化する

今の文脈で言えばオブジェクトの使用側は
「Order.cancel()」だけ知っていれば使えるようなこと

609
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:51:59  ID:k0GegrzJ.net
アンチOOP?

610
デフォルトの名無しさん[sage]   投稿日:2017/07/18 21:57:39  ID:j0qpHmEl.net(16)
>605
>注文クラスって何?
今の文脈だと汎用的というか
集約的なクラスかな

注文の情報や処理は
注文クラスでできるようにする
ただし具体的な実装は委譲する

Order.cancelでキャンセルできるけど
何日までキャンセル可能みたいな
具体的な条件や実装までは知らない
それはCancelerの責務

ウェイターは自分で料理作るわけじゃないけど
注文は取れるでしょ? それと同じ

611
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:00:18  ID:j0qpHmEl.net(16)
>607
正直、構造化っぽいコードだと思う
べつに構造化で組んじゃいけないわけじゃないけど
少なくともオブジェクト指向らしいコードではない
コメント2件

612
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:02:25  ID:oy6gK2Tn.net(4)
真面目な話だけど、次スレからコード掲載必須をスレッドローカルルールにしないか?
時間の無駄は極力減らすべき

613
[sage]   投稿日:2017/07/18 22:02:42  ID:zovgvuTt.net(13)
>611
なら、方法論が手続き型でも、そうでなくてもどっちでも良いんだから、
オブジェクト指向であれば、手続き型ではない、ってのはやっぱ変になるんじゃん。
>571の通り、オブジェクト指向であるかないかと、中身が手続き型か関数型はまったく違う次元の話かと。
そういう意味で、
>611で言う「たいてい関数型でも」に対しての「純関数型」まで挙げてんのに、なんで?

カプセル化と、抽象化は似てるけど違うでしょ。
a+bが、ベクトルでも複素型でもできるのはカプセル化ではないけど抽象化でしょ。
Order.cancelだけ知ってれば、って、Cancelが闇鍋になんじゃん。

614
[sage]   投稿日:2017/07/18 22:06:36  ID:zovgvuTt.net(13)
>614
オブジェクト指向を広く捉えたとして、物をモデル化したものをインスタンスとして扱うものとするならば、
自分からひとりでに意味を持つ注文書なんか存在しないじゃん。

切手だって勝手に有価証券になるわけでも、使用済みになるわけでもないぞ。
郵政省が刷って有効になって、手紙に誰かが貼って使えて、郵便局が消印押して無効になるんだから。

615
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:14:29  ID:oy6gK2Tn.net(4)
オブジェクトって単語に引っ張られて物のモデル化と思い込んでしまうことはよくあるけどそれは初歩的な間違い

車の販売管理システムで車の物理的構造をモデル化するバカはいない
飲食店の注文管理システムでウェイターをモデル化するバカは…

あ、このスレには1人いたか

616
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:17:16  ID:j0qpHmEl.net(16)
>616
どっちでもいいわけじゃなくて
メソッドの中身は手続き型でも
隠蔽されていることが重要なの
カプセル化されているかどうかの違い

「STATUS = 1」みたいなフラグを知らないと
関数やメソッドを利用できないのは構造化的な世界で
オブジェクト指向の世界ではそれは隠蔽する
外部からは最低限のAPIだけで利用できるのがメリット

>Order.cancelだけ知ってれば、って、
>Cancelが闇鍋になんじゃん。
隠蔽が闇鍋ってのはそういう面もあるけど

キャンセルの責務がCancelerに限定されてるから
キャンセルでバグがあるならCancelerだけいじればいい

対して構造化的なデータと処理で分けて
フラグのバケツリレーみたいなことだと
影響範囲がどこまであるのか分からなくなる
つまり闇鍋の中身がどこまでも拡散していっちゃう

だからある程度の規模になると相対的に
オブジェクト指向の方が保守しやすい

617
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:22:39  ID:tId1dkJr.net(6)
>618
ウェイターも食券販売機も一緒だろ。
窓口のサービスを起点になって、
手続き的に内部で処理されるわけ。
ウェイターもなしで、いきなり注文して、
勝手に料理作られたら困るから窓口おいとくわけ。

設計したことあるかな?
標準化とか分かるかな?
運用とか考えたことあるかな?
ないんだろーなー。
コメント1件

618
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:25:37  ID:6z8TQZIC.net
>618
人の仕事が機械に変わって行ってる現実
つまりモデル化できてるんだよ
コメント1件

619
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:26:42  ID:j0qpHmEl.net(16)
>617
オブジェクト指向のオブジェクトは
物理的な物じゃなくて責務なんだよ

飲食店の客から見たら誰が料理してるとか
厨房がどうなってるかとかは知らなくていいが
料理がちゃんと出てこないといけない

通販なら製造や流通の過程は知らなくても
注文したら発送されたり
キャンセルできたりしないといけない

その注文とかキャンセルとかが
責務でありオブジェクトの単位になる
コメント1件

620
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:37:20  ID:oy6gK2Tn.net(4)
>620,621
人のレスはよく読んでね

621
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:44:02  ID:tId1dkJr.net(6)
>623
ウェイターをモデル化したのが食券販売機だね。
どう違うか教えて。

622
[sage]   投稿日:2017/07/18 22:44:30  ID:zovgvuTt.net(13)
>619
うん、そのフラグ知ってるのは、OrderのCancelを呼ぶということを知ってるのに等しいんだけど?
だから、Cancelと言うメソッドは無いし、実質QueueOrderのOperationがそう。
最低限のAPIじゃん。exec。

キャンセルの責務はcancelに持ってるかもしれんが、その修正の影響範囲はcancelを呼ぶもの全部に波及するぞ。
バケツリレーの良いところは、明らかに守備範囲外、が明確で、かつ、その場合の処理方法が「バケツごと捨てる」の一択しかない所。
捨てられたなら、捨てた時点より以前がおかしい。単純明快。
デジャーナルして、もっかいジャーナルから流すのも簡単。
コメント1件

623
[sage]   投稿日:2017/07/18 22:47:30  ID:zovgvuTt.net(13)
>622
責務は、それぞれの責任範囲で行うこと。
それ自体は否定してない。
>421でも言ってる。

ビジネスロジックは、データの持ち物じゃない。
逆。ビジネスロジックがステートを持つなら百歩譲って理解できるが、データがロジック持つのは責務で言えば越権行為じゃないの?
コメント2件

624
デフォルトの名無しさん[sage]   投稿日:2017/07/18 22:52:05  ID:mSXXv0D2.net
>623
そうだね
よく読んでね
コメント1件

625
[sage]   投稿日:2017/07/18 22:52:47  ID:zovgvuTt.net(13)
注文管理システムであれば、ウエイターをモデル化すると実は、ウエイターは2つの職責を果たしてる事に気づくと思う。
(両方できる奴も居るが)伝票に追記したり抹消線引いたりする奴と、料理の配膳や片付けする奴。
伝票があるから、注文を伝えた事が正しかったか証明できて、料理が正しいか、配膳されたか証明できて、そして会計できる。

伝票はひとりでに動いてない。ウエイターが書いてる。
食券の自販機なんかもっとわかりやすいな。金券かつカンバンそのもの。

626
[sage]   投稿日:2017/07/18 22:55:50  ID:zovgvuTt.net(13)
食券やら映画のチケットはもっと俺が言ってるのに近いか。
存在する=金払った証明として有効
もぎれる=使用することができる

料理が出てきて食券渡して、もぎられると、もうもぎれないので、食券としては無効。
ただ、半券として金払った証明としてはまだ有効。
コメント1件

627
デフォルトの名無しさん[sage]   投稿日:2017/07/18 23:01:32  ID:LmMkrF0z.net
>629
それでいて所持する役、もぎる役がそれぞれ別にいるってことか

628
デフォルトの名無しさん[sage]   投稿日:2017/07/18 23:01:37  ID:oy6gK2Tn.net(4)
>624
レストランの物理的な構造に囚われてウェイターという物をモデル化しようとする人が居るってこと
注文クラスと聞いて紙の注文書を馬鹿正直にモデル化しようとする人も同じタイプだね
レストランシミュレーターウェイターモデルならそれでいいかもしれないが注文管理システムでは不適切だろ

ついでに言うとウェイターをモデル化したものが食券販売機という例は適切じゃない
ウェイターも食券販売機も同じインターフェースの実装でしかないよ

629
[sage]   投稿日:2017/07/18 23:05:36  ID:zovgvuTt.net(13)
>630
もぎる奴が居るから、存在するし、
使うやつが居るから、存在する。
その数は一対一でもない。媒介物。

もぎりのバイトは、ひたすらチケットもぎるだけで良い。
職務は「もぎれるかどうか判断して、もぎれなければ追い返す」
滅茶苦茶シンプルじゃん。
後工程で、映画の半券持ってたら一軒だけ飲食店で割引なんてのが突然増えても、
飲食店は、半券持ってるか、ハンコ押してないか見て、押して無かったらハンコ押して割り引くだけ。
コメント1件

630
[sage]   投稿日:2017/07/18 23:10:05  ID:zovgvuTt.net(13)
>631
飲食店の注文管理システムってのがえらく玉虫色してるな。
レストランシミュレーターウエイターシステム以外を指して言ったなら、かなり恣意的な運用な気がする。

あと、リアルウエイターは2つ以上のインターフェイスを実装することもあるとまで言ってるんだけど、割とスルーなのな。
コメント1件

631
デフォルトの名無しさん[sage]   投稿日:2017/07/18 23:11:35  ID:cq/Z8Yw/.net
おっさんたちがんばりすぎじゃねぇの?
コメント1件

632
[sage]   投稿日:2017/07/18 23:13:48  ID:zovgvuTt.net(13)
>634
なんせ、コード掲載必須をルールにしようと言ってる人が、ご高説しかくれないもんだからねえ。
コメント1件

633
デフォルトの名無しさん[sage]   投稿日:2017/07/18 23:16:56  ID:j0qpHmEl.net(16)
なんか喩え話で論点がズレてきてるし
同じことの繰り返しになるから
最後にまとめると

オブジェクト指向では
データと処理を一体化(カプセル化)する

それはネットの解説サイトでも入門書でも
だいたいそう書いてある

一体化してカプセル化することで
外側の利用者は簡潔なAPIだけ
知っていればいいから使いやすくなる
責務が限定されてるから保守もしやすくなる

データと処理がバラバラになってるのは
自己流だから他人に押しつけられても困る
コメント1件

634
デフォルトの名無しさん[sage]   投稿日:2017/07/18 23:23:00  ID:nMbDVkey.net
>632
もぎれてるか否か、ハンコの有無、といった状態をもとに各加盟店が判断をすると必ず間違いが起こる
後々ハンコ二つまで割り引くと仕様が変更になったとする
仕様変更に気が付かずハンコが1つ押してあるから割引なしと判断する加盟店が必ず現れる
コメント1件

635
デフォルトの名無しさん[sage]   投稿日:2017/07/18 23:39:41  ID:tId1dkJr.net(6)
>633
??
インスタンスを2つ作ればいいだけの話では?

636
デフォルトの名無しさん[sage]   投稿日:2017/07/19 00:12:50  ID:747RlNYZ.net(6)
エレクトリカルエバンズのドメインドライブ開発を学びましょう。
コメント1件

637
[sage]   投稿日:2017/07/19 01:04:48  ID:Hpw0ftXx.net
>637
ハンコ2つは筋が悪い。
一つだから押せば良いのであって、累積できるものはたとえ同じものでも、累積できるものであればもぎるごとく消費するか、予め2つ、ハンコ打つ欄を作るべき。
仕様変更に気が付かず、をなくすためのもぎりやハンコなんだから、先回りしろよ。
>638
そういう問題じゃなくて、インターフェイスとするのはもっともだ、って話。

638
デフォルトの名無しさん[sage]   投稿日:2017/07/19 05:39:36  ID:Fs5NzL6m.net
>640
いちいち返しがズレてるなぁ
コメント1件

639
デフォルトの名無しさん[sage]   投稿日:2017/07/19 07:10:10  ID:ax2Hweij.net
>636
デザパタとか知らなさそうなガキが言いそうな台詞w

640
デフォルトの名無しさん[sage]   投稿日:2017/07/19 07:44:25  ID:8lSN/EDp.net(5)
>642
それはデザパタを深く理解してない意見だ
デザパタは基本的にカプセル化に沿ってるぞ
コメント1件

641
デフォルトの名無しさん[sage]   投稿日:2017/07/19 10:25:55  ID:ZGccHuTU.net(3)
>593
> 違う、逆に実際のキャンセル処理はCancelerしか知らない
> Cancelerのcancellなどのメソッドにキャンセル処理を書く
実際の実装では、キャンセル処理には注文のデータそのものが必要なので、「注文の中身を知らない
Cenceler」だとキャンセル処理はできない
なので、CencelerにはOrder自身を渡す必要があり、その結果相互参照するという結合になる

> 肥大化していくから委譲する
肥大化してから考えればいいこと

それとも、最初から「注文実行クラス」「注文内容変更クラス」「注文キャンセル実行クラス」に分割しとくのか?

642
デフォルトの名無しさん[sage]   投稿日:2017/07/19 10:30:14  ID:ZGccHuTU.net(3)
>596
そのコードだと、C(注文する)・R(注文を取得する)・U(注文を変更する)・D(注文をキャンセルする)の
D以外の目的でOrderクラスを使いたいときでも、常にクライアントはCancelerをインスタンス化する必要がある

さらに言うと、OrderがCencelerに依存しているということをクライアントが知っておく必要があり、
仮にCancelerのコンストラクタ引数に変更があると、Orderクラスのクライアントコード全部を修正する必要がある
コメント1件

643
デフォルトの名無しさん[sage]   投稿日:2017/07/19 10:56:06  ID:ZGccHuTU.net(3)
>626
> ビジネスロジックは、データの持ち物じゃない。
> 逆。ビジネスロジックがステートを持つなら百歩譲って理解できるが、データがロジック持つのは責務で言えば越権行為じゃないの?
実は、DDD(ドメイン駆動設計)ではそういう考え方に近い
だからといって、一般の「データ+処理+ルール=オブジェクト」が間違いというわけではない

644
[sage]   投稿日:2017/07/19 11:13:09  ID:lwS1UjSf.net(2)
>646
うん。そこは納得してる。
「処理」と「ルール」ってのはオブジェクトの責務上持ってて然るべきだけど、それはオブジェクトのインスタンス一つが自分でできる範囲って思ってる。
これ、実務以外では確かSOLIDとか言って定義した人の本で見た気がする。
ググった感じこんなのかな。
https://code.tutsplus.com/ja/tutorials/solid-part-1-the-single-responsi...
コメント1件

645
デフォルトの名無しさん[sage]   投稿日:2017/07/19 12:01:33  ID:y+cwN28R.net
こいつらjavaのコード書きながら、
javaeeとか知らなそうなやつらばっかだな。
コメント1件

646
[sage]   投稿日:2017/07/19 13:05:49  ID:lwS1UjSf.net(2)
>648
POJOとか、いやEntityであるべきだ、DTOだ、ってJavaだとホントいつやったかわからん議論だな、確かに。
コメント2件

647
デフォルトの名無しさん[sage]   投稿日:2017/07/19 21:19:18  ID:747RlNYZ.net(6)
ジャヴァエエとかいうのなくても困らんし
バカなの茶?

648
デフォルトの名無しさん[sage]   投稿日:2017/07/19 21:20:38  ID:8lSN/EDp.net(5)
>644
>相互参照するという結合になる
相互参照は不可避でもない

たとえば話を単純にして
注文日から何日以内という情報さえあれば
キャンセルできるとする

その場合、注文日オブジェクトを
OrderとCancelerが(コンポジションで)参照する
共通参照はするが相互参照じゃない

>肥大化してから考えればいいこと
SOLIDの話が出てるからついでに触れれば
注文とキャンセルは異なる責務だと
分かっているので最初から分離したい
コメント1件

649
デフォルトの名無しさん[sage]   投稿日:2017/07/19 21:24:59  ID:747RlNYZ.net(6)
健全でない言葉が含まれているため表示しません 内容を確認する
コメント1件

650
デフォルトの名無しさん[sage]   投稿日:2017/07/19 21:31:04  ID:8lSN/EDp.net(5)
>645
>常にクライアントは〜する必要がある
インスタンス生成の処理は
ファクトリに隠蔽すれば
クライアントは依存関係や
コンストラクタについて知らなくてもいい


>646
>DDD(ドメイン駆動設計)ではそういう考え方に近い
ええ……? 逆でしょ?

DDDではドメインオブジェクトが
ビジネスロジックを持つ

データと処理をカプセル化する
OOの基本はDDDでも変わらない

あとついでに言うとDDDやるなら
(ドメイン層では)POJOね

651
デフォルトの名無しさん[sage]   投稿日:2017/07/19 21:33:44  ID:747RlNYZ.net(6)
ダメだね君たち〜
才能ないね^^
コメント1件

652
デフォルトの名無しさん[sage]   投稿日:2017/07/19 21:47:48  ID:747RlNYZ.net(6)
設計の答え、教えたろか?

653
デフォルトの名無しさん[sage]   投稿日:2017/07/19 21:48:22  ID:ytbmAMvR.net
>649
ここは初心者が活発に意見交換して知識を共有するためのスレッドだよ
まともな人はこんなところに来ない
コメント2件

654
[sage]   投稿日:2017/07/19 22:54:49  ID:PC/qPmp3.net(3)
>656
そうなの?
キャットドアとかいう欠陥問題を揉んでるスレかと。

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

655
[sage]   投稿日:2017/07/19 22:59:30  ID:PC/qPmp3.net(3)
>651
注文日オブジェクトって何者なの?
正規化しすぎたRDBみたいな話じゃん。
そんな意味のあるようで無いデータ、共通参照したら死人が増えるだけでは?
「何日以内」って誰が持ってる設定値で、誰がそれ使って処理するの?注文日オブジェクト?
密すぎると思う。分離できてそうで、全くどれも単独で存在できないじゃん。
コメント1件

656
[sage]   投稿日:2017/07/19 23:03:03  ID:PC/qPmp3.net(3)
>653
ドメインモデルなら、EntityとValueとServicesに分けたら、Orderはどこに行くの?
コメント1件

657
デフォルトの名無しさん[sage]   投稿日:2017/07/19 23:18:58  ID:lxe5FWzj.net
>655
よろしく

658
デフォルトの名無しさん[sage]   投稿日:2017/07/19 23:23:06  ID:HXXCFkzn.net
話は変わるが、お前らこういうコード書いたらダメだからな

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

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

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

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

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

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

659
デフォルトの名無しさん[sage]   投稿日:2017/07/19 23:33:07  ID:8lSN/EDp.net(5)
>658
>「何日以内」って誰が持ってる設定値で、
>誰がそれ使って処理するの?
たとえば注文日オブジェクトが
期限日を判定するメソッドの形で持つ
キャンセルがそれを参照する

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

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


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

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

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

660
デフォルトの名無しさん[sage]   投稿日:2017/07/19 23:36:30  ID:8lSN/EDp.net(5)
>659
OrderはEntity
注文日とかはValue

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

661
デフォルトの名無しさん[sage]   投稿日:2017/07/19 23:40:49  ID:747RlNYZ.net(6)
わかってないなあ
コメント1件

662
デフォルトの名無しさん[sage]   投稿日:2017/07/20 00:13:09  ID:zy040NCi.net
>664
回答まだ?
コメント2件

663
[sage]   投稿日:2017/07/20 08:44:25  ID:bw5c+A+a.net(2)
>662
期限を判定するメソッドには注文日オブジェクトが必要、
期限日は別にオブジェクトとして期限日オブジェクトが必要。
それCOBOLなんかでよくあるメタテーブルとかわらんくない?

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

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

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

664
デフォルトの名無しさん[sage]   投稿日:2017/07/20 10:39:07  ID:3fjdXCU7.net(2)
>653
> ファクトリに隠蔽すれば
わざわざ結合度が高いクラス同士に分割して、簡単にインスタンス化できなくなり、
なのでファクトリメソッドを用意する?
>577のように実装すればシンプルなのに、そうやることでなにかメリットがあるのか?

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

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

665
[sage]   投稿日:2017/07/20 12:03:30  ID:bw5c+A+a.net(2)
>667
>577はシンプルそうに見えて闇が深くないか?
例外をThrowするなら、外のCatchは本来は型指定でCatchしてるはずじゃん?
例外の種類増えないって保証も無いし、事実上はCancelを変えると、一旦全体の動作が保証できない状態に陥るかと。
そこからテストするんだろうけど、まず全体のテスト定義書き換える事になるから、全体のテスト定義の定義にあたる要件定義からテスト起こし直しでは?
自動テストかけられる方向で修正したくない?

666
デフォルトの名無しさん[sage]   投稿日:2017/07/20 13:34:14  ID:3fjdXCU7.net(2)
>668
> 例外の種類増えないって保証も無いし
例外クラスは基底クラスでcatchできるということは理解してるか?

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

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

667
[sage]   投稿日:2017/07/20 18:21:23
>669
基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。
>559でいったような、否定文での条件定義と同じく、そのときに定義されていたもの、でしかない。

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

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

全段落含めて言うけど、実務でやらんの?
コメント2件

668
デフォルトの名無しさん[sage]   投稿日:2017/07/20 18:30:59
>670
> 基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。
いやちょっと根本認識が違いすぎて、何をいいたいのかよくわからん
君のソースには、catch () {}が10個くらい並んでるのか?

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

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

669
デフォルトの名無しさん[sage]   投稿日:2017/07/20 18:45:26
つか、依存しているオブジェクトの変更が、依存する側に影響しないようにするのが基本で、
例えばSOLIDの原則とかがあるんだろ

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

670
デフォルトの名無しさん[sage]   投稿日:2017/07/20 18:52:06
例外もそう

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

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

671
[sage]   投稿日:2017/07/20 19:25:21
>671
え?どー言うこと?Exceptionなんかでトラップしたら静的解析にすら怒られるだろ。
FileNotFoundExceptionなのか、とかトラップして、定義外はアプリケーションレベルのハンドラまで飛んでプロセス殺すよ。

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

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


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

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

>673
アホか。

672
デフォルトの名無しさん[sage]   投稿日:2017/07/20 19:37:01
例外は極力クラス内で殺したい
モノによったらゼロは難しいかもしれんけど外に迷惑かけたらやばい

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

673
デフォルトの名無しさん[sage]   投稿日:2017/07/20 20:48:26
>667
同じことの繰り返しになるから
ひとつだけ言うと

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

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

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

674
デフォルトの名無しさん[sage]   投稿日:2017/07/20 22:30:58
インスタンス生成の処理は
ファクトリに隠蔽すれば
クライアントは依存関係や
コンストラクタについて知らなくてもいい

これ意味わからん
コード書いてみてよ
コメント1件

675
デフォルトの名無しさん[sage]   投稿日:2017/07/20 23:38:17
よくわからんが、order.cancel(); が出来るってことは
orderオブジェクトはそのメンバにシステムへのリンクを持ってるってことか?
class order
{
  system s;
  void cancel()
  {
    s.cancel( this );
  }
};
↑これなんかすごく筋悪くね?
system.cancel(order);
で良くね?
cancelの処理がオーダーだけで完結するとは思えんし
俺の中でorderがレシーバーとなってcancel処理っていう発想がない

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

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

676
デフォルトの名無しさん[sage]   投稿日:2017/07/20 23:39:43
主従関係が逆転した考え方は嫌いだな
プログラムは明確にトップダウンなほうが読みやすい
手続き型プログラムにはデータ構造と制御構造の二要素しかないんだから
それぞれ組み立てたうえで、それらをどのように割り振るかってことだけ
考えとけば変なことになりようがないと思うんだけど

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

677
デフォルトの名無しさん[sage]   投稿日:2017/07/20 23:45:13
俺が全てを知ってるんだから
俺オブジェを作ろう
ore.god

678
デフォルトの名無しさん[sage]   投稿日:2017/07/20 23:47:19
どこへ書いておけば後々楽かなぁ〜ってことだけ考えとけばよく
誰が処理するか、とかワケワカランことは考えなくてよし
これで大体迷子になっている人が多い印象、2chみてる限りはね

679
デフォルトの名無しさん[sage]   投稿日:2017/07/20 23:47:26
>680
そのオブジェは邪魔なのでお片付けしちゃいましょーね〜

680
デフォルトの名無しさん[sage]   投稿日:2017/07/20 23:48:59
>681
そうやって君はコントローラーやセービスにたくさん手続き書くんだろう?
それじゃオブジェ志向にはなれないだよ
コメント1件

681
デフォルトの名無しさん[sage]   投稿日:2017/07/20 23:58:42
すべてを知ってるのにファクトリ隠蔽をご存じないのはおもしろいですね
カプセル化としても大切なポイントなのに
コメント1件

682
デフォルトの名無しさん[sage]   投稿日:2017/07/20 23:59:13
別にそういうわけでもないけど

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

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

683
デフォルトの名無しさん[sage]   投稿日:2017/07/21 00:07:01
あぁ、「小さなオブジェクト」ってのは変な表現だな
「末端のオブジェクト」でおねがい

684
デフォルトの名無しさん[sage]   投稿日:2017/07/21 00:26:40
自然な手続き型至上主義の老害ガイジいるかぎり
日本の未来は明るいな

685
デフォルトの名無しさん[sage]   投稿日:2017/07/21 00:27:36
> でもよ、書かなきゃならないコードの総量は決まっているわけよ
> 必要な機能を削るわけにはいかないからな
> とにかく、それは、決まってるから、初めから

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

686
デフォルトの名無しさん[sage]   投稿日:2017/07/21 00:32:01
あと、SSE用、AVX用、AVX2用、AVX512用、と
プログラムのメイン部を4つも用意するのはマジ勘弁なんで
その辺も含めてコンパイラのループのSIMD展開に頑張ってもらうしかないと思う

687
デフォルトの名無しさん[sage]   投稿日:2017/07/21 00:41:30
そういった煽りには何かこう、イラッとすら来ないんだよ
何言っても無駄なのは知ってるし
囚われてる的な何か
自分で気づくまではどうにもならない類

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

688
デフォルトの名無しさん[sage]   投稿日:2017/07/21 06:50:23
糞設計糞コード糞重複

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

ガイジか?

689
デフォルトの名無しさん[sage]   投稿日:2017/07/21 08:41:20
コード総量がどーのって方は固定値取得とかエラー処理、ログ出力のような汎用的な処理も毎回コピペしてるんだろうか
そして毎回同じテストをしているのだろうか

690
デフォルトの名無しさん[sage]   投稿日:2017/07/21 09:45:18
>691
クソコードクソ重複が
お前にとっては「書かなきゃならないコード」
ってことかい?w

691
デフォルトの名無しさん[sage]   投稿日:2017/07/21 10:35:11
俺も最後にするわ

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

692
デフォルトの名無しさん[sage]   投稿日:2017/07/21 10:43:54
>674
> そもそも正常系を例外で処理すんな。
ケースバイケースだしポリシーの話でもあるね
>577でも「例えば例外をthrow」って書いてるだろ?

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

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

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

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

693
デフォルトの名無しさん[sage]   投稿日:2017/07/21 13:01:16
話がかみ合っていない

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

694
[sage]   投稿日:2017/07/21 13:09:10
>695
例外をスローってのは、もうどうしようもない場合だろ。

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

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

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

695
[sage]   投稿日:2017/07/21 13:14:58
見た目上疎なのと、実際に疎なのは全然違うし、
大雑把にしか取らなくて良いのと、大雑把にしか取れないのは全然違う。
未来の定義を含んでるから大きく取る他無い、って設計として柔軟なんじゃなくて、設計としてあやふやなんじゃん。

ある意味、そいつが責務として無責任な返事をしてて、その後始末を使う側に押し付けてるように見える。
コメント1件
更新情報
・スレッド一覧ページで過去ログのタイトル検索・一覧表示ができるようになりました(2016/1/20)
NGワード登録
登録する
スレッド内検索

プログラム板 タイトル検索

このスレッドが人気です(実況系)
バイキングとグッディ★4 (417)フジ実況
実況 ◆ TBSテレビ 28128 江藤愛の故郷は夏が暑すぎて住むのにはちょっと… (721)TBS実況
実況 ◆ テレビ朝日 48623 直子 (487)テレ朝実況
連続テレビ小説 ひよっこ★196 (360)NHK実況
ビビット 7/21(金) 上西小百合議員緊急生出演 ★3 (811)TBS実況
羽鳥慎一モーニングショー★4 (497)テレ朝実況
はやドキ!& あさチャン!金曜日★2 (628)TBS実況
実況 ◆ 日本テレビ 55885 こん (167)NTV実況
このスレッドが人気です(ニュース系)
【国籍法違反について】蓮舫代表「手続きを怠ったのは事実。私はずっと日本籍だけだと思っていた。深く反省している」国籍を開示★59 (944)ニュー速+
【稲田】南スーダン日報問題、実は、2月6日に日報はすべて公開されていた 一方、一連の情報リーク主犯格の名前が判明 (1002)ニュー速+
【外交】「安倍首相夫人は英語を話さない。ハローすら言わない」トランプ大統領の発言に波紋★2 (1002)ニュー速+
【訃報】リンキン・パークのボーカル チェスター・ベニントンが死去 首を吊って自殺しているのが発見される ★4 (1002)音楽・芸能ニュース
【話題】男性の「マザコン」 どこから認定する?女子に聞いてみた…「ママと呼ぶ」「着信履歴で多いのは母」「彼女よりお母さん優先」 (1002)ニュー速+
【警視庁】少年の全裸撮影で「社交界のプリンス」逮捕 (216)ニュー速+
【経済財政白書】人手不足、バブル期並み 残業抑え低成長打開を (557)ニュー速+
【国籍法違反について】蓮舫代表「手続きを怠ったのは事実。私はずっと日本籍だけだと思っていた。深く反省している」国籍を開示★58 (1008)ニュー速+
プログラム板の人気スレ
C言語なら俺に聞け 141 (142)
【統計分析】機械学習・データマイニング16 (647)
Excel VBA 質問スレ Part49 (420)
次世代言語議論スレ[Go Rust Scala Haskell]第5世代 (491)
スレ立てるまでもない質問はここで 148匹目 (671)
JavaScript の質問用スレッド vol.123 (1002)
Visual Studio 2017 Part2 (860)
Pythonのお勉強 Part53 (567)
Ruby 初心者スレッド Part 60 (712)
C++相談室 part130 (872)
Xamarin Part5 (159)
ねねっちと一緒にプログラムを勉強するスレ第2話 (910)
Git 15 (948)
Java入門・初心者質問スレ Part.4 (132)
推薦図書/必読書のためのスレッド 81 (905)
C#, C♯, C#相談室 Part94 (458)
プログラミング言語 Rust 3 (277)
C# vs Java どっちが好き? その3 (493)
【初心者歓迎】C/C++室 Ver.100【環境依存OK】 (1001)
Visual Studio 2015 Part8 (781)
Swift part11 (108)
Androidプログラミング質問スレ revision53 (574)
本当に必要ものは人工知能ではなくて検索エンジン (64)
関数型プログラミング言語Haskell Part30 (719)
MacでもLinuxでも使えるVisual Studio Code Part2 (234)
☆★Java質問・相談スレッド180★★ (346)
ふらっと C#,C♯,C#(初心者用) Part127 (408)
このサイトについて
このサイトは2ちゃんねるからデータを取得し、表示するサービスです。
画像のインライン表示機能について
画像のURLの後ろにある[画像をインライン表示]をクリックすると、URLの下に表示します。
表示される画像は横幅100pxに縮小されていて、クリックすると原寸で表示します。
このサイトの特徴
1)スレッド内検索ができます
2)レス(「>>1」など)のポップアップができます
3)不適切な言葉を含む投稿を表示しません
4)ページ内で画像を直接表示できます
5)2ch他スレッドへのリンクはタイトル・板名つきでリンクします
6)すっきりとしたデザインで表示します
7)最新スレや前スレをチェック・一覧表示します
8)NGワード機能の搭載でイヤな言葉が目に入りません
9)荒らしを自動チェックします
10)スレッド内・同一IDの書き込みだけ表示できます
11)レスの返事をレスされた発言の下に表示する「まとめビュー」が利用できます
12)シリーズ化したスレッドの一覧を表示します
13)最新のスレッドがある場合はお知らせします
削除について
こちらをご覧ください
機能要望について
現在機能要望受付中です。
問い合わせについて
こちらのページからどうぞ
広告


首都圏の方、ソフトバンク光オススメですよ


このサイトは2ch.scからデータを取得・表示しています。削除などについてはこちらをご覧ください。 アクセスモード:差分取得 - 正常取得 - 250件 - 取得完了