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

uy ◆e6.oHu1j.o · 2016/07/09(土) 00:35:13.95

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

**デフォルトの名無しさん** · 2016/07/09(土) 00:40:05.67

スレ立て乙

今回はどうなるものやら

**デフォルトの名無しさん** · 2016/07/09(土) 02:21:37.29

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

**デフォルトの名無しさん** · 2016/07/09(土) 02:35:54.68

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

2016/07/10(日) 09:45:08.81

>>3

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

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

**デフォルトの名無しさん** · 2016/07/11(月) 19:21:45.70

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

**デフォルトの名無しさん** · 2016/07/11(月) 21:38:01.16

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

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

**デフォルトの名無しさん** · 2016/07/11(月) 21:42:08.33

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

**デフォルトの名無しさん** · 2016/07/11(月) 21:50:23.51

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

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

**デフォルトの名無しさん** · 2016/07/11(月) 21:53:10.62

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

**デフォルトの名無しさん** · 2016/07/11(月) 21:55:32.79

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

**デフォルトの名無しさん** · 2016/07/11(月) 22:01:49.58

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

**デフォルトの名無しさん** · 2016/07/11(月) 22:09:20.16

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

**デフォルトの名無しさん** · 2016/07/11(月) 22:13:53.85

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

**デフォルトの名無しさん** · 2016/07/11(月) 22:21:48.36

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

**デフォルトの名無しさん** · 2016/07/11(月) 22:23:16.01

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:27:03.16

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

おまえ向いてないよ

**デフォルトの名無しさん** · 2016/07/11(月) 23:30:23.93

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

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:33:42.75

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:36:48.16

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:37:44.57

　　　　　　　　.＿＿＿＿＿＿
.　　　　　　　　|　　　　|　　　　|
　　　∩∩　 |　　　|　　　　| 　∩∩
　　　 | | | |　 |　　　　|　　　　| 　| | | |　　／￣￣￣￣￣￣￣￣￣￣￣
　　　 (　　,,)　 |　　　|　　　　|　(・ｘ・）＜おらっ！出てこい、 ID:aTiidMol
　　　/　　つ━━"....ﾛ|ﾛ　 .　|　l　　 |Ｕ　＼＿＿＿＿＿＿＿＿＿＿＿
　～（　　/　　 |　　　　|　　　　|⊂＿　|～
　　　し'∪　　└──┴──┘　　∪

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:39:31.75

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:41:00.30

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:45:26.00

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:48:51.28

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:58:21.13

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

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

**デフォルトの名無しさん** · 2016/07/11(月) 23:59:14.37

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

**デフォルトの名無しさん** · 2016/07/12(火) 00:14:23.00

using使え

**デフォルトの名無しさん** · 2016/07/12(火) 00:18:40.28

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

**デフォルトの名無しさん** · 2016/07/12(火) 00:42:17.97

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 00:45:40.75

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 00:48:43.19

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

**デフォルトの名無しさん** · 2016/07/12(火) 00:49:55.80

>>32
アナルほど凍死罵

**デフォルトの名無しさん** · 2016/07/12(火) 01:02:14.20

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:03:49.06

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:09:39.99

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:11:50.86

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:17:32.84

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:36:55.20

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:37:15.67

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

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

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:38:38.08

文中の例えばは間違い

**デフォルトの名無しさん** · 2016/07/12(火) 01:38:41.27

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:45:58.42

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

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:48:36.07

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:55:35.82

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

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:58:01.82

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 01:59:34.67

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 02:01:08.65

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

**デフォルトの名無しさん** · 2016/07/12(火) 02:01:24.87

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 02:21:04.05

>>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するなってのは環境的な問題もあるとは思うんだが。

**デフォルトの名無しさん** · 2016/07/12(火) 02:28:01.69

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

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 02:33:58.13

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

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 02:36:15.80

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

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

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

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 03:23:53.60

>>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の付け足しから感じた。

**デフォルトの名無しさん** · 2016/07/12(火) 04:39:01.98

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

**デフォルトの名無しさん** · 2016/07/12(火) 06:14:29.07

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 06:16:12.63

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 08:53:57.34

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

**デフォルトの名無しさん** · 2016/07/12(火) 10:05:30.22

ところでOOPと関係ある？

**デフォルトの名無しさん** · 2016/07/12(火) 10:09:09.18

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

**デフォルトの名無しさん** · 2016/07/12(火) 10:09:59.26

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

**デフォルトの名無しさん** · 2016/07/12(火) 10:10:01.65

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

**デフォルトの名無しさん** · 2016/07/12(火) 11:43:29.90

>>17はずれてるだろ

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

**デフォルトの名無しさん** · 2016/07/12(火) 20:39:39.22

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

**デフォルトの名無しさん** · 2016/07/12(火) 21:54:41.73

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

**デフォルトの名無しさん** · 2016/07/12(火) 22:51:05.48

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 22:57:14.06

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

**デフォルトの名無しさん** · 2016/07/12(火) 23:25:13.63

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

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

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

**デフォルトの名無しさん** · 2016/07/12(火) 23:28:42.89

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 00:20:45.58

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

**デフォルトの名無しさん** · 2016/07/13(水) 00:26:34.83

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

**デフォルトの名無しさん** · 2016/07/13(水) 00:44:09.12

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 00:48:21.46

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

**デフォルトの名無しさん** · 2016/07/13(水) 00:49:32.32

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

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

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

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 00:50:08.11

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

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 00:53:31.98

>>65
まずMain関数はこれだけだ。
これ以外不要。

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

**デフォルトの名無しさん** · 2016/07/13(水) 00:59:57.51

CreateTempFileの中身はこうだな

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 01:03:40.12

結局のところこの程度であれば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のようにシンプルのままでいられる。

**デフォルトの名無しさん** · 2016/07/13(水) 01:19:00.17

なにこのキモいスレｗ

**デフォルトの名無しさん** · 2016/07/13(水) 02:08:26.36

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

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

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

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 02:16:26.70

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

例外保証ってなんや？

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 03:23:41.31

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

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

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 06:01:23.07

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