オブジェクト指向システムの設計 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/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
手続き型でもできる。
というよりオブジェクトみたいに状態に注目するより
メッセージやメソッド、関数に注目するほうが自然な場合もある。
まあオブジェクト脳だとそういった処理をまとめたクラスを作るんだろうけど。

**デフォルトの名無しさん** · 2017/01/07(土) 12:04:44.28

>>220
具体例は？

**デフォルトの名無しさん** · 2017/01/07(土) 13:39:47.70

　サ　ー　ビ　ス　ク　ラ　ス

**デフォルトの名無しさん** · 2017/01/07(土) 21:45:21.54

>>220
> 手続き型でもできる

それはとても興味深い指摘です。後学のため、
これぞ手続き型の（つまり「そこまでやったらもはやOOP」とは言わせない、そういった小細工のない）
コードで実演してみてもらうことはできますか？

**デフォルトの名無しさん** · 2017/01/07(土) 23:48:37.74

そもそもオブジェクト指向にメリットなんかないのにやり方がわからないとかさっさと廃業しろ

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

デストラクタは OOP でないと難しいね
え？ポインタの存在自体が邪道ですか？そうかもしれないですかね‥

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

デストラクタってOOP以前からあるしOOPと直結する関係性もない
それになぜいきなりポインタ？もはや何が言いたいのか判らない

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

そう難しく考える必要はなく物事をシンプルに考えていくと自然とOOPにたどり着くんだけどね
OOPに拒否感を持つ人はその当たり前の感覚を持っていないアスペなんじゃないかな
子供の頃いじめられたりしなかったか？

機械的な命令並べてgotoするより意味的な命令並べてifとかloopとか使ったほうが簡単だな
同じ処理をなんども書くより関数にしたほうが簡単だな
引数が多くて煩わしいから一緒に使う変数をまとめて構造体にしたほうが簡単だな
この構造体は特定の関数以外から変更されたらそれらの実行の前提条件が崩れるからそれら以外からメンバに触れないようにアクセス制御したほうが間違えなくていいな
それらの関数を構造体と同じ箇所で定義すれば管理しやすいな
メンバ変数みたいにドット演算子でそれらの関数にアクセスできれば楽だな
………

こういう感覚は別にOOPを知らなくてもコーディングを簡単に安全にしたいという欲求があれば自然とたどり着くものなんだけど
感覚がおかしいのかガチで気が付かなかったのか
たどり着けないかわいそうな子も世の中には少なからずいるんだね

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

なんていうかね
棍棒だと重いし動物殺しにくいけど木の棒の先っぽに鋭い石括りつけたら軽くてめっちゃ殺せるんだけどウホホwww
正直この程度の発想でしかないんだよ
OOPってそんなに高尚で難しいものじゃない
それをわざわざ難しい概念だと錯覚して悩むのは時間の無駄じゃないか？
OOPとはなにかOOPの存在意義はなんて哲学者みたいなことを考えてないでさ
自分の感覚に従ってOOPってよくわからんけど手続き型より楽だわウホホwwwって気楽にコーディングすればいいんだよ

**デフォルトの名無しさん** · 2017/01/08(日) 09:38:52.74

なんで人格攻撃に移るの?
自分の中で辻褄が合ってないから反論できないのに他人を叩くことでそれを解消しようとするのは間違ってる
お前は技術者を廃業しろ

**デフォルトの名無しさん** · 2017/01/08(日) 09:50:56.48

ワイ「関数型最強ウホホｗｗｗ」

**デフォルトの名無しさん** · 2017/01/08(日) 10:35:35.87

> 物事をシンプルに考えていくと自然とOOPにたどり着く

逆だろうね
物事を自分のおつむの程度にしかとらえられない人間がようやくたどり着いたのが>>227が書てるOOPもどき
この程度の理解の人間がOOPを真に理解してそのメリットを引き出せているとはとうてい思えない

**デフォルトの名無しさん** · 2017/01/08(日) 10:35:39.50

>>229
残念ながらこれもOOPがらみでよく見られる光景
追い詰められてならまだしもわりと最初のほうからこれだもんね
さらにそれにしたってそれすらを長文でぐだぐだと…推して知るべし

**デフォルトの名無しさん** · 2017/01/08(日) 11:28:11.39

2chの長文すら読めないオジサンって、普段技術書読まないんですかあ？

**デフォルトの名無しさん** · 2017/01/08(日) 11:45:15.83

技術書ってクソばかりじゃないですか

**デフォルトの名無しさん** · 2017/01/08(日) 12:53:03.81

>>226
デストラクタはOOPと同時ですよ

**デフォルトの名無しさん** · 2017/01/08(日) 13:04:04.65

protectedっていつ使うんですかぁ？中途半端じゃないですかぁ？

**デフォルトの名無しさん** · 2017/01/08(日) 13:07:40.60

継承やUTで簡単に使えるようにするため
privateは全てprotectedにしろと言われたことあったわ

**デフォルトの名無しさん** · 2017/01/08(日) 13:23:09.13

継承っていう仕組みがクソ。疎結合とはなんだったのかって気分にしてくれる。

**デフォルトの名無しさん** · 2017/01/08(日) 13:34:11.82

OOPのメリットとして吹聴される要素の8割はクソ。
カプセル化はクソ（めんどくさい）
継承はクソ（親子のねっとりしたつながりがキモイ）
多態は野ぐそ（多態のための汎化、インタフェース抽出とか勘違いも甚だしい。保守性に逆行している）
俺OOP使ってこんな曲芸できます案件多すぎクソ。

**デフォルトの名無しさん** · 2017/01/08(日) 13:38:11.45

葡萄に手が届かない狐さんのたわごと

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

>>239
車輪的再発明すきそう

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

OOPみたいな簡単な仕組みも理解できない人って可哀想
もっと体動かすだけとか根性あればなんとかなる仕事に転職しないの？

**デフォルトの名無しさん** · 2017/01/08(日) 14:17:09.32

OOPは本当に簡単で短絡的な思考のすえたどり着く結論だからね
オブジェクトに操作が内包されているというのは
まるで利権主義で、縦割り行政で、日本的といえる
自分の仕事しかしないし、利権はぜった他人に渡さない
利権という物質的なオブジェクトにすべてが紐づいていて整理されている

まぁ実用面では便利な部分もあるんだが
外でOOPサイコーとかいうと人格を疑われかねない
本音と建て前でこっそり使うものだ

**デフォルトの名無しさん** · 2017/01/08(日) 15:26:35.22

OOPを無くした人類はどこへ向かうのか

**236** · 2017/01/08(日) 15:47:12.81

オブジェクト指向を用いるメリット
｢ラクして、楽しく、良いもの｣を作れる

スッキリJavaより抜粋

**デフォルトの名無しさん** · 2017/01/08(日) 16:12:47.12

｢ラクして、楽しく、良いもの｣を作れる
オブジェクト指向登場後のソフトウェア業界は
さぞかし良い世界になったんだろなあ

**デフォルトの名無しさん** · 2017/01/08(日) 16:19:04.51

とてつもなく良い世界にはなってる。

**デフォルトの名無しさん** · 2017/01/08(日) 16:46:50.39

簡単になりすぎて捌ける規模が大きくなったから
逆に要求が膨れ上がって結局辛い世になってる気もするが
まあCOBOLとかやらされるよかマシかな

**デフォルトの名無しさん** · 2017/01/08(日) 16:51:03.49

オブジェクト志向言語使っててもアホが考えた社内規約とやらとヘボいフレームワークで全く楽にならねえw

**デフォルトの名無しさん** · 2017/01/08(日) 17:26:00.28

>>249
あーわかる
なぜか規約もフレームワークも手続型っぽいんだよな

**デフォルトの名無しさん** · 2017/01/08(日) 19:34:42.91

オブジェクト指向の利点って明確にならないね

**デフォルトの名無しさん** · 2017/01/08(日) 21:51:12.89

そういやこのスレって、どんな話題で始まったんだっけ？
「オブジェクト指向の利点を明確にする」
だったっけ？

**デフォルトの名無しさん** · 2017/01/08(日) 22:30:47.12

>>252
まずメリットが明確にならないとやる意味もわからなくてさ

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

>>251
俺も最近正直そう思うようになった

最初の頃：おぶじぇくとしこう？
途中：OOP！ポリモ！デザパタ本！OOSC本！
その後：関数型？関数と変数だったら変数散らかるんじゃないんけ！
そののち：意外と関数型記述性ある！不思議と短く書けるなんやこれ！
しばらくして：いや？非OOPでも意外と書けた！
　OOP-OOPLというより大事なんは単にモジュール性や！直交性や！
　徹底してインタフェースと実装のシンプルさを保つことや！
今：そんでOOPのメリットって何なんやろな？

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

そういう本質的に重要な事を記述しやすいってところだろ？