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

■ このスレッドは過去ログ倉庫に格納されています
1uy ◆e6.oHu1j.o
垢版 |
2016/07/09(土) 00:35:13.95ID:Mn3UGZ+O
前スレ
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/
2016/07/13(水) 02:16:26.70ID:2JhFq5Nw
> 当然STLや自前クラスがどの例外保証を持っているかすべて把握してないと駄目だし、

例外保証ってなんや？

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

気をつけることがあるとしたら、それは戻り値でも同じだし
正常処理とエラーを、一つの戻り値（変数）に入れる分
複雑度は上がるんだぞ。
2016/07/13(水) 03:23:41.31ID:vjGvgzcz
>>65
ディレクトリを作れない時に、throwして外のスコープに飛ばすのは、ややこしい。
そこでエラー処理できる

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

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

修正・保守していくうちに、こういうのがいずれ、スパゲティ・泥団子へと成長していき、
誰の手にも負えないようになっていく
2016/07/13(水) 06:01:23.07ID:QAw5IbxT
>>65
的確な指摘じゃない？
どうみても下の方が出来がいい
2016/07/13(水) 06:22:04.43ID:7t1kL6eB
>>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.92ID:L2fL/y00
おはようございます！
ご回答ありがとうごさいました。
そうかー難しいのか。
難しいということはたまに言われますが、なにが難しいのかわからなくていつも悩んでいるので、自分は設計には向いていないのかもしれません。
下流で頑張ります。
皆さんも今日一日頑張ってください！
それでは！
2016/07/13(水) 09:37:32.17ID:2JhFq5Nw
>>84
> .Netにも例外を投げるInt32.Perseと投げないInt32.TryPersreの2種類があるし

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

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

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

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

その2つは、例外を投げるかどうかの違いじゃなくてやる処理の違い。
そしてどちらもやるべきことができなければ、例外を返す。
87デフォルトの名無しさん
垢版 |
2016/07/13(水) 19:05:13.08ID:OE4fGXcq
そんなに力説するほどの事か？w
2016/07/13(水) 21:38:19.72ID:2JhFq5Nw
>>87
これは力説するほどのことだよ。
なぜなら可読性の話だから。

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

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

たまに適当な関数名つけてる人がいるけど、ほんとやめてほしい。
適当な単語を並べただけじゃソースコード読めないから。
名前から意味がわからないから、中の処理を読んで解析しないといけなくなる。
89デフォルトの名無しさん
垢版 |
2016/07/13(水) 21:54:55.05ID:OE4fGXcq
それなら問うが
Parseが返すパーズした結果とは何ぞや？
TryParseが返すトライした結果とは何ぞや？
俺には名前だけではさっぱり分からんのだが
これがお前の望む適切な名前とはとても思えんのだがw
2016/07/13(水) 22:01:55.88ID:lnUCd6s/
>>89
友情努力勝利に決まってるだろ
2016/07/13(水) 22:31:57.93ID:oLxbX2RO
正直TryParseで変換できちゃうのはちょっと気持ち悪い
2016/07/13(水) 22:44:01.74ID: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))
2016/07/13(水) 22:44:36.15ID:uq0wU9fp
> 必要があれば戻り値のエラー通知を部分的に使うのはかまわないと思うよ
個人的にはTryParseをよく使っている。それで十分だから。
必要性はない。try/catchでも書ける。

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

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

ちなみに、言語的な例外復旧能力に必ずしも頼る必要はない。
上位レベルでの復旧も実は簡単だからだ。
例えばTryParse、ファイルから読むのならソースは保持する必要がない。
Seek出来ないネットワークストリーム等なら、MemoryStreamに一旦受ければいい。
JSONみたいに階層ありオブジェクトを丸々生成するのなら、成功した後に差し替えればいい。
これらの場合は、ロールバックを上位で行うことはほぼ自然に出来てしまうので、
結果的にSTLが実装した例外機構の為に無駄に税金を払う事にしかならない。
この点を修正しようというnoexceptはC++っぽくていいが、
なるほどこんな事をやっているうちは生Cを駆逐することは出来ないだろう。
2016/07/13(水) 22:45:05.83ID: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割は無限大になるというお気楽仕様だ。
当初は驚いたが、正直これで問題ないよなとも思う。
2016/07/13(水) 22:58:10.35ID:2JhFq5Nw
>>89
> Parseが返すパーズした結果とは何ぞや？

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

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

あー、うん。クラス名が先に作ってことに
気づかなかったのねｗ
>>86で引用してる>>84にかいてあんだろ。
気づけよｗ
2016/07/13(水) 23:09:44.65ID:jyyAd6hv
Int32.Parse　だからといって、必ずInt32が返るとは限らないだろ
おまえは、human.age()で必ずhumanが返ると考えるか？
2016/07/13(水) 23:11:23.52ID:2JhFq5Nw
>>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.03ID:jyyAd6hv
いっとくが、human.age()で必ずintが返るとは限らないからな
もしかしたらageオブジェクトが返るかもしれないからな
2016/07/13(水) 23:12:49.31ID:2JhFq5Nw
>>96
> Int32.Parse　だからといって、必ずInt32が返るとは限らないだろ
> おまえは、human.age()で必ずhumanが返ると考えるか？

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

human.parseだったら、human返すんじゃねーの？
2016/07/13(水) 23:13:53.29ID:jyyAd6hv
>human.parseだったら、human返すんじゃねーの？

そんなの思い込みだろ
ヒューマンパーズオブジェクトが返るかもしれないだろ
2016/07/13(水) 23:18:25.58ID:2JhFq5Nw
>>94
> 他の関数型言語の例外機構ってどうなっているんだ？知ってたらよろしく。

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

関数呼び出しの中の、関数呼び出しの中の、関数呼び出しの中の、関数呼び出し で
エラー情報が返ってきたら、if式による分岐の嵐でもはや
関数型言語のように見えないだろうね。
2016/07/13(水) 23:22:40.62ID:2JhFq5Nw
>>100
> ヒューマンパーズオブジェクトが返るかもしれないだろ

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

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

なにも100%完全に返り値の情報がわかるなんて言ってないんだよw
2016/07/13(水) 23:36:52.14ID:C7S+nyqs
型を見りゃいいだろ

まさかこのスレに居ながら、屁臭いペチプ〜やゴミのペールやペールの糞からひり出されたルビーや・・・そんな糞まみれのウンコ野郎はおるまいね？
2016/07/14(木) 00:31:59.76ID:4Ps/X1K6
>>102
いやお前それ苦しいだろ

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

想像？
思い込みでしょ
ヒューマンパーズオブジェクトが返るかもしれない、とは書いたが
実際には何が返るかわからないから、そう書いただけであって
どうせ、仕様を調べなきゃならないんだよ
2016/07/14(木) 01:02:32.63ID:9qkjMq+e
>>104
言うと思ったｗ

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

適切な名前があると覚やすいっていうのはこういうこと。
2016/07/14(木) 01:31:15.59ID:rhZMoeJF
>>101
>関数型で戻り値でエラー情報なんか返したら
>エラー情報が返ってきたら、if式による分岐の嵐でもはや

ifの分岐しないためにfunctorだのアプリカティブだのmonadだのtraverseがあるじゃん？
try1 >=> try2 >=> try3 >=> ... tryN
みたいので「成功するまで処理を続けて失敗したら例外情報をもって途中で抜ける関数」を作れるし
こういう合成力は関数型の強み
107デフォルトの名無しさん
垢版 |
2016/07/14(木) 06:27:39.21ID:cfi8dg7p
自分の思い込みの通りなら良い設計良いコードw
2016/07/14(木) 07:26:28.53ID:xgZTwt3g
正しく意図した通りに騙してくれるなら
明らかに良いコードだろ
頭のてっぺんからケツのシワまで数え上げてようやく読解できるコードが糞じゃなきゃ何なんだ
109デフォルトの名無しさん
垢版 |
2016/07/14(木) 07:44:38.40ID:cfi8dg7p
クソの主観によりクソ認定されたコード達w
本当は良い奴も沢山いただろうに不憫だわーw
2016/07/14(木) 08:31:57.85ID:qme/E7bl
車輪の再発明しか出来ない人がいると聞いて。
2016/07/15(金) 23:14:34.82ID:/IkQTUfk
DAO とかDTO ってのが出てくるアーキテクチャは手続き型であって、オブジェクト指向ではない

ってのが解る人ここにいるか?
2016/07/15(金) 23:20:25.90ID:sS/v2c9e
そんな嘘ついちゃいけないんだお
113デフォルトの名無しさん
垢版 |
2016/07/15(金) 23:39:15.88ID:iR/HdeCl
今の日本人は>>111みたいな馬鹿が普通なんだお
2016/07/21(木) 22:59:46.89ID:6Fy4Bz7m
>>113
やはり解る人はいないか
DAOやDTOってのはデータと処理を分離するから手続き的なんだがなぁ
2016/07/21(木) 23:36:49.83ID:vaQfL518
オブジェクト指向なのはEntityを使ったタイプのO/Rマッパーだね。
Railsとかもそう。DAOやDTOなんてのは出てこないで
データベースがオブジェクトにそのままマッピングされる。
2016/07/22(金) 08:12:39.95ID:OQdSZmk7
抽象化が過ぎて解る人がいないだけ
2016/07/22(金) 18:14:47.22ID:fQzF4pQd
>>111
主張が良くわからない。

http://www.nulab.co.jp/designPatterns/designPatterns3/designPatterns3-4.html
に出てくる例と説明にそって、論を展開してみてくれ。
118デフォルトの名無しさん
垢版 |
2016/07/30(土) 00:56:46.87ID:crIAC8Sk
言いたいのは単純に

DAO/DTO

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

それだけだろ。
2016/07/30(土) 02:56:03.60ID:YgaIk6dE
んなことゆーたら全部手続きですやんける
2016/07/30(土) 02:57:31.49ID:6YLFMraq
>>119
程度の問題
2016/07/30(土) 03:07:28.00ID:crIAC8Sk
単に>>114が知ったかぶりしたいだけだろ。
>>111の段階で明らかだし。
2016/07/30(土) 08:02:13.88ID:gkAo/Cig
>>118
逆だろ
使うのはオブジェクト指向にするためで
その実装の中身は程度の差こそあれ
DBを相手にする以上手続き的にならざるを得ない
123デフォルトの名無しさん
垢版 |
2016/07/30(土) 08:03:21.46ID:cz6waps9
知ったかぶりにすらなってなくて意味のない単語の羅列にすぎん
124デフォルトの名無しさん
垢版 |
2016/08/04(木) 16:27:41.40ID:pdTKskF+
クラスの中に別のクラスをコンポジットしてあり、
そのクラスの中にも別のクラスをコンポジットしてあり…という場合、

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

カプセル化せずに
outerClass.middleClass.innerClass.set_value(100);
とした方が楽だと思うのですがまずいでしょうか？
2016/08/04(木) 19:08:09.61ID:w6fnMNqO
別に良いけど
innerClass.set_valueが呼ばれて値が変更されたときに
変更されたことをouterClassやmiddleClassに通知する仕組みが必要になるかもしれないよ
この場合、余計にややこしくなる

そのほかのディメリットはカプセル化しないことで発生するディメリットと同じ
2016/08/04(木) 20:37:30.59ID:jTAWnEUa
>>124
O/Rマッパーを使うからそういう処理は
勝手にやってくれる。
2016/08/04(木) 22:17:26.33ID:9BD7w8j0
>>124
更に言えば
実装方法としても、set_valueは分かり難いし楽でも何でもない
あえてやるなら
outerClass.set_value(key, value)とか？
2016/08/04(木) 22:24:04.58ID:dkWDRS+N
>>127
最低のやり方だな
そのk,vのMap、実行するまで完全なブラックボックスになるじゃん
死んで、どうぞ
2016/08/04(木) 23:34:15.07ID:dkWDRS+N
>>127
くっせ〜なホント
こういうペチプ〜崩れの塵屑見ると延髄チョップからのバックドロップ食らわせてやりたくなるわ
まじな。死ね。
2016/08/04(木) 23:36:44.15ID:dkWDRS+N
なんでもarrayにしときゃいいと思ってるド低脳
チンパンジー以下のサルゥ
ほんとつっかえ・・・
2016/08/04(木) 23:37:05.58ID:dkWDRS+N
>>127
血染めの赤にしてやる
死ね
2016/08/04(木) 23:46:15.09ID:dkWDRS+N
>>127
おら何とか言えよゴミ
ID変わるまで逃げるのか？
ほんまつっかえゴミくずやな〜
2016/08/05(金) 07:18:34.18ID:ZdrtHNhg
イコール代入するなら、最後は明示されたセッター呼ぶのは中途半端な気がする。

各クラスにユーティリティメソッド実装できるなら、
outerClass.getNodeFromPath("middleClass.innerClass").set_value(xxx)
とか取得関数持っちゃうと、文字列だけ不細工だけどなんとでもなったりするんじゃないかな。
2016/08/05(金) 10:32:18.42ID:VlcB2rw7
結論
余計なことはするな
135デフォルトの名無しさん
垢版 |
2016/08/10(水) 22:14:29.57ID:UWZg55pn
株式会社TOUAが2016年7月に破産
http://www.tdb.co.jp/tosan/syosai/4191.html
2016/08/11(木) 00:00:42.11ID:0L+mrDki
>>135
派遣会社ってピンハネしかしてないのに潰れるの?
137デフォルトの名無しさん
垢版 |
2016/08/11(木) 00:16:35.15ID:OU7OxTj6
>>136
トウアは仕事をしない、仕事ができない人間を抱えすぎていたのと、資金がもともとないのにオフィスを分散させたり、複数社のグループにしていたせいで効率が悪かった。

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

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

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

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

ドコモあたりのアホ企業頼みだった。
2016/09/10(土) 13:15:16.78ID:twqmh/TK
予想通り、誰もいなくなったのね。
2016/09/10(土) 15:03:56.80ID:+QFLkWhC
static Koma.move() の頃がおまいら一番輝いてたね}
2016/09/17(土) 22:40:32.14ID:hd6Wyy09
人の意見を聞かずにバッサリ切り捨てる、典型的な２ch脳な人が
のさばり出した時点で離れた。
2016/09/19(月) 10:09:43.20ID:bJUofi69
それぞれに結論がでてる状態なんだろ？
俺も一連のやりとりでオブジェクト指向ってやっぱりクソだなって再認識した
2016/09/19(月) 11:03:13.57ID:KUojTFe6
やっぱり誰でもわかる手続き型がナンバーワン
2016/09/19(月) 12:18:29.50ID:0K/woKyj
手続き型は誰でもわかるが工数が多すぎてな
ビジネスでやる以上工数は節約しなきゃ
2016/09/19(月) 12:59:11.35ID:KUojTFe6
誰でもわかる明朗なコードを書かなくてはいけない
ビジネスだからこそ、手続き型がナンバーワン
ビジネスは君の趣味ではない
2016/09/19(月) 13:02:51.87ID:xTk+6xzH
ビジネスだからこそお荷物は解雇しなきゃならない
ある程度の能力のある人間が工数を減らせる手法で開発する
工数の掛かる手続き型しか書けない読めない人は解雇するべきビジネスだから
2016/09/19(月) 13:08:18.37ID:KUojTFe6
趣味をビジネスに持ち出すオタクはNGですよ、これ常識ｗ
2016/09/19(月) 14:10:27.86ID:VkQagIEW
成長しない新米プログラマをいつまでも傭い続けるわけにはいかない
ビジネスってさボランティアじゃないんだよね
2016/09/19(月) 14:18:05.63ID:KUojTFe6
で、君らはまたstatic final Koma.move(int kyori)すんの？
2016/09/19(月) 14:29:03.47ID:AFsKEmAF
回り将棋ならいいかもしれない
150デフォルトの名無しさん
垢版 |
2016/12/27(火) 23:00:43.33ID:DbM4OtJE
ViewModelってどのレイヤーに属するんだ？
Viewに関する知識はないからUIレイヤーではないだろう
ビジネスルールに関する知識は必要だからドメインレイヤー？
2016/12/27(火) 23:06:49.29ID:+TUrL10Q
UIレイヤーの中のドメインレイヤーとの境界面、じゃないの
2016/12/27(火) 23:10:35.70ID:+TUrL10Q
あ、あとViewModelに必要な知識はビジネスルールじゃなくて
ドメインレイヤーのインターフェースだけじゃないのかな？
ビジネスルールに関することはモデル内で処理するべきだと思って作ってるけど…
2016/12/27(火) 23:37:51.54ID: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にビジネスルールが染み出してしまう
2016/12/28(水) 00:02:52.91ID:KMmXCa3M
自分は個人で作ってるだけで好きなようにやれるからだけど、
そういう場合、自分はxもyもそのままモデルに投げてその処理はいったんそこで終わり。
モデルで値をチェックしてエラーならエラーイベント発生
→入力用ViewModelがそのイベントを受け取ってViewに伝えるDataErrorイベント発生
→Viewが変化

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

あくまでも、x,ｙの値によってモデルが例外を投げないように自分で作れるからだけど…
2016/12/28(水) 20:24:38.28ID:b06lzq40
限界あるな
xにうんこって入れられても一旦は保存するってことだろそれ
まさにクソまみれ
2016/12/28(水) 21:08:30.55ID:YF6A9Wev
ViewModelが勝手に「これはうんこだ！捨てておこう！」「これはうんこじゃない！大丈夫だ！」
なんてやってる方が、いずれシステムがうんこまみれになる危険が高い気がするが…

人間だって、目がうんこの反射光をとらえて、視神経がそれを脳に伝えて、
そして最後に脳が「うんこだ！汚い！」ってやるんだから
Modelが「うんこだ！汚い！」と判断するまで、
ViewやViewModelが入力情報をそのまま伝えていくことを
「うんこを一旦保存」とかとらえるのはおかしいと思うんだけどな…
2016/12/28(水) 21:55:12.03ID:b06lzq40
>>156
じゃあ超長い文字列とかも一旦は保存するんだろ?
思想に限界があるって気付けよ
2016/12/28(水) 22:03:00.40ID:b06lzq40
そもそも画面仕様が専用であるはずなのに
データ型のみModel依存ってこだわりがうんこ
画面なんか内部も含めて作り捨て上等だろ
2016/12/28(水) 22:06:08.16ID:b06lzq40
次の変更は一度にたくさん入力したいのでExcelかcsvから読み込んでもらえますか?
だったら一生懸命付けた汎用性もm9(^Д^)ﾌﾟｷﾞｬｰ
2016/12/28(水) 23:01:11.92ID:gapvLjp6
画面の検証は入力長、上下限、正規表現など簡単なものだけ採用する
自動計算項目も簡単なものだけを採用する
例えば金額と税率から税込価格を自動計算するとか商品コード入力したら商品名取ってくるとかその程度で我慢する
画面の検証や自動計算項目はあくまで入力支援が目的なのでビジネスルールに完全に遵守する必要はない
ビジネスルールを厳密に守らなければいけないのはアプリケーションサービスインターフェースより向こう側だけ
アプリケーションサービスの内部で画面か受け取った入力内容をドメインモデルにマップしてそこで本気の検証や計算を行う
2016/12/29(木) 00:14:19.42ID:5yPVbf0y
一切関知すべきじゃないな。
うんこかもしれないもの、としてVM以降に渡して、うんこではないものを貰うしか無い。
2016/12/29(木) 00:36:39.28ID:BD9K+jOv
それだと使い勝手は悪くなるな
2016/12/29(木) 02:16:04.01ID:ZpKqxRRa
>>161
小数じゃないのに小数点が入力できちゃったり
マイナス値なんて取らないのにマイナスが入力できちゃったり
全角なんて入力してほしくないのに全角で打てちゃったり
ファイルパスを入力して欲しいのにパスに入力できない文字が入る
その状態でファイルオープンダイアログ開いたら死ぬの?とか
素人丸出しアプリだな
visualstudioでプロパティいじれば解決する話をわざわざコードで記述してバグる超絶欠陥製品にしかならないだろうね
すべての値のチェックを入口で退治するんではなくて一度保持してしまうから問題を拡散している
undoしたらどこの値に戻るの?それ
2016/12/29(木) 02:36:25.34ID:RruPXahs
>>163
何を誤解してるかわからんが、それは、ビューモデル以外の場所で即座に否定されたり、是正されたり、これはは間違ってますよとエラーと判定されるから、
ビューモデルは、判定結果をおとなしく持って、ビューにレンダリングしてもらうだけじゃん。

お前がやってんのは、それはVMの仕事じゃない。
2016/12/29(木) 08:38:21.22ID:ZpKqxRRa
>>164
だからさ
その構造を実現することになんの意味があるのって話
2016/12/29(木) 10:19:02.48ID:BD9K+jOv
>>163
そういうのは大前提としてやった上での話だよ
整数入力コントロールには指定した桁数いないの数字しか入らない(アルファベットなどはキーを押しても入力されない)
その上でビューモデルにどこまでビジネスルールの知識を与えるか、ドメインモデルとの違いはなんだ、という議論をしている
2016/12/29(木) 10:37:25.80ID:vPLPY1D6
>>165
データを処理する処理に徹することができるのと
データを描画する処理に徹することができるんじゃん。
2016/12/29(木) 11:35:18.82ID:3hi3YdfK
>>167
現実にはできなくて、やるメリットもあまりなくてって状況だと思うけど
2016/12/29(木) 11:43:36.53ID:3hi3YdfK
>>166
だったら内部の仕様も画面にべったりなんでしょ?
今更分離して何がしたいの?
2016/12/29(木) 11:49:35.65ID:3hi3YdfK
はっきり言ってしまうと経験が浅いから掲げる理想が陳腐
大規模DBとそれを操作するインターフェイスを真似たモデルであれば
画面なんてプロジェクトごと作り捨て上等なんだよ
DBはもう誰も仕様変更を入れられない
画面は実現したい内容によって完全廃棄もありうる
これが現実なんだよ
2016/12/29(木) 12:03:50.76ID:orpg8/1p
>>169
VとMVの分離のメリットなら2つ大きいのがある
1. UIの状態数の最小化
2. 手続型から宣言型への移行
2016/12/29(木) 12:23:28.51ID:orpg8/1p
>>170
画面を使い捨てる前提ならますます分離した方がいい
ひと昔前はViewにビジネスロジックが当たり前のように書かれていた
こういう画面は本当に使い捨てていい画面なのか判断が難しい
画面を使い捨てる前にリファクタリングを行いビジネスロジックを抽出して分析しなければならなかった
必要なビジネスロジックは残して別の画面から利用するように変更しなければならない
この作業が全てうまくいけばようやっと画面を使い捨てる事が許される
2016/12/29(木) 13:00:59.69ID:3hi3YdfK
だからさ
現実にはできないじゃん
ちょっと突っ込まれるだけでボロボロ抜けが出てくんだから
2016/12/29(木) 13:23:47.48ID:orpg8/1p
>>173
最近はちゃんと分離されているシステムが増えてきてる
2016/12/29(木) 13:26:05.73ID:3hi3YdfK
>>174
誰の周辺の話なの?
2016/12/29(木) 13:36:40.64ID:orpg8/1p
>>175
世界的に
2016/12/29(木) 19:34:31.18ID:AIw2bcpm
>>168
割と大規模やってるけど、気合でWPFに移行してからそこそこうまく行ってるよ。
出来なくて切った会社は沢山あった。
2016/12/29(木) 22:28:45.06ID:ZpKqxRRa
>>177
そんな多大な犠牲を払ってようやくできたのか?（笑）
設計ってみんながわかりやすくするためにするもんじゃないの?
選ばれし者しかできない時点で失敗してるんだよ
わかる?
2016/12/29(木) 23:34:45.76ID:5yPVbf0y
>>178
莫大な犠牲は下請けが払ったんだと思うよ。
選ばれしものしかできないとは思わないが、
選ばれしものが出来ないのはある程度あるんじゃないの？
馬鹿とか。
2016/12/30(金) 01:32:03.00ID:JXfD++Nt
>>179
何のための画面と内部の分離だったの?
メリットが見えない
選ばれし者しか理解できないソースと組んだやつしか読めないソースの品質の違いが俺にはさっぱりわからないよ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況