2ちゃんねる★スマホ版★■掲示板に戻る■全部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 :
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
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
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 :
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 :
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 メルアドのみで数年やれるか(なら文字列でサクっと実装しちまえよ)による
128KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: