ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
■ このスレッドは過去ログ倉庫に格納されています
■ オブジェクト指向・デザインパターン（有用）
わかり易い例
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/ >>482
そこに関しちゃそうだな
どっちかというと、ユーザーの要望と要件は1/3ぐらい真の要件や最適解とは程遠いので、そこを整理せずに設計するとカオスになるんだと思うよ >>476
＞オブジェクト指向とDIは画面とエンティティとテーブルに綺麗な対応関係があるって前提からスタートしてるから
どのオブジェクト指向がそんなことを前提にしてるって？
OOA/OODのことか？OOPとは別の話だろ。
DIは完全にOOP側の要素だし。
OOA/OODやDIを否定して勢い余ってOOPまで否定するのは感心せんな。 >>483
お前に技術力がないだけでは？
もともと画面（View）はモデルとは分離して作る
コントローラー側で複数のモデルにたいしてデータを作成するだけ
お前が、画面をもとにモデルを設計してるからそうなるんだよ。
というか設計してない。単に画面をそのままコードに変換してるだけ >>485
そんな厳密に分ける必要のある話ちゃうやんｗ >>486
うーん、でもそれ机上の空論だよね？
って話してるわけ >>480
「机上の空論」っていうことに
根拠は無いよねって言ってる >>488
そら設計できないお前にとってはありとあらゆる設計手法が机上の空論やろw >>486
じゃ、データがリアルタイムで更新されるとして
そこに表示されるコンボボックスの要素もリアルタイムで更新されるとしたとき
どんな設計するん？
モデルとビューは関係ないとかキチガイ発言繰り返すのん？ >>492
なにその初歩的なお題
そんなところで躓いてる奴が「机上の空論」ってドヤってんのか
そうやって煽ってアドバイスをもらおうとするのやめた方がいいよ初心者さん >>493
でも解決方法はこんな簡単な問題でもビューとモデルを包括した仕様の変更しか無いよね？
この程度で限界が来ちゃう理論を大事に守ってるのってなんか意味あるの？ >>492
MVVMという言葉で調べておいで。
本当に能力不足だったようだｗ >>494
この程度で、自分の限界が来ちゃってるのねｗ
お前、この業界にいる意味あるの？ 画面を区分けしてそれぞれにViewとModelを割り当てる
画面全体は各Viewを取りまとめたり、相互作用を仲介したりする >>496
え？このままじゃどうにもならないでしょ？
頭悪いの？
コンボボックスで選択してる間に選択項目消えちゃうって言ってるんだよ >>498
選択項目消えても問題ないように作れば？ >>498
選んでる最中に消えるからどうにもならないって？
どうするか決めろのが設計だろアホw この分じゃ楽観的ロックも知らんのやろうな
こいつが問題にしているのは
コンボボックスの中身を更新するために全部消してリセットしたら
選択位置がリセットされちゃうんです。
え？全部消すんじゃなくて変わった部分のみを変更すればいいって？
そんなのどうやるんですか？そんなコード会社で見たことないです！
程度の話だろｗ >>500
モデルとビューなんて切ってたってこの程度だぜ 全部消えちゃった時どうすればいいかわかんないんです。 仕様がないんです。会社のコード見てもよくわかんないんです。
どうしたら良いんでしょうか？誰か教えてください。 >>506
ビューとモデルは分離していいことあった？ >>508
当たり前。分離されてるからテストもしやすい ビューとモデルが分離されてると
使いやすいUIに変更するときも便利
良いことならたくさんあるよ 逆にビューとモデルを分離せずにいいことあったかどうかを聞きたいね
別にシンプルになるわけでもないし やたらめったら抽象化された7個のインターフェース、13個のクラス
オープンソースライブラリ使いまくりのゴミコンソールアプリを作ってるバカな同僚がいたから
同じことをする10行ぐらいのスクリプトを書いてやったら急に怒り出した
DI厨ヤバすぎ >>517
めちゃあるよ
DIするとバカみたいにクラスやインターフェースが増えて大したことしてないのにメンテナンスコストが増える >>518
問題をDIそのものにすり替えたくなるほど憎いんだね DIを使うとコードが1割、2割は確実に増える
経験的に最悪で2倍ぐらいかな DIのデメリットはコードが増えると言うよりも
価値がないコードができるということ シェルのパイプラインでサクサクつなげて30秒で入力おわり即実行みたいな処理も
JavaやC#でDIを使うとサブプロセスをインターフェースで隠蔽してインジェクト、
データベースもインジェクト、Webアクセスもインジェクト、設定ファイル読むのもインジェクト
って具合にアホみたいに大量のクラスとインターフェースが作られる
ビルドも遅いしコンテナサービスセットアップしてクラス全部登録すんのも超めんどくさい >>523
だから俺は価値がないDIを使わないって。
DIは特になにか必要になってるわけじゃないのに
こんなふうに（冗長に）書け。そうすれば
そのうち役に立つかもしれないって押し付けるパターンだからね >>524
それで済む程度の処理にDIなんか使うわけないじゃん
「同僚」とやらが実在するなら注意してあげな ではどういうときに必要になるかと言うと、
その具体例はでてこないという
だって、必要だからDIを使うのではなく
とりあえずDIを使っとけになってるから しょぼい案件で工数がそれほど見込めない時に水増しする為に無駄な実装でかさ上げするのに有効。 DIは最高すぎるけどなぁ
本当に同じものについて語ってるのだろうか 300行で書けるスクリプトがJavaとDIのせいで2000行ぐらいに膨れ上がった
ほんと害悪なんだが ドカタがドカタ言語で書くとDIは冗長になるのは分かるよ？
でもそれはドカタが悪いのであってDIの所為じゃない
こっちはDI使ってシンプルで読みやすく保守しやすいコードが書けるんだから寄ってくんな というかjavaやc#がうんこだからDIで安全マージンとりながらやらなければならない
スクリプトだったらそんなん要らん >>542
> ドカタがドカタ言語で書くとDIは冗長になるのは分かるよ？
俺はわかんないよ
なんで、ドカタがドカタ言語で書くとDIは冗長になるのか
説明してくれよ DIで冗長になる前提で話してるのが意味不明
冗長になるって言うならコード書いてみてよ じゃあお題
$app = New-Object -ComObject Excel.Application
$app.DisplayAlerts = $false
$app.Visible = $false
Remove-Item ./* -Recurse
git clone $env.REPO_URL
Get-ChildItem ./spread/*.xlsx | foreach {
$book = $app.Workbooks.Open($_.FullName)
$sheet = $app.Worksheets("datasheet")
[pscustomobject]@{
Foo = $sheet.Range("A1").Text
Bar = $sheet.Range("D5").Text
Baz = $sheet.Range("G2").Text
}
$.Close($false)
} | where { $_.Foo -ne "xxx" } | foreach {
$cmd = "insert into XlsxImp (foo,bar,baz) values ('$($_.Foo)', '$($_.Bar)', '$($_.Baz)');"
$cmd | sqlplus -s -l $env.DB_CONN_STR as sysdba
}
$app.Quit()
JavaとDIを使うとどうなる？ ドカタはexcel使う必要あるんだね
成る程ドカタだわ ほらみたことか
DIじゃろくな事にならないからって無様な捨ぜりふ吐いて逃げるんだもんなぁ
普段偉そうなこと言ってるわりにこれだもん
DI厨の限界見えたわ 処理の概要とideone.comなどコードが見易い所にあげるぐらいの気遣いは欲しいな
色んな依存はある気がするが処理がこれしかないならこのままでいいんじゃね？ DI厨「DIの不利を悟ったから関係ないこと言ってお茶を濁そう」 全体で20行ぐらいのコードしかないのに
DIする奴いるの？ アンチDIって、DIやってる人がいつでもどこでもDIやってると思ってるんだろうか >>552
javaの方がシンプルに書けたらpsの存在意義ってなんだよアホ Mochなどと同じで汎用性が欲しい時、テストとかしやすくしたいときに使おうってだけの話だよね >>561
またテストか。DIはテストだけのものじゃないって言ってるだろ クッソ笑える
DI厨全滅かよwww
なーにが「い、いつもDIするわけじゃねーし」(ふるえ声)
だよwwwww >>560
おう書いてみろや、ご自慢のDI使ってな じゃあJavaとDIでシステム組んで最後の1つの機能が>>552で、これ移植したら円満にプロジェクト終了って時はどうすんの？
そうなってもいつもDIするわけじゃねーし、だの、1つくらいDIじゃなくても問題ないなんつって逃げそうだよなお前らw >>564
適材適所がわからないんだな
スクリプトでやるようなことをDI使ってやれって、頭沸いてんのか？ >>566
やっぱり言い訳するんだ
99%Javaで美しいDIで一生懸命組み上げたシステムの最後のピースがやっつけのスクリプトってさぁ
やれやれだよホント まったくだ
JavaもDIも役立たずのゴミ
スクリプトを書いたほうが短く簡潔で保守性も高まる >>571
少なくともここにいるDI厨はスクリプトでやるらしいぞ
大規模システムの一部という前提を与えてやってもDIでやる場面じゃないだのなんだのと言い訳してDIを拒む
じゃあもうどこでDIすんだって話だよ おうおう
出るわ出るわ負け惜しみ
ここでサクッとJavaのDI使ったコードを書いて黙らせるぐらいのことできんのかねぇ >>578
何言ってんだ？
スクリプトならサクッと書けるって例だが？ Javaで作るような大規模システムをサクッと書いてよ エクセルの内容をノールックでDBに入れるだけの簡単なお仕事 書き直す気力も起きない程の圧倒的ドカタコードを提示する事で
相手のヤル気を削ぐ作戦に出るとは恐れ入った ■ このスレッドは過去ログ倉庫に格納されています
