X
ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
垢版 |
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/
0587仕様書無しさん
垢版 |
2018/06/23(土) 22:00:27.65
DIは百害あって一利なし
利用者もゼロ
これが現実
0593仕様書無しさん
垢版 |
2018/06/23(土) 22:03:11.72
>>589
できるが無駄が多すぎと言ってる
そもそも出来ない君たちとは違うんだな
0596仕様書無しさん
垢版 |
2018/06/23(土) 22:04:19.06
>>591
そうやって悪口言うしか出来ないんだね
完全敗北ってやつだよソレ
0599仕様書無しさん
垢版 |
2018/06/23(土) 22:05:39.48
>>592
みた結果がこれだよ

>>594
普段からDI推奨してるこのスレの住民ですらお題を出したらまったくDIを使わないということが明るみに出てしまった
0600仕様書無しさん
垢版 |
2018/06/23(土) 22:06:37.64
>>597
ほらまた言った
負け惜しみの悪口はやめて素直に参りましたって言えば良いのの
0604仕様書無しさん
垢版 |
2018/06/23(土) 22:09:16.56
プログラマならコードで語れ
DI派はDI使ったコードを書いてようやっと議論のスタートラインに立てる
でも何を言われても書かこうとしない
負けを認めてんだよ内心ではね
でも悔しいから負けたという事実は言葉にはせず悪口に逃げるんだ
0605仕様書無しさん
垢版 |
2018/06/23(土) 22:10:17.96
>>603
君がお題に対してDIを使ったコードを書いたら1にカウントしてやるよ
0607仕様書無しさん
垢版 |
2018/06/23(土) 22:11:25.14
業務用のコードこんなところで晒して勝った気になるのはまずくないか？
0614仕様書無しさん
垢版 |
2018/06/23(土) 22:21:34.31
そもそもオブジェクト指向もDIも大規模開発の複雑さに立ち向かうための手法なのに、それを理解してない奴が
1ファイルのスクリプトを例に出して、ほらDIなんていらない、とかドヤってんだよなww
0617仕様書無しさん
垢版 |
2018/06/23(土) 22:29:44.72
>>614
雑魚の理論
小さいまとまりの集まりで大きなものを作るんだ
大きくなると造りを変えないといけないんんてのは多分何も作れてないんだそいつ
0619仕様書無しさん
垢版 |
2018/06/24(日) 02:37:42.98
>>552
このくらいの規模だとDIに限らず
関数もクラスもモジュールもクロージャも要らないけど
だからって大きなプログラムで不要な事にはならないよね？

いや、もしかしたらドカタはmain関数で全てやりくりするから不要なのかな？w
0620仕様書無しさん
垢版 |
2018/06/24(日) 02:41:43.67
>>619
もしかして、クラスに分ける＝DIを使うと思ってる？
ならアホだよ。

main関数ですべてやりくりするわけ無いじゃん。
DIは使わずにクラスに分けるだけ

はぁ。そんなこともわからんのかね
0621仕様書無しさん
垢版 |
2018/06/24(日) 02:49:59.29
>>552にDIが不要だからって、常にDIが不要な事を示せてないって言ってるだけなんだけど
>>620には理解できなかったみたいだねw
流石ドカタやってるだけあるわ
0622仕様書無しさん
垢版 |
2018/06/24(日) 02:54:53.60
？
お前はDIがいると言ってる。
俺はいらないと言ってる。

で？お前はDIがいると言うだけ？
理由は？ お前がDIがいると言ってることなんて
最初からわかってるんだよ。理由を言え
0623仕様書無しさん
垢版 |
2018/06/24(日) 03:00:39.24
俺にはDIはいるけどお前のようなドカタには不要だよ
だから意見は一致している
ドカタはドカタとして生きていけ
0626仕様書無しさん
垢版 |
2018/06/24(日) 07:50:21.99
スクリプト厨「DIが優れてるというなら>>552をDI使って書き直してみろ」

DI厨「いつでもDIするわけじゃない。この程度ならDIは不要」

スクリプト厨「じゃあこの処理が大規模システムの一部だったらと仮定しよう。他の99%の機能はDIで作られてるので、アーキテクチャの一貫性のためにこの機能もDIで実装しなきゃならないよね」

DI厨「罵詈雑言。罵詈雑言。罵詈雑言」

これじゃあどう見てもDI厨の負けだぞ
お前ら普段からDIなんて使ってないんだろ？
0629仕様書無しさん
垢版 |
2018/06/24(日) 09:24:12.28
>>552をクラスには分けないんでしょ？
なんでDIだけ入れろというの？
0630仕様書無しさん
垢版 |
2018/06/24(日) 10:32:58.22
>>629
分けたいなら分ければ？
DIに必要なことならなんでもやっていいよ
まっ無駄な工数だけどDIには必要なんだろ
0631仕様書無しさん
垢版 |
2018/06/24(日) 10:53:08.78
依存オブジェクトの固定化をやめるだけで盛り上がってるな
0632仕様書無しさん
垢版 |
2018/06/24(日) 11:01:23.65
>>630
20行のコードを
クラスに分ける必要ないし
DIにする必要もない
でもだからと言ってクラスもDIも不要にはならない
0634仕様書無しさん
垢版 |
2018/06/24(日) 11:16:56.77
>>633
ドカタ「じゃあこの処理が大規模システムの一部だったらと仮定しよう。
他の99%の機能は関数で作られてるので、アーキテクチャの一貫性のために
この機能も関数で実装しなきゃならないよね」
0636仕様書無しさん
垢版 |
2018/06/24(日) 11:32:08.03
DIするとテストが簡単になるらしい。
なら>>552のコードをテストしていただきたい
それでDIの真価が発揮されるのだろう？
0637仕様書無しさん
垢版 |
2018/06/24(日) 11:39:02.13
$app = New-Object -ComObject Excel.Application

お前はCOMのインターフェースを実装したオブジェクトをインジェクションしている
0638仕様書無しさん
垢版 |
2018/06/24(日) 11:51:50.39
>>637
じゃあそれをインジェクションしないコードに書き換えてみてよ


できないでしょ？ｗ
なんでもかんでもインジェクションといってるから
恥をかくんだよ。
0639仕様書無しさん
垢版 |
2018/06/24(日) 11:52:26.90
DI厨ってさ遊び半分なんだよね
論理的にDIが綺麗だってのはわかるよ
でも現実の仕事じゃコードを冗長でわかりにくくしてるだけ
テストもモック書くのがめんどくさいし
工数を数倍に膨らませてまでやるこっちゃない
0641仕様書無しさん
垢版 |
2018/06/24(日) 12:03:38.61
>>640
実装に依存した考え方しかできないなら
ドカタと言われてもしょうがないね
0642仕様書無しさん
垢版 |
2018/06/24(日) 12:05:39.60
DIはいらない。COMで全部作れば
インジェクションになるからだ

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

俺の考えるDIこそが世界唯一のDIなんだ！
0643仕様書無しさん
垢版 |
2018/06/24(日) 12:07:55.57
という茶番からもわかるように、

依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
でないものはDIではないのです。
DIではないのだからインジェクションと読んではいけません
0645仕様書無しさん
垢版 |
2018/06/24(日) 12:17:59.88
適切なデザインパターンを適用すればいいだけでは？

つまり依存関係をひとまとめに定義なんかする必要はないということ
それはDIではないということを意味する
0649仕様書無しさん
垢版 |
2018/06/24(日) 13:03:23.73
>>646
ほとんど切り離し不可能
COMは実装ありきのインターフェースだから複雑すぎるんだよ
0651仕様書無しさん
垢版 |
2018/06/24(日) 14:43:53.04
interface IExcelFileProvider {
IEnumerable<FileInfo> GetExcelFiles();
}

class GitExcelFileProvider {
private GitExcelFileProviderOptions Options { get; }
public GitExcelFileProvider(IOptions<GitExcelFileProviderOptions> options) {
Options = options.Value;
}
public IEnumerable<FileInfo> GetExcelFiles() {
if (Directory.Exists(Options.LocalRepo)) Directory.Delete(Options.LocalRepo, true);
Directory.Create(Options.LocalRepo);
var spi = new StartProcessInfo("git", $"clone {Options.RemoteRepo}");
spi.WorkingDirectory = Options.LocalRepo;
var proc = Process.Start(spi);
proc.WaitForExit();
var spreaddir = Path.Combine(Options.LocalRepo, "spread");
return Directory.GetFiles(spreaddir, "*.xlsx");
}

Gitの処理だけで力尽きたわ
DIってバカバカしいなぁ
Javaだとさらに長くなるんだろこれ
0652仕様書無しさん
垢版 |
2018/06/24(日) 15:51:30.46
何でもインラインで空行も入れないから見にくくてしかたないな
0655仕様書無しさん
垢版 |
2018/06/24(日) 16:19:03.87
こんな汚いコード書く奴がDIの可読性うんぬん言ってんだから滑稽だわ
0656仕様書無しさん
垢版 |
2018/06/24(日) 16:23:27.70
威勢のいいことを言うけど綺麗なDIコードは書けない
それがDI厨なんだなぁ
プログラマならコードで語りなよ
ほんと情けないよDI厨
0658仕様書無しさん
垢版 |
2018/06/24(日) 16:30:08.44
むしろ打ちのめされて元気ないように見えるDI信者さんたち
0660仕様書無しさん
垢版 |
2018/06/24(日) 16:37:23.63
そっか
負けっぱなしじゃツマラナイもんな
飽きてもしゃあない
0664仕様書無しさん
垢版 |
2018/06/24(日) 20:52:07.62
ここまでのやり取りで、ドカタはエンジニア様がDI使って作ったものを
10行程度のスクリプトで利用するだけだって分かったね
良かったよかった
0665仕様書無しさん
垢版 |
2018/06/24(日) 21:25:09.37
ドカタが10行程度のスクリプトでできる事をDI厨はできなかったという事だよ
0666仕様書無しさん
垢版 |
2018/06/24(日) 21:27:30.26
ドカタ「じゃあこの処理が大規模システムの一部だったらと仮定しよう。
他の99%の機能はクラスで作られてるので、アーキテクチャの一貫性のために
この機能もクラスで実装しなきゃならないよね」
0667仕様書無しさん
垢版 |
2018/06/24(日) 21:29:48.89
>>666
なんでもかんでもDIすりゃいいってもんじゃない
99%DIだろうとこの程度のスクリプトにはDIは使わん
サブプロセス呼び出しで十分
0668仕様書無しさん
垢版 |
2018/06/24(日) 22:51:07.15
>>552もよく見りゃDBの接続を環境変数に外出ししてるな

こういった処理が数100もあって、例えば対象のフォルダ、シート名、セル参照、テーブル名といったものが微妙に違った時に、否定派はその都度書くのだろうか？
0669仕様書無しさん
垢版 |
2018/06/24(日) 22:58:23.13
微妙に違うならパタメタライズすればいいだけだよ？
むしろそういうのはDIのほうが苦手
DIはどちらかというと特化する方向に作りこんでいくからな
リポジトリなんてほとんどテーブルと1:1だろ？
テーブルが100個あったらインターフェースとクラスとエンティティが100個ずつできる
スクリプトならパラメータ化したやつ1個で十分
0670仕様書無しさん
垢版 |
2018/06/24(日) 23:01:59.04
シート名やセル参照も同じ
DIだと神エクセルのパターンごとに読み取りクラスを作る
神エクセルの種類が100パターンあったら読み取りクラスも100種類
バカバカしいよほんと
スクリプトならシート名とセルアドレス、プロパティのマッピング定義を指定するだけでOKな関数を1つ書くだけなのにな
0671仕様書無しさん
垢版 |
2018/06/24(日) 23:08:22.10
思い込みが強くて応用の効かない阿玉の固い人間というのは良くわかった
0674仕様書無しさん
垢版 |
2018/06/25(月) 00:17:07.79
DIはクラス間の依存関係を解決するためのもので、
設定ファイルから設定値を読み込むのはDIじゃない
0675仕様書無しさん
垢版 |
2018/06/25(月) 07:33:14.28
設定値の読み込みはインフラに依存するのでDIしないとだめだよ
0676仕様書無しさん
垢版 |
2018/06/25(月) 07:59:06.06
なんでもDIでやるからほら変な癖がついてる
DIでやる必要のないものまでDIでやってる
設定の読み込みはDIとは無関係
0677仕様書無しさん
垢版 |
2018/06/25(月) 09:50:30.59
設定をコードに散らばらせずに一箇所にまとめるメリットは分かるのに
クラスの依存関係をコードに散らばらせずに一箇所にまとめるメリットは分からないの？
0678仕様書無しさん
垢版 |
2018/06/25(月) 09:58:08.32
設定だから一箇所にまとめることにメリットあるわけで、
設定じゃないものは、一箇所にまとめるメリットないぞ？
すべての処理を一箇所にまとめたらデメリットだってわかるだろ？

一箇所にまとめる ＝ メリットなんじゃなくて
設定を一箇所にまとめる = メリットなんだよ
0680仕様書無しさん
垢版 |
2018/06/25(月) 10:52:37.67
「設定」は一箇所だろではなく
「シングルトン」は一箇所だろに
話が変わっているところに注意

今話をしているのは「設定」だから
一箇所にすることにメリットが有るという話で
設定じゃないもの（クラスやシングルトン）は
一箇所にしたところでメリットはない
0681仕様書無しさん
垢版 |
2018/06/25(月) 10:57:10.70
データベースも最終的に呼び出す場所は１箇所だけどな。
0683仕様書無しさん
垢版 |
2018/06/25(月) 11:02:48.36
なるほど、設定だから、一箇所にまとめるわけですね。
設定じゃないものは、まとめないしDIを使う必要もないと
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況