オブジェクト指向システムの設計 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/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
的確な指摘じゃない？
どうみても下の方が出来がいい

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

>>80
>契約プログラミング
C++だとBoost.Contract
.NetだとSystem.Diagnostics.Contracts
があるね
使ったことないけど

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

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

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

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

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

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

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

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

おはようございます！
ご回答ありがとうごさいました。
そうかー難しいのか。
難しいということはたまに言われますが、なにが難しいのかわからなくていつも悩んでいるので、自分は設計には向いていないのかもしれません。
下流で頑張ります。
皆さんも今日一日頑張ってください！
それでは！

**デフォルトの名無しさん** · 2016/07/13(水) 09:37:32.17

>>84
> .Netにも例外を投げるInt32.Perseと投げないInt32.TryPersreの2種類があるし

名前が重要なんだよ。（ちなみにParseな）

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

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

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

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

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

そんなに力説するほどの事か？w

**デフォルトの名無しさん** · 2016/07/13(水) 21:38:19.72

>>87
これは力説するほどのことだよ。
なぜなら可読性の話だから。

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

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 21:54:55.05

それなら問うが
Parseが返すパーズした結果とは何ぞや？
TryParseが返すトライした結果とは何ぞや？
俺には名前だけではさっぱり分からんのだが
これがお前の望む適切な名前とはとても思えんのだがw

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

>>89
友情努力勝利に決まってるだろ

**デフォルトの名無しさん** · 2016/07/13(水) 22:31:57.93

正直TryParseで変換できちゃうのはちょっと気持ち悪い

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

>>84
例外をエラー通知として使う分にはその辺は知らなくていいんだよ。
ただ、例外で復旧させようとするのなら、その辺を全て把握する必要がある。
そして彼等はそれにも耐えられるようにSTLを整備しようとしている。
それは無駄なコストを発生するから、それについて彼等も議論しているわけだ。

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

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

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

> 必要があれば戻り値のエラー通知を部分的に使うのはかまわないと思うよ
個人的にはTryParseをよく使っている。それで十分だから。
必要性はない。try/catchでも書ける。

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

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

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

**デフォルトの名無しさん** · 2016/07/13(水) 22:45:05.83

生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割は無限大になるというお気楽仕様だ。
当初は驚いたが、正直これで問題ないよなとも思う。

**デフォルトの名無しさん** · 2016/07/13(水) 22:58:10.35

>>89
> Parseが返すパーズした結果とは何ぞや？

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

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

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

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

Int32.Parse　だからといって、必ずInt32が返るとは限らないだろ
おまえは、human.age()で必ずhumanが返ると考えるか？

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

>>94
> なおJavaScriptは0割は無限大になるというお気楽仕様だ。

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

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

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

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

いっとくが、human.age()で必ずintが返るとは限らないからな
もしかしたらageオブジェクトが返るかもしれないからな

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

>>96
> Int32.Parse　だからといって、必ずInt32が返るとは限らないだろ
> おまえは、human.age()で必ずhumanが返ると考えるか？

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

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

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

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

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

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

>>94
> 他の関数型言語の例外機構ってどうなっているんだ？知ってたらよろしく。

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

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

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

>>100
> ヒューマンパーズオブジェクトが返るかもしれないだろ

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

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

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

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

型を見りゃいいだろ

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

**デフォルトの名無しさん** · 2016/07/14(木) 00:31:59.76

>>102
いやお前それ苦しいだろ

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

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

**デフォルトの名無しさん** · 2016/07/14(木) 01:02:32.63

>>104
言うと思ったｗ

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

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

**デフォルトの名無しさん** · 2016/07/14(木) 01:31:15.59

>>101
>関数型で戻り値でエラー情報なんか返したら
>エラー情報が返ってきたら、if式による分岐の嵐でもはや

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

**デフォルトの名無しさん** · 2016/07/14(木) 06:27:39.21

自分の思い込みの通りなら良い設計良いコードw

**デフォルトの名無しさん** · 2016/07/14(木) 07:26:28.53

正しく意図した通りに騙してくれるなら
明らかに良いコードだろ
頭のてっぺんからケツのシワまで数え上げてようやく読解できるコードが糞じゃなきゃ何なんだ

**デフォルトの名無しさん** · 2016/07/14(木) 07:44:38.40

クソの主観によりクソ認定されたコード達w
本当は良い奴も沢山いただろうに不憫だわーw

**デフォルトの名無しさん** · 2016/07/14(木) 08:31:57.85

車輪の再発明しか出来ない人がいると聞いて。

**デフォルトの名無しさん** · 2016/07/15(金) 23:14:34.82

DAO とかDTO ってのが出てくるアーキテクチャは手続き型であって、オブジェクト指向ではない

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

**デフォルトの名無しさん** · 2016/07/15(金) 23:20:25.90

そんな嘘ついちゃいけないんだお

**デフォルトの名無しさん** · 2016/07/15(金) 23:39:15.88

今の日本人は>>111みたいな馬鹿が普通なんだお

**デフォルトの名無しさん** · 2016/07/21(木) 22:59:46.89

>>113
やはり解る人はいないか
DAOやDTOってのはデータと処理を分離するから手続き的なんだがなぁ

**デフォルトの名無しさん** · 2016/07/21(木) 23:36:49.83

オブジェクト指向なのはEntityを使ったタイプのO/Rマッパーだね。
Railsとかもそう。DAOやDTOなんてのは出てこないで
データベースがオブジェクトにそのままマッピングされる。

**デフォルトの名無しさん** · 2016/07/22(金) 08:12:39.95

抽象化が過ぎて解る人がいないだけ

**デフォルトの名無しさん** · 2016/07/22(金) 18:14:47.22

>>111
主張が良くわからない。

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

**デフォルトの名無しさん** · 2016/07/30(土) 00:56:46.87

言いたいのは単純に

DAO/DTO

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

それだけだろ。

**デフォルトの名無しさん** · 2016/07/30(土) 02:56:03.60

んなことゆーたら全部手続きですやんける

**デフォルトの名無しさん** · 2016/07/30(土) 02:57:31.49

>>119
程度の問題

**デフォルトの名無しさん** · 2016/07/30(土) 03:07:28.00

単に>>114が知ったかぶりしたいだけだろ。
>>111の段階で明らかだし。

**デフォルトの名無しさん** · 2016/07/30(土) 08:02:13.88

>>118
逆だろ
使うのはオブジェクト指向にするためで
その実装の中身は程度の差こそあれ
DBを相手にする以上手続き的にならざるを得ない

**デフォルトの名無しさん** · 2016/07/30(土) 08:03:21.46

知ったかぶりにすらなってなくて意味のない単語の羅列にすぎん

**デフォルトの名無しさん** · 2016/08/04(木) 16:27:41.40

クラスの中に別のクラスをコンポジットしてあり、
そのクラスの中にも別のクラスをコンポジットしてあり…という場合、

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

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

**デフォルトの名無しさん** · 2016/08/04(木) 19:08:09.61

別に良いけど
innerClass.set_valueが呼ばれて値が変更されたときに
変更されたことをouterClassやmiddleClassに通知する仕組みが必要になるかもしれないよ
この場合、余計にややこしくなる

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

**デフォルトの名無しさん** · 2016/08/04(木) 20:37:30.59

>>124
O/Rマッパーを使うからそういう処理は
勝手にやってくれる。

**デフォルトの名無しさん** · 2016/08/04(木) 22:17:26.33

>>124
更に言えば
実装方法としても、set_valueは分かり難いし楽でも何でもない
あえてやるなら
outerClass.set_value(key, value)とか？

**デフォルトの名無しさん** · 2016/08/04(木) 22:24:04.58

>>127
最低のやり方だな
そのk,vのMap、実行するまで完全なブラックボックスになるじゃん
死んで、どうぞ

**デフォルトの名無しさん** · 2016/08/04(木) 23:34:15.07

>>127
くっせ～なホント
こういうペチプ～崩れの塵屑見ると延髄チョップからのバックドロップ食らわせてやりたくなるわ
まじな。死ね。

**デフォルトの名無しさん** · 2016/08/04(木) 23:36:44.15

なんでもarrayにしときゃいいと思ってるド低脳
チンパンジー以下のサルゥ
ほんとつっかえ・・・

**デフォルトの名無しさん** · 2016/08/04(木) 23:37:05.58

>>127
血染めの赤にしてやる
死ね

**デフォルトの名無しさん** · 2016/08/04(木) 23:46:15.09

>>127
おら何とか言えよゴミ
ID変わるまで逃げるのか？
ほんまつっかえゴミくずやな～

**デフォルトの名無しさん** · 2016/08/05(金) 07:18:34.18

イコール代入するなら、最後は明示されたセッター呼ぶのは中途半端な気がする。

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

**デフォルトの名無しさん** · 2016/08/05(金) 10:32:18.42

結論
余計なことはするな

**デフォルトの名無しさん** · 2016/08/10(水) 22:14:29.57

株式会社TOUAが2016年7月に破産
http://www.tdb.co.jp/tosan/syosai/4191.html

**デフォルトの名無しさん** · 2016/08/11(木) 00:00:42.11

>>135
派遣会社ってピンハネしかしてないのに潰れるの?

**デフォルトの名無しさん** · 2016/08/11(木) 00:16:35.15

>>136
トウアは仕事をしない、仕事ができない人間を抱えすぎていたのと、資金がもともとないのにオフィスを分散させたり、複数社のグループにしていたせいで効率が悪かった。

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

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

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

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

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

**デフォルトの名無しさん** · 2016/09/10(土) 13:15:16.78

予想通り、誰もいなくなったのね。

**デフォルトの名無しさん** · 2016/09/10(土) 15:03:56.80

static Koma.move() の頃がおまいら一番輝いてたね}

**デフォルトの名無しさん** · 2016/09/17(土) 22:40:32.14

人の意見を聞かずにバッサリ切り捨てる、典型的な２ch脳な人が
のさばり出した時点で離れた。

**デフォルトの名無しさん** · 2016/09/19(月) 10:09:43.20

それぞれに結論がでてる状態なんだろ？
俺も一連のやりとりでオブジェクト指向ってやっぱりクソだなって再認識した

**デフォルトの名無しさん** · 2016/09/19(月) 11:03:13.57

やっぱり誰でもわかる手続き型がナンバーワン

**デフォルトの名無しさん** · 2016/09/19(月) 12:18:29.50

手続き型は誰でもわかるが工数が多すぎてな
ビジネスでやる以上工数は節約しなきゃ

**デフォルトの名無しさん** · 2016/09/19(月) 12:59:11.35

誰でもわかる明朗なコードを書かなくてはいけない
ビジネスだからこそ、手続き型がナンバーワン
ビジネスは君の趣味ではない

**デフォルトの名無しさん** · 2016/09/19(月) 13:02:51.87

ビジネスだからこそお荷物は解雇しなきゃならない
ある程度の能力のある人間が工数を減らせる手法で開発する
工数の掛かる手続き型しか書けない読めない人は解雇するべきビジネスだから

**デフォルトの名無しさん** · 2016/09/19(月) 13:08:18.37

趣味をビジネスに持ち出すオタクはNGですよ、これ常識ｗ

**デフォルトの名無しさん** · 2016/09/19(月) 14:10:27.86

成長しない新米プログラマをいつまでも傭い続けるわけにはいかない
ビジネスってさボランティアじゃないんだよね

**デフォルトの名無しさん** · 2016/09/19(月) 14:18:05.63

で、君らはまたstatic final Koma.move(int kyori)すんの？

**デフォルトの名無しさん** · 2016/09/19(月) 14:29:03.47

回り将棋ならいいかもしれない

**デフォルトの名無しさん** · 2016/12/27(火) 23:00:43.33

ViewModelってどのレイヤーに属するんだ？
Viewに関する知識はないからUIレイヤーではないだろう
ビジネスルールに関する知識は必要だからドメインレイヤー？

**デフォルトの名無しさん** · 2016/12/27(火) 23:06:49.29

UIレイヤーの中のドメインレイヤーとの境界面、じゃないの

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

あ、あとViewModelに必要な知識はビジネスルールじゃなくて
ドメインレイヤーのインターフェースだけじゃないのかな？
ビジネスルールに関することはモデル内で処理するべきだと思って作ってるけど…

**デフォルトの名無しさん** · 2016/12/27(火) 23:37:51.54

>>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にビジネスルールが染み出してしまう

**デフォルトの名無しさん** · 2016/12/28(水) 00:02:52.91

自分は個人で作ってるだけで好きなようにやれるからだけど、
そういう場合、自分はxもyもそのままモデルに投げてその処理はいったんそこで終わり。
モデルで値をチェックしてエラーならエラーイベント発生
→入力用ViewModelがそのイベントを受け取ってViewに伝えるDataErrorイベント発生
→Viewが変化

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

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

**デフォルトの名無しさん** · 2016/12/28(水) 20:24:38.28

限界あるな
xにうんこって入れられても一旦は保存するってことだろそれ
まさにクソまみれ

**デフォルトの名無しさん** · 2016/12/28(水) 21:08:30.55

ViewModelが勝手に「これはうんこだ！捨てておこう！」「これはうんこじゃない！大丈夫だ！」
なんてやってる方が、いずれシステムがうんこまみれになる危険が高い気がするが…

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

**デフォルトの名無しさん** · 2016/12/28(水) 21:55:12.03

>>156
じゃあ超長い文字列とかも一旦は保存するんだろ?
思想に限界があるって気付けよ

**デフォルトの名無しさん** · 2016/12/28(水) 22:03:00.40

そもそも画面仕様が専用であるはずなのに
データ型のみModel依存ってこだわりがうんこ
画面なんか内部も含めて作り捨て上等だろ

**デフォルトの名無しさん** · 2016/12/28(水) 22:06:08.16

次の変更は一度にたくさん入力したいのでExcelかcsvから読み込んでもらえますか?
だったら一生懸命付けた汎用性もm9(^Д^)ﾌﾟｷﾞｬｰ

**デフォルトの名無しさん** · 2016/12/28(水) 23:01:11.92

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

**デフォルトの名無しさん** · 2016/12/29(木) 00:14:19.42

一切関知すべきじゃないな。
うんこかもしれないもの、としてVM以降に渡して、うんこではないものを貰うしか無い。

**デフォルトの名無しさん** · 2016/12/29(木) 00:36:39.28

それだと使い勝手は悪くなるな

**デフォルトの名無しさん** · 2016/12/29(木) 02:16:04.01

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

**デフォルトの名無しさん** · 2016/12/29(木) 02:36:25.34

>>163
何を誤解してるかわからんが、それは、ビューモデル以外の場所で即座に否定されたり、是正されたり、これはは間違ってますよとエラーと判定されるから、
ビューモデルは、判定結果をおとなしく持って、ビューにレンダリングしてもらうだけじゃん。

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

**デフォルトの名無しさん** · 2016/12/29(木) 08:38:21.22

>>164
だからさ
その構造を実現することになんの意味があるのって話