オブジェクト指向とDIを分かりやすく例えて教えてくれ 3

1仕様書無しさん2018/05/19(土) 21:44:19.89
■ オブジェクト指向・デザインパターン(有用)
 
 わかり易い例
 class Dog extends Animal
 class Cat extends Animal

■ DI(ゴミ)

 DIとは?・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
        オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン

 https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html

 > Dependency Injection の形式
 > Dependency Injection の基本的な考え方は、独立したオブジェクトを
 > Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
 > MovieLister クラスのフィールドへ適切に設定させるというものだ。
 > 依存関係は図2のようになる。


前スレ

オブジェクト指向とは 分かりやすく教えてくれ
https://medaka.5ch.net/test/read.cgi/prog/1521869966/

オブジェクト指向を分かりやすく例えて教えてくれ 2
https://medaka.5ch.net/test/read.cgi/prog/1525660302/

477仕様書無しさん2018/06/17(日) 16:20:20.28
それ、階層足りないだけで、きちんと集約されてないから複雑に見えるだけなんだけどな。
要するに分析が出来て無いだけ。設計が手抜きって事。

478仕様書無しさん2018/06/17(日) 17:19:54.26
>>477
〜設定してるときに〜見たいじゃんって要求が必ずしも綺麗に行くとは思えない
え?でもその可能性を考慮しちゃうと
すべてのデータがすべてのデータにアクセスできる必要があっちゃわない?
ってとこまで行く経験は俺はよくあるけどね

〜を触ってるときに〜を知る必要はない
って思い込みで設計をしたところから地獄が始まる
せめてその意図を同時に記述しておき
それが崩れたときはすべての隠蔽コードを破棄するべき

479仕様書無しさん2018/06/17(日) 17:41:17.94
>>478
バカ

480仕様書無しさん2018/06/17(日) 18:01:09.78
業務系のユーザーは欲張りだからね
要望を聞くと「1画面にあらゆるものをしこたま詰め込んでカオス化させること」が要件になってしまう
シンプルな画面を沢山つくるんじゃ「画面遷移が多くて生産性が上がらない」ってクレームがついて前述の要件を満たせなくなる

481仕様書無しさん2018/06/17(日) 18:39:59.54
まあ、別アプリ組み合わせてオペレーターに作業させればいいだけだったりするよな。

482仕様書無しさん2018/06/17(日) 23:52:27.35
>>480
そりゃそうでしょ
毎日同じ画面と向き合って入力するのに、何回も何回も画面遷移したい?

483仕様書無しさん2018/06/18(月) 00:47:34.09
>>482
俺がどう思うかは興味ない
客が巨大な神画面を要求するという事実が重要
神画面が要件に入るとオブジェクト指向もDIもまともに機能しなくなる
高尚な理論を説いても現実の世界では使い物にならない

484仕様書無しさん2018/06/18(月) 02:20:07.14
>>482
そこに関しちゃそうだな
どっちかというと、ユーザーの要望と要件は1/3ぐらい真の要件や最適解とは程遠いので、そこを整理せずに設計するとカオスになるんだと思うよ

485仕様書無しさん2018/06/18(月) 07:14:41.26
>>476
>オブジェクト指向とDIは画面とエンティティとテーブルに綺麗な対応関係があるって前提からスタートしてるから

どのオブジェクト指向がそんなことを前提にしてるって?
OOA/OODのことか?OOPとは別の話だろ。
DIは完全にOOP側の要素だし。

OOA/OODやDIを否定して勢い余ってOOPまで否定するのは感心せんな。

486仕様書無しさん2018/06/18(月) 07:17:19.27
>>483
お前に技術力がないだけでは?

もともと画面(View)はモデルとは分離して作る
コントローラー側で複数のモデルにたいしてデータを作成するだけ

お前が、画面をもとにモデルを設計してるからそうなるんだよ。
というか設計してない。単に画面をそのままコードに変換してるだけ

487仕様書無しさん2018/06/18(月) 07:18:32.71
>>485
そんな厳密に分ける必要のある話ちゃうやんw

488仕様書無しさん2018/06/18(月) 07:19:38.61
>>486
うーん、でもそれ机上の空論だよね?
って話してるわけ

489仕様書無しさん2018/06/18(月) 08:19:35.10
>>480
「机上の空論」っていうことに
根拠は無いよねって言ってる

490仕様書無しさん2018/06/18(月) 08:19:50.30
>>488へのレスの間違い

491仕様書無しさん2018/06/18(月) 08:34:56.58
>>488
そら設計できないお前にとってはありとあらゆる設計手法が机上の空論やろw

492仕様書無しさん2018/06/18(月) 12:44:38.66
>>486
じゃ、データがリアルタイムで更新されるとして
そこに表示されるコンボボックスの要素もリアルタイムで更新されるとしたとき
どんな設計するん?
モデルとビューは関係ないとかキチガイ発言繰り返すのん?

493仕様書無しさん2018/06/18(月) 14:26:26.57
>>492
なにその初歩的なお題
そんなところで躓いてる奴が「机上の空論」ってドヤってんのか

そうやって煽ってアドバイスをもらおうとするのやめた方がいいよ初心者さん

494仕様書無しさん2018/06/18(月) 18:51:47.24
>>493
でも解決方法はこんな簡単な問題でもビューとモデルを包括した仕様の変更しか無いよね?
この程度で限界が来ちゃう理論を大事に守ってるのってなんか意味あるの?

495仕様書無しさん2018/06/18(月) 19:19:16.24
>>492
MVVMという言葉で調べておいで。
本当に能力不足だったようだw

496仕様書無しさん2018/06/18(月) 19:20:08.86
>>494
この程度で、自分の限界が来ちゃってるのねw
お前、この業界にいる意味あるの?

497仕様書無しさん2018/06/18(月) 20:18:43.80
画面を区分けしてそれぞれにViewとModelを割り当てる
画面全体は各Viewを取りまとめたり、相互作用を仲介したりする

498仕様書無しさん2018/06/18(月) 20:40:04.70
>>496
え?このままじゃどうにもならないでしょ?
頭悪いの?
コンボボックスで選択してる間に選択項目消えちゃうって言ってるんだよ

499仕様書無しさん2018/06/18(月) 23:09:20.84
>>498
選択項目消えても問題ないように作れば?

500仕様書無しさん2018/06/18(月) 23:28:53.37
>>498
選んでる最中に消えるからどうにもならないって?
どうするか決めろのが設計だろアホw

501仕様書無しさん2018/06/18(月) 23:40:21.48
この分じゃ楽観的ロックも知らんのやろうな

こいつが問題にしているのは

コンボボックスの中身を更新するために全部消してリセットしたら
選択位置がリセットされちゃうんです。
え?全部消すんじゃなくて変わった部分のみを変更すればいいって?
そんなのどうやるんですか?そんなコード会社で見たことないです!

程度の話だろw

502仕様書無しさん2018/06/19(火) 07:10:57.09
>>501
全部消えちゃう可能性もあるよね?

503仕様書無しさん2018/06/19(火) 07:12:08.27
>>500
モデルとビューなんて切ってたってこの程度だぜ

504仕様書無しさん2018/06/19(火) 07:12:40.61
>>502
それがどうかしたの?

505仕様書無しさん2018/06/19(火) 07:18:28.77
全部消えちゃった時どうすればいいかわかんないんです。

506仕様書無しさん2018/06/19(火) 07:24:41.31
それは仕様を決めればいいだけだよね?

507仕様書無しさん2018/06/19(火) 07:26:00.21
仕様がないんです。会社のコード見てもよくわかんないんです。
どうしたら良いんでしょうか?誰か教えてください。

508仕様書無しさん2018/06/19(火) 08:15:05.37
>>506
ビューとモデルは分離していいことあった?

509仕様書無しさん2018/06/19(火) 14:55:08.95
>>508
当たり前。分離されてるからテストもしやすい

510仕様書無しさん2018/06/19(火) 14:55:24.44
あとCLIから実行するのも簡単

511仕様書無しさん2018/06/19(火) 15:55:59.74
でもUI的に使い辛いんだよな。

512仕様書無しさん2018/06/19(火) 17:15:37.12
ビューとモデルが分離されてると
使いやすいUIに変更するときも便利
良いことならたくさんあるよ

513仕様書無しさん2018/06/19(火) 17:20:53.75
嘘ばっかし。

514仕様書無しさん2018/06/19(火) 17:27:03.62
嘘だ!嘘に違いない!ばーかばーか!

515仕様書無しさん2018/06/19(火) 17:43:58.81
逆にビューとモデルを分離せずにいいことあったかどうかを聞きたいね
別にシンプルになるわけでもないし

516仕様書無しさん2018/06/19(火) 17:52:42.07
やたらめったら抽象化された7個のインターフェース、13個のクラス
オープンソースライブラリ使いまくりのゴミコンソールアプリを作ってるバカな同僚がいたから
同じことをする10行ぐらいのスクリプトを書いてやったら急に怒り出した
DI厨ヤバすぎ

517仕様書無しさん2018/06/19(火) 19:21:45.90
>>516
それDI関係ねーよwww

518仕様書無しさん2018/06/19(火) 19:24:17.79
>>517
めちゃあるよ
DIするとバカみたいにクラスやインターフェースが増えて大したことしてないのにメンテナンスコストが増える

519仕様書無しさん2018/06/19(火) 19:47:24.49
>>518
問題をDIそのものにすり替えたくなるほど憎いんだね

520仕様書無しさん2018/06/19(火) 19:50:15.21
DIを使うとコードが1割、2割は確実に増える
経験的に最悪で2倍ぐらいかな

521仕様書無しさん2018/06/19(火) 19:53:29.08
DIのデメリットはコードが増えると言うよりも
価値がないコードができるということ

522仕様書無しさん2018/06/19(火) 19:56:12.12
>>520
ああテストコードのない昔々の話ですね

523仕様書無しさん2018/06/19(火) 19:56:32.85
>>521
価値がないコードを書く開発者は死ね

524仕様書無しさん2018/06/19(火) 20:02:42.71
シェルのパイプラインでサクサクつなげて30秒で入力おわり即実行みたいな処理も
JavaやC#でDIを使うとサブプロセスをインターフェースで隠蔽してインジェクト、
データベースもインジェクト、Webアクセスもインジェクト、設定ファイル読むのもインジェクト
って具合にアホみたいに大量のクラスとインターフェースが作られる
ビルドも遅いしコンテナサービスセットアップしてクラス全部登録すんのも超めんどくさい

525仕様書無しさん2018/06/19(火) 20:03:46.05
>>523
だから俺は価値がないDIを使わないって。
DIは特になにか必要になってるわけじゃないのに
こんなふうに(冗長に)書け。そうすれば
そのうち役に立つかもしれないって押し付けるパターンだからね

526仕様書無しさん2018/06/19(火) 20:56:39.77
そしてそれは役に立った試しのない不良債権

527仕様書無しさん2018/06/19(火) 22:02:31.07
>>525
はいキチガイ

新着レスの表示
レスを投稿する