オブジェクト指向システムの設計 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/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
だからさ
その構造を実現することになんの意味があるのって話

**デフォルトの名無しさん** · 2016/12/29(木) 10:19:02.48

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

**デフォルトの名無しさん** · 2016/12/29(木) 10:37:25.80

>>165
データを処理する処理に徹することができるのと
データを描画する処理に徹することができるんじゃん。

**デフォルトの名無しさん** · 2016/12/29(木) 11:35:18.82

>>167
現実にはできなくて、やるメリットもあまりなくてって状況だと思うけど

**デフォルトの名無しさん** · 2016/12/29(木) 11:43:36.53

>>166
だったら内部の仕様も画面にべったりなんでしょ?
今更分離して何がしたいの?

**デフォルトの名無しさん** · 2016/12/29(木) 11:49:35.65

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

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

>>169
VとMVの分離のメリットなら2つ大きいのがある
1. UIの状態数の最小化
2. 手続型から宣言型への移行

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

>>170
画面を使い捨てる前提ならますます分離した方がいい
ひと昔前はViewにビジネスロジックが当たり前のように書かれていた
こういう画面は本当に使い捨てていい画面なのか判断が難しい
画面を使い捨てる前にリファクタリングを行いビジネスロジックを抽出して分析しなければならなかった
必要なビジネスロジックは残して別の画面から利用するように変更しなければならない
この作業が全てうまくいけばようやっと画面を使い捨てる事が許される

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

だからさ
現実にはできないじゃん
ちょっと突っ込まれるだけでボロボロ抜けが出てくんだから

**デフォルトの名無しさん** · 2016/12/29(木) 13:23:47.48

>>173
最近はちゃんと分離されているシステムが増えてきてる

**デフォルトの名無しさん** · 2016/12/29(木) 13:26:05.73

>>174
誰の周辺の話なの?

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

>>175
世界的に

**デフォルトの名無しさん** · 2016/12/29(木) 19:34:31.18

>>168
割と大規模やってるけど、気合でWPFに移行してからそこそこうまく行ってるよ。
出来なくて切った会社は沢山あった。

**デフォルトの名無しさん** · 2016/12/29(木) 22:28:45.06

>>177
そんな多大な犠牲を払ってようやくできたのか?（笑）
設計ってみんながわかりやすくするためにするもんじゃないの?
選ばれし者しかできない時点で失敗してるんだよ
わかる?

**デフォルトの名無しさん** · 2016/12/29(木) 23:34:45.76

>>178
莫大な犠牲は下請けが払ったんだと思うよ。
選ばれしものしかできないとは思わないが、
選ばれしものが出来ないのはある程度あるんじゃないの？
馬鹿とか。

**デフォルトの名無しさん** · 2016/12/30(金) 01:32:03.00

>>179
何のための画面と内部の分離だったの?
メリットが見えない
選ばれし者しか理解できないソースと組んだやつしか読めないソースの品質の違いが俺にはさっぱりわからないよ

**デフォルトの名無しさん** · 2016/12/30(金) 08:31:43.34

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

**デフォルトの名無しさん** · 2016/12/30(金) 09:27:05.84

インスタンスメソッドは選ばれしものにしか使えないから
全てスタティックメソッドにしなさい
ってことですか？

**デフォルトの名無しさん** · 2016/12/30(金) 09:41:15.14

>visualstudioでプロパティいじれば解決する
あーダメダメ

**デフォルトの名無しさん** · 2016/12/30(金) 09:55:02.42

できるヤツができないヤツに合わせる必要はない
退化する

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

スタティックお兄さん爆誕
古き良きプログラミングの時代、復活の刻

**デフォルトの名無しさん** · 2016/12/30(金) 10:21:30.65

>>181
え?でもいまの状態で画面と内部の分離ができてないじゃん
値のチェック前に一旦値を保存するんだよね?
内部に問い合わせないとチェックする内容がわからんから
偉そうなこと言ってるけどできたもんはゴミじゃん

**デフォルトの名無しさん** · 2016/12/30(金) 11:02:39.37

>>186
保存ってどこから出てきたんだ？

**デフォルトの名無しさん** · 2016/12/30(金) 11:28:27.74

>>187
このスレよく読んでからレスしてね

**デフォルトの名無しさん** · 2016/12/30(金) 12:14:51.41

ViewModelからModelに入力値の通知を行うことを「保存」と呼ぶ頭のおかしい人が約1名いるだけ

**デフォルトの名無しさん** · 2016/12/30(金) 15:13:10.80

なるほど
どうりで話が通じんわけだ

**デフォルトの名無しさん** · 2016/12/30(金) 15:29:32.71

>>180
画面直すのかデザイナさんにもできる、
ロジック直すのが画面に一切影響しない事を謳ってプログラマだけで出来る。
これ大規模だと結構大きいよ。デザイナさんに動いてもらうのそこそこかかるし。

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

**デフォルトの名無しさん** · 2016/12/30(金) 15:44:27.69

>>191
はぁ?
なんのこと喋ってるの?
ちゃんと理解してからレスしてね

**デフォルトの名無しさん** · 2016/12/30(金) 15:52:05.62

>>192
>>177
で発端にすらなってるから、理解はしてるが。
アホなのかな。

**デフォルトの名無しさん** · 2016/12/30(金) 21:13:04.65

なぜオブジェクト指向の設計の話になると喧嘩になってしまうのか？
やはり関数型にすべきでないのか？

**デフォルトの名無しさん** · 2016/12/30(金) 22:35:50.28

>>194
モナドを許すか許さないか論、原始再帰関数の定義の喧嘩になるのがオチ。
手続きとしてCPUが処理している所に別のパラダイム持ち込むとこうなるし、
関数としてGPUが処理している所に手続きを持ち込むと同じように異論は出てくる。

**デフォルトの名無しさん** · 2016/12/30(金) 22:36:08.50

喧嘩がなくなるなら関数型喜んでつかうわ

**デフォルトの名無しさん** · 2016/12/30(金) 22:54:38.14

工数の少ない方を採用するなぁ
何が何でもオブジェクト指向！ってのは手段が目的になっちゃってるように感じる

**デフォルトの名無しさん** · 2016/12/30(金) 23:59:17.50

感情をイミュータブルにしましょう

**デフォルトの名無しさん** · 2016/12/31(土) 07:44:43.00

工数最小マンって無責任だと思うよ
保守は他人がやるからラピッドでええやんってクズばかりだから業界全体が停滞してるんだよ
多少工数が増えてもエレガントなOOPで作るべきだ
というかそもそも工数ベースで見てもOOPの方が優位だけどな

**デフォルトの名無しさん** · 2016/12/31(土) 08:26:58.81

工数最小≠OOP
って、どっから沸いてきた式だよ
コンパイル通らないぞハゲ

**デフォルトの名無しさん** · 2016/12/31(土) 10:34:26.84

>>199
ん?でもさぁ
汎用性つけまくった挙句に次の変更が来なかったら汎用化にかけた工数は無駄じゃない?

**デフォルトの名無しさん** · 2016/12/31(土) 11:05:14.41

>>201
汎用性と保守性を混同するのは初心者にはありがちだけど全く別のものだぞ
OOPはまず保守性を高めてくれるってのが主だ
結果として見ると汎用性もオマケで付いてくる場合が多いってだけだ

**デフォルトの名無しさん** · 2016/12/31(土) 11:40:12.70

>>202
そもそもOOPだと何で保守性上がるの？

**デフォルトの名無しさん** · 2016/12/31(土) 12:13:13.06

粗結合の徹底→モジュール化→単体テストしやすさ、古くなった部分の可換性

**デフォルトの名無しさん** · 2016/12/31(土) 12:24:49.69

>>203
SOLIDを実践しやすいから
モデルを忠実にコードに反映できるから

**デフォルトの名無しさん** · 2016/12/31(土) 13:03:52.81

>>204
OOPならではの部分を強調してほしかったが
疎結合とモジュール性についてまっさきに触れているので結果的に好感触

>>205
聞いて損した

**デフォルトの名無しさん** · 2016/12/31(土) 13:15:07.39

>>206
俺も答えて損した
馬の耳になんとかってヤツだね

**デフォルトの名無しさん** · 2016/12/31(土) 13:18:39.21

なんかごめんね…

**デフォルトの名無しさん** · 2016/12/31(土) 14:00:22.29

>>208
反省しろよ

**デフォルトの名無しさん** · 2016/12/31(土) 15:09:26.22

>>209
おまえもな

**デフォルトの名無しさん** · 2016/12/31(土) 16:41:13.08

>>210
消えろ
ぶっ飛ばされんうちにな

**デフォルトの名無しさん** · 2016/12/31(土) 17:32:21.84

>>211
おまえもな

**デフォルトの名無しさん** · 2016/12/31(土) 17:32:59.43

>>211
あんまり調子こいてると手続き型にするぞ？

**デフォルトの名無しさん** · 2016/12/31(土) 17:37:54.48

もういいから

**デフォルトの名無しさん** · 2016/12/31(土) 17:40:02.54

工数気にするのって完全受注型で自分とこで商品開発できないようなところだろうなと思うわ

**デフォルトの名無しさん** · 2017/01/01(日) 00:00:05.99

採算度外視で開発とかないわ

**デフォルトの名無しさん** · 2017/01/06(金) 17:03:12.17

オブジェクト指向の良書教えて

**デフォルトの名無しさん** · 2017/01/06(金) 17:25:52.39

>>217
http://echo.2ch.net/test/read.cgi/tech/1467992113/

**デフォルトの名無しさん** · 2017/01/06(金) 20:45:05.38

ループかよ

**デフォルトの名無しさん** · 2017/01/07(土) 11:22:42.01

>>204
手続き型でもできる。
というよりオブジェクトみたいに状態に注目するより
メッセージやメソッド、関数に注目するほうが自然な場合もある。
まあオブジェクト脳だとそういった処理をまとめたクラスを作るんだろうけど。