ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3

言えるよ

>>189
それで代わりにお前はなにを出すんだ？

なんだ、宗教か。

>>156
おー、やるねー。

>>290
自明であることの数学的根拠は？ｗ

次が要るのか？

>>61
必ずしもそうとは限らない

>>200
俺を知らないのか？
モグリだぞ

>>262
> poor man’s DI は pasta のほうと同じパターンな

証明してないので認められない

アンチの主張は間違ってるのだからわかりやすく説明することはできないよ
1 + 1 = 3であることをわかりやすく説明するようなものでそれは不可能だ
間違ってることを説明しようとするから筋が通らず支離滅裂でわかりにくくなる

だからそれも自称IoC支持者と自称多くの議論でしかないんだよ
そういうつぶやきじゃなくて最低限、議事録をだせよ

>>147
そもそも”問題”だと思っているものが問題じゃないんですよ

頭のいい馬鹿は問題があればそれを解决しなきゃ
どんなコストを支払ってでも！って考えますが、

問題はあるが少しコストを支払って、許容範囲に
おさめれば、それは問題ではなくなるんですよ

なにをいってるのかわからないでしょうね。
要するに依存しててもいいじゃない
少し面倒になるだけでしょう。という話です。

>>249
あの馬鹿も必死なんですよｗ
自分の説を認めてもらおうと
頑張って調べて・・・んで返り討ちにあってるわけですねｗ

DIコンテナ必須派ってさいつもこうだよな
MFとかいう面識もない殆ど空想上のおっさんが言ってた、っていうくだらない根拠しか提示できない
おっさんの権威を認めなければこんなにも簡単に崩れ去るロジックしか示せない
まったくもって片腹痛いわ

>>251
Q. poor man’s DIはDIですか？
A. いいえ、DIではありません。

>>66
こいつｗｗｗ

>>133
逆ではないのですか？DI手段でやるのしんどいからそれを解決するのがDIコンテナかと思ってました。

まあこう書いてあるしな。
独立させたオブジェクトにしないといけない

　> Dependency Injection の形式
　> Dependency Injection の基本的な考え方は、独立したオブジェクトを
　> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を

>>293
自明の要件を満たしてないことは自明

制御の反転およりDIが”問題”の唯一の解決手段だと考えるのがだめなんだよ。

制御を反転というのは、反転、つまり正しい流れから逆なわけだよね
逆にしないで正常の流れのまま、問題を解決するほうが良いだろう？

>>77
何回も書いてあるだろ

再掲すると

　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のようになる。

ファクトリはプログラマが適切なタイミングで必要なオブジェクトを
ファクトリ経由で生成してもらう。依存関係はその場に記述する

DIは依存関係をひとまとめに定義する部分が独立して存在する
DIコンテナはファクトリに似ているが、関連するオブジェクトのみを扱うファクトリとは違って
DIコンテナは、全てのオブジェクトと取り扱うプロジェクトで唯一のグローバルなファクトリ

歪な知識しか持たないIT社長が、素人に歪で浅い知識植え付けて、そこらのJava案件に送り込むんだよね。
DIとかまさにそんな感じ。

良く知らずに使わされている技術について考える良い機会になったと思うよ。

>>344
AOPも「やりたいこと」ではないからね。
本当のやりたいことっていうのはロギングだったり
トランザクション制御だったりするわけ

DIもAOPもそれがあるだけじゃ
ロギングもトランザクションも実現できない

かといってそれをDIやAOPの利用者が実装するとなると大変
そこでDIやAOPをベースとしたフレームワークが登場する
それがSpring FrameworkやASP.NET Core
フレームワークの開発者にとってはDIやAOPは便利な道具

だけど別にDIやAOPを使わなければフレームワークが作れないわけじゃないし
ロギングやトランザクション制御ができないわけでもない
だってフレームワークはDIやAOP登場以前からあったわけだし

だけどDIがあるおかげで間接的にメリットがある・・・と思うだろ？
そうじゃない。フレームワーク開発者がロギングやトランザクション制御に
DIを使うということは、それらをカスタマイズしようと思ったら
利用者に対して、DIのやり方でやってくださいと強制してしまう
（頑張れば完全に隠蔽も可能だろうけど、そういうフレームワークは聞いたことないな）

それに対してDIを使わないフレームワークでは簡単な設定で
ロギングやトランザクション制御を変更することができる。
なぜなら複雑な仕組みになるがゆえに、フレームワーク利用者に簡単に
使ってもらうために、フレームワーク開発者が内部にうまく隠蔽しようと頑張るから

その結果、DIを使うフレームワークは、フレームワーク開発者にとては開発が楽になるのだろうが、
フレームワークの利用者にとっては面倒なDIの設定が増え、ソースコードの複雑さが増し
理解が困難になってしまう。

>>174
自明じゃないので証明してみな

>>74
DI使ったことない人がこちら

数学的根拠を示すためにデータを集めてね
最低でも100件

>>240
俺が言ってるから正しい
５ちゃんねるに書いてあるのが証拠だ

それはデフォルトのオプションというだけであって必須というわけではない

void Func(string p = “unko”) {}

pは必須パラメータか？違う

DIコンテナも多くの人にとってはデフォルトではあるが必須ではない

DI使っても使う所で
newもしくは、DIコンテナから取得
するっていうのはわかるね？

newはあちこちに散らばある。
DI使えばnewが一箇所にまとまると言うが、
newの代わりにDIコンテナからの取得が
散らばるだけだっていうのは気づいてるよね？

おそらく気づいてないんだと思う。
だってDI使ってないだろ？ｗ

>>136
その図はわかりやすいね。これからそれも利用していこう

https://msdn.microsoft.com/ja-jp/library/ff921152.aspx

> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。

だってQiitaとか出したらバカにされたし
Wikipedia出したら、あんなの信じるの？とか言われたし

>>190
>>173という完全なロジックを出すよ

どのクラスをnewして使うべきか、というのもオブジェクトの大事な責務なのに、
それを外出しして一つにまとめて神クラス作るのがDI
DI褒めてるやつはオブジェクト指向を分かってない

>>201
じゃあお前とマーチンファウラーを比べてやるから
名前言えよ。その勇気があるのならな

いまどきはウェブアプリだらけだけどな。
ちょっとしたソシャゲなんかモロにな。

>>119
何言ってるかわかんねぇ。
AがBを利用してんなら、AとBが強い依存関係にしろ弱い依存関係にしろ、Bは単独でテストできるだろ。単独でテスト出来ない方はむしろAだろ。

数学的根拠も示してないのに一般的とかどういう神経してるんだろうかｗ

>>109
ネットワークと繋がるアプリケーションを考えろ
アプリケーションはネットワークより小さいものだが
アプリケーションはネットワークへのアクセスをインジェクションして内部に抱えることができる

>>173
お前が言ってることは間違ってる
これも自明なんだが？

前提わかってるか？

依存関係の定義を一箇所にするっていうのは
一般的なプログラミングのセオリーに反してるんだよ。

ファイルを分割するとき責務で分割する。機能分割してはいけない。
例えば、O/Rマッパーはテーブル（責務）ごとに分割する。
select機能、update機能、delete機能、ごとに分割したりはしない
こんなことをすると、テーブルの構造が変わったとき、
select機能、update機能、delete機能、の各ファイル３つの
ファイルを修正することになる

依存関係の定義っていうのは、まさに機能ごとの定義になってる
あるモジュールが依存するオブジェクトが変わった（例えば追加）されたとき、
依存関係の定義ファイルまで修正しなければいけなくなる

責務ではなくて機能で分割されている証拠

結局手抜きしてフィールドインジェクションしてるわ

関数型メインだから勝手に問題消滅してるわ。テスタブルなコードばかりだし。

そりゃな、世界でもトップクラスの
アーキテクトだし

５ちゃんねるで騒いてるガキとは
レイヤーが違うよｗ

> 適当なブログに命名したって書いたら発案者になってしまうなら楽なもんだよな

楽じゃないよ

> As a result with a lot of discussion with various IoC advocates
> we settled on the name Dependency Injection.

> 結論をいえば、このパターンにはもっと明確な名前が必要なように思う。
> 「制御の反転」という用語では包括的すぎる。これでは混乱する人が出てくるのも無理はない。
> 様ざまな IoC 支持者と多くの議論を重ねた末、その名前は Dependency Injection (依存オブジェクト注入)に落ち着いた。

こう書いてあるだろ？

IoC 支持者と多くの議論を重ねて命名したんだよ
お前にそれができるか？

>>197
地動説の置き換えが思いつかなかったんだなwwwwwwwwwww

> 依存性を注入してればDIだよ
嘘つくな。誰がそんな事言ってるんだ？

こちらはソースをちゃんと示せる。
お前は今まで一つも示せてない
個人ブログはソースじゃないからな

マイクロソフト
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
↑の詳細情報に書いてある
「制御の反転パターンの詳細については、以下の情報を参照してください。」
のリンク先

Fowler の Web サイトの「Inversion of Control Containers and the Dependency Injection pattern」
https://www.martinfowler.com/articles/injection.html

必須でないなら使用してもしなくてもよい
それはまさにオプションのことである
はい自明

>>169
俺は理を語ってるだけだ
理には俺という権威は必要ない
数学の証明と同じこと

依存性の注入(DI)とは
依存性を注入することである

これは自明である

依存性の注入を実装する方法は複数存在する
DIコンテナはその一種でしかないので必須要素ではない

これは二種類以上例を挙げれば証明できる
例1 DIコンテナパターン
例2 貧者のDIパターン

はい終わり
この理は誰々が言ってたとか関係ねえんだよ

DIなんて実装の一作法でしか無いのに、まるでオブジェクト指向の根幹みたいな勘違いさせるスレタイってw
…あ、隔離スレかww

>>285
必須と明記された資料はマーティンのサイトにもMicrosoftのサイトにもないぞ
あるというなら必須であると明記されたソースだして
なければ必須ではないということ
つまりオプションということだ

なにそのpoormanって、いつからアベンジャーズの話になったの？

結局、間違ったことを書いて、
間違っていることを証明してみせよって
言ってるだけなんだよなｗ

何言ってんだこいつら

マックブックも作る時はDIだよ
各地から部品を調達して組み合わせてテストしてる

最終的にユーザーに届く時は美しいUIやAPIにパッケージされてるというだけ
製造過程では他と同じようにDIしてる

>>101
そこまでいくとDIではなく
足し算や代入のような命令文の粒度だろうね
命令文にDIは必要ないだろ？
コンデンサもトランジスタもCPUの実装なんだよ

でもCPUはDIで独立性を高めた方がいいわけだな

DIはスタティックおじさんの一種だなw

マーチンファウラーはDIの名付け親
マーチンファウラーは「こういうものをDIと名付けます」と
言ってることに対して、他人が、それはDIじゃないと
いっても、バカにされるぞｗ

■ Spring でのセッター・インジェクションの例
Spring Framework は エンタープライズ Java 開発向けの守備範囲の広いフレームワークだ。
トランザクション、永続化フレームワーク、Web アプリケーション開発や JDBC に関する抽象レイヤがある。

MovieLister がインジェクションに対応できるように、 サービス設定用の setter メソッドを定義しなければならない。
（省略）

同様に、MovieFinder には文字列の setter を定義する。
（省略）

3番目のステップとして、ファイルに設定を記述する。Spring での設定は XML ファイルでもコードでも可能だが、 XMLで行うことが望ましいとされている。

<beans>
<bean id=”MovieLister” class=”spring.MovieLister”>
<property name=”finder”>
<ref local=”MovieFinder”/>
</property>
</bean>
<bean id=”MovieFinder” class=”spring.ColonMovieFinder”>
<property name=”filename”>
<value>movies1.txt</value>
</property>
</bean>
</beans>

テストはこんな感じだ。
public void testWithSpring() throws Exception {
ApplicationContext ctx = new FileSystemXmlApplicationContext(“spring.xml”);
MovieLister lister = (MovieLister) ctx.getBean(“MovieLister”);
Movie[] movies = lister.moviesDirectedBy(“Sergio Leone”);
assertEquals(“Once Upon a Time in the West”, movies[0].getTitle());
}

>>291
自明

こういうふうに、自明でないものを自明とか
嘘つくやつがいるせいで信用されないってわかってないのかね？

>>324みればわかるけど、理由がないんだよ。
長々とした水増し文章見てもわかるだろ？
結局、あいつは馬鹿なんだ。程度のことしか言ってない
DIに明確なメリットが無いから、技術的な話ができないんだよ

> 依存性を注入してればDIだよ
> そんで注入するための手段は無数にあって
> DIコンテナはそのうちの1つのパターンでしかない
>
> DIコンテナがなくてもDIは成立する
> これ基本中の基本だからそろそろ理解してくれないかな

>>153だけど、俺も単純にこう思うんだよなあ。
で、毎回マーチンファウラーのリンクばかりでわけわからん。もう少しわかりやすく例えて説明してほしい。
そのためのスレなんだから。

>>325
オブジェクト指向って想定される変更に柔軟に対応できるように
クラスを使って変更点を一箇所に抽出するプログラミングスタイルと言えるよね？

で、依存関係を一つに集約する方法が、DIであり、メインからのインジェクションだろう？

そんなもの必要ない！とか感情論的に言われたら
君は依存関係が一つにまとまることがメリットとなるプロジェクトに携わったことがないということになるのでは？

どんな優れたパターンもテクニックもライブラリもフレームワークも技術も
目的がハローワールドを作ることなのであれば、全て無価値だ。

少なくともおれは、小さなアプリケーションから始まって、そのアプリケーションが成長するとともに管理が複雑化し
その複雑さの解消のひとつとして、依存性をひとつにまとめることは大きな価値があったよ。

メインを見れば、どのようにプログラムが動いてるか、抽象度の高いとこから見渡すことができる。

それが、プロジェクトの全てのファイルを開いて一つずつメモしなければ依存関係がわからない状態なんて、クソ喰らえだね！

>>176
1. 自明じゃない
M.F.が初出という証拠がない

2. だからなんだ

3. これはむしろDIコンテナは必須ではないということだがよろしいか？
組み立て役は組み立てれればいいのでDIコンテナである必要はない

1. DIという用語を作ったのマーチンファウラーである
これは自明

2. このサイトがマーチンファウラーのサイトである
https://www.martinfowler.com/articles/injection.html
（翻訳） https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html#FormsOfDependencyInjection

これも自明

3. DIの基本的な考え方は独立したオブジェクトをAssember（組み立て役）として用意する

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

これも自明

みなさんお開きにしましょうか？
DIはDIコンテナを使うパターンであると
わかった上で、言葉遊びでしてるだけなんですよ
そんなやつに真面目に付き合う必要はありません。

>>41
> オブジェクトのオーケストレーションという責務

なんで責務を増やすの？
そんなの不要なものなのに

デメリットが大きすぎて、DIと同じメリットが得られる
別の手法を選ばざるをえない
コードを書き捨てるドカタは事情が違うかもしれないけど

一方は証明できるのに、もう一方の人は証明できない
これも能力の差なのかな
アンチの方こそDIをよく理解している

>>286
いや、必須じゃないという根拠を聞いてるんだが？