5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

1 :uy ◆e6.oHu1j.o :2016/07/09(土) 00:35:13.95 ID:Mn3UGZ+O
前スレ
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/

2 :デフォルトの名無しさん:2016/07/09(土) 00:40:05.67 ID:DRCwnEUQ
スレ立て乙

今回はどうなるものやら

3 :デフォルトの名無しさん:2016/07/09(土) 02:21:37.29 ID:GFJ5/r//
今頃流行ってんだなOOP
10年くらい前は否定派のオッサンが多くてめっちゃ肩身狭かったけど

4 :デフォルトの名無しさん:2016/07/09(土) 02:35:54.68 ID:3DBY5ZwO
>>3
お前の会社は可哀想だなw

5 :名無しさん@そうだ選挙に行こう! Go to vote!:2016/07/10(日) 09:45:08.81 ID:uQXCaqsb
>>3

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

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

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

7 :デフォルトの名無しさん:2016/07/11(月) 21:38:01.16 ID:qc/cfS6K
>>6
実際のコードがないと何とも言えん気がするが

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

8 :デフォルトの名無しさん:2016/07/11(月) 21:42:08.33 ID:5tv/61n2
C界隈出身の先輩が言う事は話半分で聞いてりゃいいよ。

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

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

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

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

12 :デフォルトの名無しさん:2016/07/11(月) 22:01:49.58 ID:dAMIv9Pn
>>11
簡単にでいいから書いてみ↓
https://ideone.com/

13 :デフォルトの名無しさん:2016/07/11(月) 22:09:20.16 ID:aTiidMol
>>12
書いたらrunて押せばいいの?

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

15 :デフォルトの名無しさん:2016/07/11(月) 22:21:48.36 ID:aTiidMol
https://ideone.com/KbepnL
こう?

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

17 :デフォルトの名無しさん:2016/07/11(月) 23:27:03.16 ID:qc/cfS6K
>>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するの?

おまえ向いてないよ

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

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

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

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

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

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

22 :デフォルトの名無しさん:2016/07/11(月) 23:39:31.75 ID:qc/cfS6K
俺が悪かった
薬飲んで寝るよ

23 :デフォルトの名無しさん:2016/07/11(月) 23:41:00.30 ID:aTiidMol
>>22
ちゃんと意見言ってくれただけでもありがたいよ。
薬飲んでるのか?
体は大事にな。
ゆっくり休んでな。

24 :デフォルトの名無しさん:2016/07/11(月) 23:45:26.00 ID:jK3rCQ1d
精神不安定杉内
やっぱIT業界って頭やられちまう奴多いんだなw

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

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

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

27 :デフォルトの名無しさん:2016/07/11(月) 23:59:14.37 ID:c813o9It
>>19
> やっぱ真面目に作ろうとすると昔ながらのc言語スタイルかなと
それはない。
C言語スタイルでは大規模アプリの例外処理は
大変すぎて手に負えなくなる。

28 :デフォルトの名無しさん:2016/07/12(火) 00:14:23.00 ID:92wyFONm
using使え

29 :デフォルトの名無しさん:2016/07/12(火) 00:18:40.28 ID:StomlD/Y
C言語スタイルってなんぞ?

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

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

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

31 :デフォルトの名無しさん:2016/07/12(火) 00:45:40.75 ID:StomlD/Y
Cって例外ないじゃん
C++は既にJavaに似た例外あるじゃん

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

32 :デフォルトの名無しさん:2016/07/12(火) 00:48:43.19 ID:M/oXbOZH
>>31
だから例外ないからその場で処理するしかないだろ

33 :デフォルトの名無しさん:2016/07/12(火) 00:49:55.80 ID:StomlD/Y
>>32
アナルほど凍死罵

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

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

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

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

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

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

37 :デフォルトの名無しさん:2016/07/12(火) 01:11:50.86 ID:Vf+ZIi05
C言語の例外処理はシグナルを使う方法だろ

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

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

39 :デフォルトの名無しさん:2016/07/12(火) 01:36:55.20 ID:4M8hLvVe
>>36
Googleは特殊な事例があるからってだけだなw

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

40 :デフォルトの名無しさん:2016/07/12(火) 01:37:15.67 ID:M/oXbOZH
>>34
会社でどっちに倒すか?
ってなったら俺ならその場で対処だな

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

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

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

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

41 :デフォルトの名無しさん:2016/07/12(火) 01:38:38.08 ID:M/oXbOZH
文中の例えばは間違い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

48 :デフォルトの名無しさん:2016/07/12(火) 02:01:08.65 ID:rBak2gB5
ごめん、まちがえた
>>47>>44

49 :デフォルトの名無しさん:2016/07/12(火) 02:01:24.87 ID:4M8hLvVe
>>47
レスする相手は俺じゃないだろw

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

50 :デフォルトの名無しさん:2016/07/12(火) 02:21:04.05 ID:umCvEWis
>>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するなってのは環境的な問題もあるとは思うんだが。

51 :デフォルトの名無しさん:2016/07/12(火) 02:28:01.69 ID:SKMsT/RZ
>>6
tryで囲む領域が大きくなると、どこでエラーが起きたか、わかりにくい

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

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

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

52 :デフォルトの名無しさん:2016/07/12(火) 02:33:58.13 ID:4M8hLvVe
>>50
そんな小さい処理で同じとか言われてもな。

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

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

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

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

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

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

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

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

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

54 :デフォルトの名無しさん:2016/07/12(火) 03:23:53.60 ID:umCvEWis
>>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の付け足しから感じた。

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

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

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

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

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

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

58 :デフォルトの名無しさん:2016/07/12(火) 08:53:57.34 ID:3JVrmQRs
例外を「例外」だと思わないマが多すぎる
とくにJavaから来た人

59 :デフォルトの名無しさん:2016/07/12(火) 10:05:30.22 ID:KWfKXhYB
ところでOOPと関係ある?

60 :デフォルトの名無しさん:2016/07/12(火) 10:09:09.18 ID:3O9ex62E
例外よりeitherの方が使いやすいよ
型安全だし

61 :デフォルトの名無しさん:2016/07/12(火) 10:09:59.26 ID:ddtK31Ex
ここはOOだけやってんだろ?Pはスレ違いだしな。

62 :デフォルトの名無しさん:2016/07/12(火) 10:10:01.65 ID:3O9ex62E
例外よりeitherの方が使いやすいよ
型安全だし

63 :デフォルトの名無しさん:2016/07/12(火) 11:43:29.90 ID:K7Zjf19C
>>17はずれてるだろ

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

64 :デフォルトの名無しさん:2016/07/12(火) 20:39:39.22 ID:cQbnp1H7
>>63
意図を汲んでくれてありがとう

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

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

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

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

67 :デフォルトの名無しさん:2016/07/12(火) 22:57:14.06 ID:aSzJV8SF
普通に書け
普通に
オリジナリティなんていらねえんだよゴミが

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

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

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

69 :デフォルトの名無しさん:2016/07/12(火) 23:28:42.89 ID:VAaNpcds
>>66
初心者であるとかお年頃であるとか
そーいうのじゃない可能性もあるな

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

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

71 :デフォルトの名無しさん:2016/07/13(水) 00:26:34.83 ID:C7S+nyqs
noexceptでヌルポったらどうなるん?

72 :デフォルトの名無しさん:2016/07/13(水) 00:44:09.12 ID:yKl3ljrD
>>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.46 ID:wcqcmuYS
>>66
共通の例外処理を繰り返したくないと書かれてるじゃん
読解力がない上に自分の意見を押し付けるってさあ…

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

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

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

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

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

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

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

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

76 :デフォルトの名無しさん:2016/07/13(水) 00:53:31.98 ID:2JhFq5Nw
>>65
まずMain関数はこれだけだ。
これ以外不要。

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

77 :デフォルトの名無しさん:2016/07/13(水) 00:59:57.51 ID:2JhFq5Nw
CreateTempFileの中身はこうだな

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

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

78 :デフォルトの名無しさん:2016/07/13(水) 01:03:40.12 ID:2JhFq5Nw
結局のところこの程度であれば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.17 ID:OE4fGXcq
なにこのキモいスレw

80 :デフォルトの名無しさん:2016/07/13(水) 02:08:26.36 ID:uq0wU9fp
>>70,72
情報ありがとう。

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

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

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

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

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

例外保証ってなんや?

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

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

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

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

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

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

83 :デフォルトの名無しさん:2016/07/13(水) 06:01:23.07 ID:QAw5IbxT
>>65
的確な指摘じゃない?
どうみても下の方が出来がいい

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

87 :デフォルトの名無しさん:2016/07/13(水) 19:05:13.08 ID:OE4fGXcq
そんなに力説するほどの事か?w

88 :デフォルトの名無しさん:2016/07/13(水) 21:38:19.72 ID:2JhFq5Nw
>>87
これは力説するほどのことだよ。
なぜなら可読性の話だから。

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

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

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

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

90 :デフォルトの名無しさん:2016/07/13(水) 22:01:55.88 ID:lnUCd6s/
>>89
友情努力勝利に決まってるだろ

91 :デフォルトの名無しさん:2016/07/13(水) 22:31:57.93 ID:oLxbX2RO
正直TryParseで変換できちゃうのはちょっと気持ち悪い

92 :デフォルトの名無しさん:2016/07/13(水) 22:44:01.74 ID:uq0wU9fp
>>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 :デフォルトの名無しさん:2016/07/13(水) 22:44:36.15 ID:uq0wU9fp
> 必要があれば戻り値のエラー通知を部分的に使うのはかまわないと思うよ
個人的にはTryParseをよく使っている。それで十分だから。
必要性はない。try/catchでも書ける。

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

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

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

94 :デフォルトの名無しさん:2016/07/13(水) 22:45:05.83 ID:uq0wU9fp
生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割は無限大になるというお気楽仕様だ。
当初は驚いたが、正直これで問題ないよなとも思う。

95 :デフォルトの名無しさん:2016/07/13(水) 22:58:10.35 ID:2JhFq5Nw
>>89
> Parseが返すパーズした結果とは何ぞや?

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

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

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

96 :デフォルトの名無しさん:2016/07/13(水) 23:09:44.65 ID:jyyAd6hv
Int32.Parse だからといって、必ずInt32が返るとは限らないだろ
おまえは、human.age()で必ずhumanが返ると考えるか?

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

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

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

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

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

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

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

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

100 :デフォルトの名無しさん:2016/07/13(水) 23:13:53.29 ID:jyyAd6hv
>human.parseだったら、human返すんじゃねーの?

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

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

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

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

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

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

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

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

103 :デフォルトの名無しさん:2016/07/13(水) 23:36:52.14 ID:C7S+nyqs
型を見りゃいいだろ

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

104 :デフォルトの名無しさん:2016/07/14(木) 00:31:59.76 ID:4Ps/X1K6
>>102
いやお前それ苦しいだろ

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

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

105 :デフォルトの名無しさん:2016/07/14(木) 01:02:32.63 ID:9qkjMq+e
>>104
言うと思ったw

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

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

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

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

107 :デフォルトの名無しさん:2016/07/14(木) 06:27:39.21 ID:cfi8dg7p
自分の思い込みの通りなら良い設計良いコードw

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

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

110 :デフォルトの名無しさん:2016/07/14(木) 08:31:57.85 ID:qme/E7bl
車輪の再発明しか出来ない人がいると聞いて。

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

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

112 :デフォルトの名無しさん:2016/07/15(金) 23:20:25.90 ID:sS/v2c9e
そんな嘘ついちゃいけないんだお

113 :デフォルトの名無しさん:2016/07/15(金) 23:39:15.88 ID:iR/HdeCl
今の日本人は>>111みたいな馬鹿が普通なんだお

114 :デフォルトの名無しさん:2016/07/21(木) 22:59:46.89 ID:6Fy4Bz7m
>>113
やはり解る人はいないか
DAOやDTOってのはデータと処理を分離するから手続き的なんだがなぁ

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

116 :デフォルトの名無しさん:2016/07/22(金) 08:12:39.95 ID:OQdSZmk7
抽象化が過ぎて解る人がいないだけ

117 :デフォルトの名無しさん:2016/07/22(金) 18:14:47.22 ID:fQzF4pQd
>>111
主張が良くわからない。

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

118 :デフォルトの名無しさん:2016/07/30(土) 00:56:46.87 ID:crIAC8Sk
言いたいのは単純に

DAO/DTO

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

それだけだろ。

119 :デフォルトの名無しさん:2016/07/30(土) 02:56:03.60 ID:YgaIk6dE
んなことゆーたら全部手続きですやんける

120 :デフォルトの名無しさん:2016/07/30(土) 02:57:31.49 ID:6YLFMraq
>>119
程度の問題

121 :デフォルトの名無しさん:2016/07/30(土) 03:07:28.00 ID:crIAC8Sk
単に>>114が知ったかぶりしたいだけだろ。
>>111の段階で明らかだし。

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

123 :デフォルトの名無しさん:2016/07/30(土) 08:03:21.46 ID:cz6waps9
知ったかぶりにすらなってなくて意味のない単語の羅列にすぎん

124 :デフォルトの名無しさん:2016/08/04(木) 16:27:41.40 ID:pdTKskF+
クラスの中に別のクラスをコンポジットしてあり、
そのクラスの中にも別のクラスをコンポジットしてあり…という場合、

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

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

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

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

126 :デフォルトの名無しさん:2016/08/04(木) 20:37:30.59 ID:jTAWnEUa
>>124
O/Rマッパーを使うからそういう処理は
勝手にやってくれる。

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

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

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

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

131 :デフォルトの名無しさん:2016/08/04(木) 23:37:05.58 ID:dkWDRS+N
>>127
血染めの赤にしてやる
死ね

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

133 :デフォルトの名無しさん:2016/08/05(金) 07:18:34.18 ID:ZdrtHNhg
イコール代入するなら、最後は明示されたセッター呼ぶのは中途半端な気がする。

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

134 :デフォルトの名無しさん:2016/08/05(金) 10:32:18.42 ID:VlcB2rw7
結論
余計なことはするな

135 :デフォルトの名無しさん:2016/08/10(水) 22:14:29.57 ID:UWZg55pn
株式会社TOUAが2016年7月に破産
http://www.tdb.co.jp/tosan/syosai/4191.html

136 :デフォルトの名無しさん:2016/08/11(木) 00:00:42.11 ID:0L+mrDki
>>135
派遣会社ってピンハネしかしてないのに潰れるの?

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

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

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

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

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

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

138 :デフォルトの名無しさん:2016/09/10(土) 13:15:16.78 ID:twqmh/TK
予想通り、誰もいなくなったのね。

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

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

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

142 :デフォルトの名無しさん:2016/09/19(月) 11:03:13.57 ID:KUojTFe6
やっぱり誰でもわかる手続き型がナンバーワン

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

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

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

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

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

148 :デフォルトの名無しさん:2016/09/19(月) 14:18:05.63 ID:KUojTFe6
で、君らはまたstatic final Koma.move(int kyori)すんの?

149 :デフォルトの名無しさん:2016/09/19(月) 14:29:03.47 ID:AFsKEmAF
回り将棋ならいいかもしれない

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

151 :デフォルトの名無しさん:2016/12/27(火) 23:06:49.29 ID:+TUrL10Q
UIレイヤーの中のドメインレイヤーとの境界面、じゃないの

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

153 :デフォルトの名無しさん:2016/12/27(火) 23:37:51.54 ID:DbM4OtJE
>>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 :デフォルトの名無しさん:2016/12/28(水) 00:02:52.91 ID:KMmXCa3M
自分は個人で作ってるだけで好きなようにやれるからだけど、
そういう場合、自分はxもyもそのままモデルに投げてその処理はいったんそこで終わり。
モデルで値をチェックしてエラーならエラーイベント発生
→入力用ViewModelがそのイベントを受け取ってViewに伝えるDataErrorイベント発生
→Viewが変化

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

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

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

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

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

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

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

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

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

161 :デフォルトの名無しさん:2016/12/29(木) 00:14:19.42 ID:5yPVbf0y
一切関知すべきじゃないな。
うんこかもしれないもの、としてVM以降に渡して、うんこではないものを貰うしか無い。

162 :デフォルトの名無しさん:2016/12/29(木) 00:36:39.28 ID:BD9K+jOv
それだと使い勝手は悪くなるな

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

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

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

165 :デフォルトの名無しさん:2016/12/29(木) 08:38:21.22 ID:ZpKqxRRa
>>164
だからさ
その構造を実現することになんの意味があるのって話

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

167 :デフォルトの名無しさん:2016/12/29(木) 10:37:25.80 ID:vPLPY1D6
>>165
データを処理する処理に徹することができるのと
データを描画する処理に徹することができるんじゃん。

168 :デフォルトの名無しさん:2016/12/29(木) 11:35:18.82 ID:3hi3YdfK
>>167
現実にはできなくて、やるメリットもあまりなくてって状況だと思うけど

169 :デフォルトの名無しさん:2016/12/29(木) 11:43:36.53 ID:3hi3YdfK
>>166
だったら内部の仕様も画面にべったりなんでしょ?
今更分離して何がしたいの?

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

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

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

173 :デフォルトの名無しさん:2016/12/29(木) 13:00:59.69 ID:3hi3YdfK
だからさ
現実にはできないじゃん
ちょっと突っ込まれるだけでボロボロ抜けが出てくんだから

174 :デフォルトの名無しさん:2016/12/29(木) 13:23:47.48 ID:orpg8/1p
>>173
最近はちゃんと分離されているシステムが増えてきてる

175 :デフォルトの名無しさん:2016/12/29(木) 13:26:05.73 ID:3hi3YdfK
>>174
誰の周辺の話なの?

176 :デフォルトの名無しさん:2016/12/29(木) 13:36:40.64 ID:orpg8/1p
>>175
世界的に

177 :デフォルトの名無しさん:2016/12/29(木) 19:34:31.18 ID:AIw2bcpm
>>168
割と大規模やってるけど、気合でWPFに移行してからそこそこうまく行ってるよ。
出来なくて切った会社は沢山あった。

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

179 :デフォルトの名無しさん:2016/12/29(木) 23:34:45.76 ID:5yPVbf0y
>>178
莫大な犠牲は下請けが払ったんだと思うよ。
選ばれしものしかできないとは思わないが、
選ばれしものが出来ないのはある程度あるんじゃないの?
馬鹿とか。

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

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

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

183 :デフォルトの名無しさん:2016/12/30(金) 09:41:15.14 ID:U2S2spdu
>visualstudioでプロパティいじれば解決する
あーダメダメ

184 :デフォルトの名無しさん:2016/12/30(金) 09:55:02.42 ID:G92pvYFd
できるヤツができないヤツに合わせる必要はない
退化する

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

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

187 :デフォルトの名無しさん:2016/12/30(金) 11:02:39.37 ID:fHdmB1av
>>186
保存ってどこから出てきたんだ?

188 :デフォルトの名無しさん:2016/12/30(金) 11:28:27.74 ID:zvHkIzW0
>>187
このスレよく読んでからレスしてね

189 :デフォルトの名無しさん:2016/12/30(金) 12:14:51.41 ID:tYlkXQKT
ViewModelからModelに入力値の通知を行うことを「保存」と呼ぶ頭のおかしい人が約1名いるだけ

190 :デフォルトの名無しさん:2016/12/30(金) 15:13:10.80 ID:NIWDNqpS
なるほど
どうりで話が通じんわけだ

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

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

192 :デフォルトの名無しさん:2016/12/30(金) 15:44:27.69 ID:zvHkIzW0
>>191
はぁ?
なんのこと喋ってるの?
ちゃんと理解してからレスしてね

193 :デフォルトの名無しさん:2016/12/30(金) 15:52:05.62 ID:7Zd5OH2Q
>>192
>>177
で発端にすらなってるから、理解はしてるが。
アホなのかな。

194 :デフォルトの名無しさん:2016/12/30(金) 21:13:04.65 ID:0uD1Maua
なぜオブジェクト指向の設計の話になると喧嘩になってしまうのか?
やはり関数型にすべきでないのか?

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

196 :デフォルトの名無しさん:2016/12/30(金) 22:36:08.50 ID:KB0M7zpX
喧嘩がなくなるなら関数型喜んでつかうわ

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

198 :デフォルトの名無しさん:2016/12/30(金) 23:59:17.50 ID:0uD1Maua
感情をイミュータブルにしましょう

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

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

201 :デフォルトの名無しさん:2016/12/31(土) 10:34:26.84 ID:H2pBZ8ZG
>>199
ん?でもさぁ
汎用性つけまくった挙句に次の変更が来なかったら汎用化にかけた工数は無駄じゃない?

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

203 :デフォルトの名無しさん:2016/12/31(土) 11:40:12.70 ID:I0WFUQzY
>>202
そもそもOOPだと何で保守性上がるの?

204 :デフォルトの名無しさん:2016/12/31(土) 12:13:13.06 ID:3aGn9kAy
粗結合の徹底→モジュール化→単体テストしやすさ、古くなった部分の可換性

205 :デフォルトの名無しさん:2016/12/31(土) 12:24:49.69 ID:XK+xRs9l
>>203
SOLIDを実践しやすいから
モデルを忠実にコードに反映できるから

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

>>205
聞いて損した

207 :デフォルトの名無しさん:2016/12/31(土) 13:15:07.39 ID:XK+xRs9l
>>206
俺も答えて損した
馬の耳になんとかってヤツだね

208 :デフォルトの名無しさん:2016/12/31(土) 13:18:39.21 ID:I0WFUQzY
なんかごめんね…

209 :デフォルトの名無しさん:2016/12/31(土) 14:00:22.29 ID:XK+xRs9l
>>208
反省しろよ

210 :デフォルトの名無しさん:2016/12/31(土) 15:09:26.22 ID:2Xzfkrwi
>>209
おまえもな

211 :デフォルトの名無しさん:2016/12/31(土) 16:41:13.08 ID:n5yZbU99
>>210
消えろ
ぶっ飛ばされんうちにな

212 :デフォルトの名無しさん:2016/12/31(土) 17:32:21.84 ID:2Xzfkrwi
>>211
おまえもな

213 :デフォルトの名無しさん:2016/12/31(土) 17:32:59.43 ID:qTR6JDNw
>>211
あんまり調子こいてると手続き型にするぞ?

214 :デフォルトの名無しさん:2016/12/31(土) 17:37:54.48 ID:I0WFUQzY
もういいから

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

216 :デフォルトの名無しさん:2017/01/01(日) 00:00:05.99 ID:7qccLNYe
採算度外視で開発とかないわ

217 :デフォルトの名無しさん:2017/01/06(金) 17:03:12.17 ID:rigfFBS6
オブジェクト指向の良書教えて

218 :デフォルトの名無しさん:2017/01/06(金) 17:25:52.39 ID:A0+jLhsU
>>217
http://echo.2ch.net/test/read.cgi/tech/1467992113/

219 :デフォルトの名無しさん:2017/01/06(金) 20:45:05.38 ID:8EHemPmg
ループかよ

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

221 :デフォルトの名無しさん:2017/01/07(土) 12:04:44.28 ID:kXk28A5p
>>220
具体例は?

222 :デフォルトの名無しさん:2017/01/07(土) 13:39:47.70 ID:u/YaKAHu
 サ ー ビ ス ク ラ ス

223 :デフォルトの名無しさん:2017/01/07(土) 21:45:21.54 ID:6fDgBl5y
>>220
> 手続き型でもできる

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

224 :デフォルトの名無しさん:2017/01/07(土) 23:48:37.74 ID:8zzGw/ml
そもそもオブジェクト指向にメリットなんかないのにやり方がわからないとかさっさと廃業しろ

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

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

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

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

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

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

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

230 :デフォルトの名無しさん:2017/01/08(日) 09:50:56.48 ID:TXqGgIea
ワイ「関数型最強ウホホwww」

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

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

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

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

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

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

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

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

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

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

240 :デフォルトの名無しさん:2017/01/08(日) 13:38:11.45 ID:tl4nBuMM
葡萄に手が届かない狐さんのたわごと

241 :デフォルトの名無しさん:2017/01/08(日) 14:08:24.06 ID:TXqGgIea
>>239
車輪的再発明すきそう

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

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

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

244 :デフォルトの名無しさん:2017/01/08(日) 15:26:35.22 ID:TXqGgIea
OOPを無くした人類はどこへ向かうのか

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

スッキリJavaより抜粋

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

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

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

249 :デフォルトの名無しさん:2017/01/08(日) 16:51:03.49 ID:hENayCqC
オブジェクト志向言語使っててもアホが考えた社内規約とやらとヘボいフレームワークで全く楽にならねえw

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

251 :デフォルトの名無しさん:2017/01/08(日) 19:34:42.91 ID:oIuk3BCz
オブジェクト指向の利点って明確にならないね

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

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

254 :デフォルトの名無しさん:2017/01/08(日) 23:00:17.73 ID:iT+T8lZs
>>251
俺も最近正直そう思うようになった

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

255 :デフォルトの名無しさん:2017/01/08(日) 23:23:47.58 ID:XDbKIsfA
そういう本質的に重要な事を記述しやすいってところだろ?

256 :デフォルトの名無しさん:2017/01/08(日) 23:34:45.33 ID:oIuk3BCz
>>255
え?
全然意味わかんない

257 :デフォルトの名無しさん:2017/01/08(日) 23:40:45.17 ID:XDbKIsfA
>>256
そのうちわかるよ

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

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

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



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

261 :デフォルトの名無しさん:2017/01/09(月) 01:00:59.79 ID:Dm7q6S9e
そしてウンポコPのペチプァみたいなゴミ屑コードができあがる

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

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

263 :デフォルトの名無しさん:2017/01/09(月) 07:18:15.57 ID:XasE0eMK
>>262
話の主旨もわからず回答とかおめでてーな

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

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

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

266 :デフォルトの名無しさん:2017/01/11(水) 00:22:47.67 ID:GtOiWPCh
大概書いた奴は既に現場にいないという現実

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

267 :デフォルトの名無しさん:2017/01/11(水) 00:55:08.27 ID:t4W503XG
自社で保守する仕事なら綺麗に書くけど
同業他社が保守するなら難解な方がいいだろ
足を引っ張って競争が優位になる

268 :デフォルトの名無しさん:2017/01/11(水) 00:58:40.69 ID:p4WB0UzK
無駄

269 :デフォルトの名無しさん:2017/01/11(水) 00:58:42.43 ID:GtOiWPCh
>>267
こんなんだから凋落してくんだよジャップランド土人が

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

271 :デフォルトの名無しさん:2017/01/11(水) 01:06:16.95 ID:1SbN3a75
>>265
その全てをパスしているが動かないコードと
その全てを満たしているが動くコードの
どちらを持っていくかと言われたら迷わず糞を持っていく俺

272 :デフォルトの名無しさん:2017/01/11(水) 01:20:12.02 ID:GtOiWPCh
>>271
動くなんて大前提だよ
そんなんだから脳みそまで糞まみれなんだよボケナス
殺すぞ

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

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

275 :デフォルトの名無しさん:2017/01/11(水) 22:20:40.95 ID:R6uUA9rB
仕様が無いのになぜ動いていると言えるのか。

276 :デフォルトの名無しさん:2017/01/11(水) 22:53:40.84 ID:SOQiv9G3
動いてるとも動いてないとも言えない
これが波動関数ってやつさ

277 :デフォルトの名無しさん:2017/01/11(水) 23:44:57.82 ID:GtOiWPCh
>>275
仕様がない=動作が正=動いている

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

279 :デフォルトの名無しさん:2017/01/12(木) 08:29:14.43 ID:D/kCxt4Z
Cの悪口はやめろ

280 :デフォルトの名無しさん:2017/01/14(土) 20:38:16.71 ID:2kEkn3lr
初期化以降はリードオンリーとするフィールド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;}
}
どうよ?

281 :デフォルトの名無しさん:2017/01/14(土) 21:48:54.83 ID:YGCVk3Sf
>>280
C#ならプロパティ使えばよくね

282 :デフォルトの名無しさん:2017/01/14(土) 21:56:28.41 ID:rLoB6nGZ
>>281
Java脳だから仕方ない

283 :デフォルトの名無しさん:2017/01/14(土) 23:11:55.85 ID:/w8IJdhk
C#は、自動プロパティの初期化もできるようになったしな

284 :デフォルトの名無しさん:2017/01/15(日) 09:41:20.06 ID:h+wxmfZm
OOPでフィールドを丸出しなんてはしたないことはやめてください

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

286 :デフォルトの名無しさん:2017/01/15(日) 19:25:01.82 ID:h+wxmfZm
フィールドは実装
実装を晒しては行けない

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

288 :285:2017/01/15(日) 20:03:27.72 ID:zmg1eHAc
元の主張はいったん置いとくけど

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

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

289 :デフォルトの名無しさん:2017/01/15(日) 20:05:23.89 ID:kU0DmNyE
そういうOOPLってのは
フィールドをpublicに出来ない言語って意味ね

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

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

292 :デフォルトの名無しさん:2017/01/16(月) 00:16:59.04 ID:WtkYzKjH
private Integer id;
private String domain;

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

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

293 :デフォルトの名無しさん:2017/01/16(月) 06:36:24.60 ID:5GH26V/A
リフレクションでめんどくさいからやめろよ

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

295 :デフォルトの名無しさん:2017/01/16(月) 23:15:52.19 ID:WtkYzKjH
class User {
private Integer id;
private String domain;

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

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

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

296 :デフォルトの名無しさん:2017/01/16(月) 23:43:04.52 ID:7tn+c1o5
それだと至る所でハイフンでsplitされるって話だろ
AccountId値型を作ろう

297 :デフォルトの名無しさん:2017/03/25(土) 12:41:38.33 ID:Hepb4FxQ
instanceおじさんをレイオフする会を発足します

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

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

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

300 :デフォルトの名無しさん:2017/04/20(木) 23:17:36.80 ID:nIwh3CMn
ワインと豆腐には旅をさせちゃあいけない
という山岡さんの名言がある

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

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

302 :デフォルトの名無しさん:2017/04/21(金) 12:33:54.90 ID:e2S2gBzR
旅をするのは変数ではなく値なんだけどね

303 :デフォルトの名無しさん:2017/04/21(金) 21:12:23.25 ID:JwbSy4qm
グロバール変数やめました
シングルトンもやめました
結果、
オブジェクトをたらい回しにしまくりんぐ地獄

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

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

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

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

308 :デフォルトの名無しさん:2017/04/23(日) 21:23:18.06 ID:mOY43HnC
staticおじさんは今日も元気でした

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

310 :デフォルトの名無しさん:2017/04/23(日) 23:16:24.84 ID:fe+cTrdN
勝ち負けだったのか

311 :デフォルトの名無しさん:2017/04/23(日) 23:26:57.94 ID:HqNmAyPa
>>310
負けは認めるんだな

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

313 :デフォルトの名無しさん:2017/04/24(月) 00:08:36.40 ID:ix3EvlHl
あとキャットドアって初めて聞いたんだけど何なの?

314 :デフォルトの名無しさん:2017/04/24(月) 00:13:48.70 ID:ix3EvlHl
>>キャットドア問題
ググってもAmazonしか出てこない、、、

315 :デフォルトの名無しさん:2017/04/24(月) 00:51:34.45 ID:eKiX5mKm
google「オブジェクト指向 キャットドア問題」
で出るな

316 :デフォルトの名無しさん:2017/04/24(月) 01:00:29.18 ID:ix3EvlHl
>>315
まじか!
ありがとう、見てみるよ

317 :デフォルトの名無しさん:2017/04/24(月) 01:02:48.58 ID:ix3EvlHl
なんか別のスレがヒットするだけなんだけどあってる?
http://itest.2ch.net/test/read.cgi/tech/1491118238/

318 :デフォルトの名無しさん:2017/04/24(月) 06:42:37.83 ID:DtGFy1JY
キャットドア問題って何だよ
博識な俺様でも知らんぞ

319 :デフォルトの名無しさん:2017/04/24(月) 19:56:51.33 ID:aju9PDoI
それを流行らせようとして必死なやつをどっかのスレで見たわ
放置推奨

320 :デフォルトの名無しさん:2017/04/24(月) 20:17:16.61 ID:MN8pW2Am
なんだ
騒ぎ立ててるヤツが居るだけなのね

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

321 :デフォルトの名無しさん:2017/04/24(月) 21:31:35.57 ID:Fbyj+dPJ
結局、キャットドア問題解決できなかったしね

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

323 :デフォルトの名無しさん:2017/04/25(火) 12:08:14.39 ID:5ILiyJO9
キャットドア問題が何を問題にしているのかわからない
合力できるように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

324 :デフォルトの名無しさん:2017/04/25(火) 19:47:55.64 ID:sSL6z0RB
staticおじさんは今日も大勝利

325 :デフォルトの名無しさん:2017/04/25(火) 20:11:32.58 ID:4og0+rzt
結局どんな勝負なの?

326 :デフォルトの名無しさん:2017/04/25(火) 21:16:26.91 ID:qd1hD0YR
>>325
結局、キャットドア問題解決できなかったしね

327 ::2017/04/25(火) 23:25:27.84 ID:RguWTiRy
キャットドアとやらが拠り所なのか…

328 :デフォルトの名無しさん:2017/04/25(火) 23:46:03.28 ID:qd1hD0YR
if cat door is open
human begining become
and we will we will goto heaven

329 :デフォルトの名無しさん:2017/04/25(火) 23:57:29.33 ID:qaES5lmc
ごめん、それでは理解できない
どんな勝負だったの?
勝利条件やルールは何だったの?

330 ::2017/04/26(水) 00:00:54.76 ID:R2CP97M0
何かの引用のもじりなんだろうか?
ひどい英語に見えるけどなんか意味あるのかな…

331 :デフォルトの名無しさん:2017/04/26(水) 00:19:05.94 ID:9BTWZVlt
>>329
逃げるのか?

332 :デフォルトの名無しさん:2017/04/26(水) 00:35:26.90 ID:1c8kYD+M
ネコ用のドアって蚊やハエが入って来ないの?

333 :デフォルトの名無しさん:2017/04/26(水) 06:46:17.53 ID:Ex4Hni8+
>>331
や、だから俺はそもそも勝負に参加してないっての
参加するにしても勝利条件とルールを聞いても誰も教えてくれないから参戦もできない

334 :デフォルトの名無しさん:2017/04/26(水) 06:52:05.72 ID:LAzkzAvR
>>333
マヌケなヤローだ

335 :デフォルトの名無しさん:2017/04/26(水) 07:00:16.63 ID:Ex4Hni8+
ああ
これは会話させてくれないやつだ

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

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

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

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

338 :デフォルトの名無しさん:2017/04/28(金) 12:21:14.12 ID:xTWRaXFB
それは抽象化ではないとだけ言っておこう

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

340 :デフォルトの名無しさん:2017/04/29(土) 00:17:16.42 ID:QOk6w6Nc
頭が悪いという事実以外にどこに問題があるのか

341 :デフォルトの名無しさん:2017/04/29(土) 01:10:48.87 ID:PKfhB/PA
まあな、お前らほど優秀な奴らがあの場にいたらキャットドア問題など発生すらしなかったんだろうなw

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

343 :デフォルトの名無しさん:2017/04/29(土) 14:57:30.88 ID:Y+QDu0qT
>>323
俺はこんなコード書きたくないなあ

344 :デフォルトの名無しさん:2017/04/29(土) 18:07:18.04 ID:LioC+4qb
>>343
お前が書かなくても>>323が書いてお前に保守させるから問題ない

345 :デフォルトの名無しさん:2017/04/29(土) 18:32:37.57 ID:u4T6eHTd
>>344
> お前に保守させるから

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

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

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

348 :デフォルトの名無しさん:2017/05/01(月) 21:37:55.53 ID:FwcOD9NG
作業性?

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

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

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

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

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

353 :デフォルトの名無しさん:2017/05/01(月) 22:22:57.53 ID:yowwCFAh
で、それって何?って言われれば
まとめて整理整頓術としか言いようがない

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

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

355 :デフォルトの名無しさん:2017/05/01(月) 22:51:43.47 ID:zOqzFQEM
> 整理整頓術

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

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

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

357 :デフォルトの名無しさん:2017/05/01(月) 23:05:09.52 ID:yowwCFAh
あと、整理整頓術も工場用語でも何でもないぞ

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

358 ::2017/05/01(月) 23:10:42.49 ID:nao9PwD/
工場での生産の作業性をぼんやりした形で適当に定義しないでほしいな。

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

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

360 :デフォルトの名無しさん:2017/05/01(月) 23:15:56.09 ID:cOn1eaku
>>357
もうちょっと整理整頓して文章書こうな(藁干草)

361 :デフォルトの名無しさん:2017/05/01(月) 23:17:09.68 ID:Qjntrl82
吉野家は3件全立してると思ってた

362 ::2017/05/01(月) 23:20:32.57 ID:nao9PwD/
>>361
高くはない、まずくはない、遅くもないものはなんとかなる。
その状態が、生産ラインの安定地点でもある。

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

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

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

365 :デフォルトの名無しさん:2017/05/02(火) 01:00:54.02 ID:E47XnT0a
整理整頓じゃなくてモデリングだな
設計とも言う

366 :デフォルトの名無しさん:2017/05/02(火) 04:16:06.60 ID:702+910T
オブジェクト指向って処理をソースのどこに書くかってだけの技術だしね
どんなにこねくり回しても直接的には1円にもならないんだよね
違うと認めないやつもいそうだけど
そろそろ自分が扱ってるモノの本質を見定めるべき

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

368 :デフォルトの名無しさん:2017/05/02(火) 08:01:47.95 ID:XmGRHQZl
>>366
お前のその考えじゃ一円も生み出せないわな

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

370 :デフォルトの名無しさん:2017/05/02(火) 09:26:50.56 ID:Spp7QSKK
経済の本質?ロボットによる自動化かね?

371 ::2017/05/02(火) 10:53:02.51 ID:Ua7wVMyf
>>363
個々に対応しない全体論なんてあるわけねえじゃん。
頭おかしいのか?

372 :デフォルトの名無しさん:2017/05/02(火) 23:05:52.32 ID:cIXPJSKK
じゃあお前キャットドア問題解けるの?

373 ::2017/05/04(木) 12:00:51.58 ID:iOTKQL/7
>>372
次世代言語の前スレで単なるオブジェクト指向では無理でしょ的にGoで断片書いた。

374 :デフォルトの名無しさん:2017/05/04(木) 13:02:33.28 ID:WFPOAInc
>>373
書いたじゃなくてその話をここでもう一度やれって言ってんだよ

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

376 :デフォルトの名無しさん:2017/05/04(木) 14:19:13.70 ID:Ugw5qKle
>>374
オレは>>323に書いた
これだと駄目な理由を早よ書け

377 :デフォルトの名無しさん:2017/05/04(木) 18:23:43.55 ID:7TNYL3q7
>>376
323のプログラムは何の役に立つの?

378 :デフォルトの名無しさん:2017/05/04(木) 19:20:07.24 ID:a0jn5Ofo
>>377
キャットドア問題が解けること

379 ::2017/05/04(木) 20:17:32.14 ID:iOTKQL/7
砂上の楼閣が作れるスコップみたいな話か。

380 :デフォルトの名無しさん:2017/05/04(木) 23:18:06.53 ID:BVx/80uV
>>377
分脈はおろかコードすら読めない奴がレスしてんじゃねーよ

381 :デフォルトの名無しさん:2017/05/04(木) 23:44:26.02 ID:7TNYL3q7
>>380
分脈!!

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

382 :デフォルトの名無しさん:2017/05/05(金) 02:35:43.37 ID:+77JIYq6
>>381
さながらキミは文脈わかったつもり系か

383 :デフォルトの名無しさん:2017/05/07(日) 08:39:23.39 ID:RHR/U83g
文脈系男子は帰って

384 :デフォルトの名無しさん:2017/05/23(火) 17:41:22.37 ID:kKBwFCtV
データと処理が分離してるクセに継承の嵐。
意味不明なラムダ式の多様。
意味不明なabstract縛り
邪魔なprivate宣言
csvの共通クラスだけで10以上のクラス

悪夢を見てるようだ。

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

385 :デフォルトの名無しさん:2017/05/23(火) 21:49:08.89 ID:PZYq3vzy
全てのメソッドにstatic付けられてから嘆け雑魚が

386 :デフォルトの名無しさん:2017/05/24(水) 12:02:36.26 ID:VdpFCLoQ
ドヤ顔で言語仕様に振り回されて無駄だらけで読みづらいクソコード量産すんなって話だな。
全部staticのほうが逆に使いやすいなんてのは、もう目も当てられない。
中途半端にスキルあるヤツに多いんだよなあ。

387 :デフォルトの名無しさん:2017/05/24(水) 17:58:34.22 ID:IXUmJ/sE
>>386
その中途半端なスキルの奴は、もう次の段階に行ってるよ。
そうやって設計手法に振り回されながらも実践し、失敗を繰り返すことで成長していくんだから。
で、お前はそいつの成長過程で産み落とされたゴミをメンテする役ね。成長はないけどまぁ食っていけてるならいいんじゃない。

388 :デフォルトの名無しさん:2017/05/24(水) 21:18:50.72 ID:VdpFCLoQ
レッテル張りして、プンスカ怒ってるみたいだけど、そうとう図星だったか。
設計ミスるのも程々にしとき。

389 :デフォルトの名無しさん:2017/05/24(水) 22:12:57.77 ID:krzOkTvb
>>388
お前は設計ミスなんてしないもんな
なぜなら設計したことがないからw

390 :デフォルトの名無しさん:2017/05/25(木) 00:25:16.97 ID:hLFywp3s
なんか、もういいや。建設的じゃねーし。

120 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)