ｵﾌﾞｼﾞｪｸﾄ指向、DIとService Locatorの違いを教えて4
■ このスレッドは過去ログ倉庫に格納されています
■ オブジェクト指向・デザインパターン（有用）
わかり易い例
class Dog extends Animal
class Cat extends Animal
■ DI（ゴミ）
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
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/
ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
https://medaka.5ch.net/test/read.cgi/prog/1526733859/ Service Locator と Dependency Injection の違いから
正しいDependency Injectionの意味を理解しよう！
■ Service Locator と Dependency Injection ってなにが違うの？
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
https://i-msdn.sec.s-msft.com/dynimg/IC258669.png の図より
Service Locator には、サービスロケーターがあって、
Dependency Injection には、その代わりに
ビルダーっていうのがあるのはわかった。
そのビルダーっていうのがDIコンテナと
呼ばれているものであることもわかった
重要な違いは、
Service Locator は、サービスロケーター があって
Dependency Injection には、ビルダー（DIコンテナ）がある https://msdn.microsoft.com/ja-jp/magazine/mt707534.aspx
サービス実装への参照がハードコーディングされる問題を解決するために用意されているのが、
DI による間接参照です。DI では、サービスのインスタンスを new 演算子で直接作成するのではなく、
クライアント (アプリケーション) はサービスのインスタンスを、サービス コレクションや「ファクトリ」に要求します。 DIされるクラスはDIコンテナを直接利用しないようにしようね終わり https://github.com/google/guice/wiki/Motivation#dependency-injection
Dependency Injection
Like the factory, dependency injection is just a design pattern.
The core principle is to separate behaviour from dependency resolution.
In our example, the RealBillingService is not responsible for looking up the TransactionLog and CreditCardProcessor.
Instead, they're passed in as constructor parameters: https://github.com/google/guice/wiki/GettingStarted
Guiceとの依存関係注入を始める方法。
入門
依存性注入の場合、オブジェクトはコンストラクタの依存関係を受け入れます。
オブジェクトを構築するには、まずその依存関係を構築します。しかし、
各依存関係を構築するには、その依存関係などが必要です。したがって、
オブジェクトを作成するときは、実際にオブジェクトグラフを作成する必要があります。
手作業でオブジェクトグラフを作成すると、労力がかかり、エラーが発生しやすくなり、
テストが困難になります。代わりに、Guiceはオブジェクトグラフを作成することができます。
しかし、まずGuiceは、あなたが望むように正確にグラフを構築するように構成する必要があります。
モジュールはインジェクタのビルディングブロックであり、Guiceのオブジェクトグラフビルダーです。
まず、インジェクタを作成し、それを使用して以下をビルドしBillingServiceます。
billingServiceを構築することで、Guiceを使って小さなオブジェクトグラフを構築しました。
グラフには、請求サービスとそれに依存するクレジットカードプロセッサとトランザクションログが含まれています。 これはGuiceの例だが、このような依存関係を定義して
public class BillingModule extends AbstractModule {
@Override
protected void configure() {
/*
* This tells Guice that whenever it sees a dependency on a TransactionLog,
* it should satisfy the dependency using a DatabaseTransactionLog.
*/
bind(TransactionLog.class).to(DatabaseTransactionLog.class);
/*
* Similarly, this binding tells Guice that when CreditCardProcessor is used in
* a dependency, that should be satisfied with a PaypalCreditCardProcessor.
*/
bind(CreditCardProcessor.class).to(PaypalCreditCardProcessor.class);
}
} このようなインジェクタを使ってインスタンスを作成するのがDIパターン
インジェクタっていうのが>>2でいうビルダーで
>>1でいうAssembler(組み立て係)のこと
public static void main(String[] args) {
/*
* Guice.createInjector() takes your Modules, and returns a new Injector
* instance. Most applications will call this method exactly once, in their
* main() method.
*/
Injector injector = Guice.createInjector(new BillingModule());
/*
* Now that we've got the injector, we can build objects.
*/
BillingService billingService = injector.getInstance(BillingService.class);
...
} 動機・・・なになにしたい
それをどうやって解決するかの一つの方法がDIパターンで
そのDIパターンは
http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。 Assemblerを使わない場合のDI（正確には手動のAssember）を
見てみるとわかると思うがすごく面倒で、
こんなことやってられない。
その批判を避けるためにDIパターンでは
DIコンテナを使うことが事実上の必須になっている。 面倒だと書いた、手動のAssemblerというのはこの部分
これはサンプルだから少ないが、もっと多くのクラスを
このmainにずらずらずらずらと何十行、何百行も書くことになる。
Unfortunately, now the clients of BillingService need to lookup its dependencies.
We can fix some of these by applying the pattern again! Classes that depend on
it can accept a BillingService in their constructor. For top-level classes,
it's useful to have a framework. Otherwise you'll need to construct
dependencies recursively when you need to use a service:
public static void main(String[] args) {
CreditCardProcessor processor = new PaypalCreditCardProcessor();
TransactionLog transactionLog = new DatabaseTransactionLog();
BillingService billingService
= new RealBillingService(processor, transactionLog);
...
} 単体テストでモックに差し替えるのにDIコンテナ使うの？ >>15
結局の所、それがDIを使う目的になっちゃってる
で、モックに差し替えるためにDI使わなくてもできるなら
DIいらないよね？って話
そのためのツールがJavaだとMockitoとかEasyMockとかJMockitになる
モックにすげ替えることができるように設計レベルで歪めてしまうDIと違って
単純な設計のまま、モックにすげ替えることが可能になる 前スレでストレージを他に変えるときDI使ってるという話忘れた？ >>17
それは単なるストラテジーパターンを使えばいいだけの話で、
mainにずらずら依存関係書いたりする必要がないから
DIじゃなくていいんだよっていう話なの理解してないの？ 結局手動でやってるんだ
フレームワークで簡単にできるように用意されてるの使えばいいのに 小さいものしか作ってないんだからいらんよ
mainに手動で書いていれば事足りる DIコンテナに登録しておけば自動でインジェクションしてくれたりするのに 面倒やん、その定義書くの
DIコンテナ用のライブラリも必要になるし
そんな事するぐらいならもうDIなんていらねーってなる ドカタが無理して数学について語るスレはここですか？ とりあえず https://kakutani.com/trans/fowler/injection.html の中から
Dependency Injection と Service Locator の違いが書いてある部分を抜き出してみた
これがそれぞれのパターンの重要な特徴だと思われる
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
https://kakutani.com/trans/fowler/injector.gif
> Service Locator を利用する
> Service Locator の背後にある基本的な考え方は、あるアプリケーションが必要とするであろうサービスの
> すべてを保持する、単一のオブジェクトを用意するというものだ。したがって、今回のアプリケーション用
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
https://kakutani.com/trans/fowler/locator.gif >>24
言葉の定義の問題であって数学の話じゃないで
元のスレにお帰りください。 DIは必須と言っていいぐらい有益だがDIコンテナは別にいらんな
Factoryを自分で書いたほうが柔軟で良い >>26
ドカタに数学は無理ですもんね
身の程を知るのは良いことですよ >>28
http://proofcafe.org/k27c8/math/math/set_theoryII/page/definition/
定義は大切！！
もう「定義」と「定理」とは、全くの別物であることは分かりましたね？
「定理」とは、命題の一種です。
一方「定義」とは「言葉決め」のことであり「命題」では決してございません。。。 公理1: 無能に数学はできない
公理2: ドカタは無能である
定理: ドカタに数学はできない
証明:
ドカタに数学ができると仮定する。
すると公理1よりドカタは無能ではない。
しかしドカタが無能ではないとすると公理2と矛盾する。
ゆえにドカタに数学はできない。Q.E.D ようやく定義だと気づいたかｗ
ドカタをからかうのは楽しいな
またくるからよ。じゃあなｗ >>30
なんで公理（命題）が２つ出てきてるんだよｗ
お前、本当は数学わかってないだろ >>30
> 定理: ドカタに数学はできない
> ゆえにドカタに数学はできない。Q.E.D
お前、定理（証明ずみなので、証明無しで使ってもいいはずのもの）を証明してるで？ >>32
自然数の公理系（ペアノの公理）は5個の公理で成り立ってるよ >>33
公理=仮定なんだから
仮定をもとにもう一方の仮定を証明なんかできないって
マジレスしたらだめな流れ？ >>34
その定理の証明だろw
そして定理には証明が必要だろ
ホント数学知らんのな >>36
公理は仮定じゃないよ
このスレに出てきた言葉で一番近いニュアンスなら定義 >>37
仮定から証明をすることは不可能って話なんだけど
理解してる？ >>38
ふーん、そういう理屈で行くのなら
定義を証明して見せてっていうだけの話だけど 定理ってのはさ、公理が真のときに真になる命題のことなんだよね
だから公理が成り立って証明がつく命題は真といえる
もちろん、全く別の公理を立てることもできて、数学では互いに矛盾するようないろんな公理系がある 話逸れてるけど、DIとService Locatorの定義はこれであってるんだよね？
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
https://kakutani.com/trans/fowler/injector.gif
> Service Locator を利用する
> Service Locator の背後にある基本的な考え方は、あるアプリケーションが必要とするであろうサービスの
> すべてを保持する、単一のオブジェクトを用意するというものだ。したがって、今回のアプリケーション用
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
https://kakutani.com/trans/fowler/locator.gif 物理法則と矛盾した世界を定義することも出来るのが数学だから
ドカタが無能でない世界も定義できる。数学ならね
でもこのスレのドカタは無能だねw >>47
> 物理法則と矛盾した世界を定義することも出来るのが
なるほど、物理法則と矛盾した世界を定義したわけか 男は俺だけの世界を定義して、
俺以外はみんな女、ハーレムじゃぁ
って感じかな？
ちょっと虚しいね >>49
そりゃ無能でないドカタもいるだろ実際には
でも、このスレのドカタは無能w ファウラーとかいうおじさんがこれがDIって言ってるだけだろ
真のDIがその定義であるかどうかはまた別の問題だな 良く知りもしない数学的証明なんて言葉でマウント取ろうとしたヤツが悪い
誰だよ最初に言いだしたヤツ >>52
そのファウラーがDIという言葉を作り出したんだよｗ
正確には有識者の意見をまとめてDIという呼び方が適切であると同意をとったんだけどな
だからDIと言う言葉を使うなら生みの親のファウラーの定義に従わなければいけない >>53
まあいいじゃん。いいおもちゃになってくれたしｗ >>54
ファウラーが生み出したということ
有識者が同意をとったこと
その同意が一般に認識されていて認められていること
ファウラーの定義に従わなければならないこと
この4つを数学的に証明して
できなきゃ嘘ってことだ >>57
定義なんで証明する必要なし
いい加減学習しろ お、今度のドカタは知恵をつけてきたじゃん
今度は「数学的証明さん」はどんなふうに対抗するのかな？ｗ >>58
ファウラーが言ってるのはオレオレファウラーDIの定義な
真のDIの定義とオレオレファウラー定義が同一のものなのかはまだわからない
なのでファウラーの定義を引用して、真のDIとはこういうものである、と言うことはできない
ファウラーによると、オレオレファウラーDIとはこういうものである、ならば言って良い 真のDIってなんだよｗｗｗｗ
お前の定義のDIが真のDIだとでも思ってんの？
それこそオレオレDIだろ > オレオレファウラーDI
ファウラーの時点でオレオレじゃないが？ ファウラーの定義にはAssemblerについて「独立したオブジェクトをAssembler(組み立て係)として用意し」としか書いてないね
ってことはAssemblerが一つであることも、ましてや依存関係をひとまとめに定義することもDIに必須じゃないわけだ？ >>64
図を見れば一つしかないことはわかる。
あと英語なら複数なら複数形になってるはず >>65
図には作られる側のクラスやインターフェースも一個しかないけど？ >>67
世界のソフトウェアの設計の基礎を作り上げた人 この業界でマーチンファウラーを知らないとかモグリだろ >>68
へー、すごい人なんだね。
>>69
すまん。モグリやったｗ で？マーティン・ファウラーのDIの定義がそれとして、だからどうしたと？ DIの定義を正しく知ってないと、DIの説明はできないってことでしょう？
オレオレDIの解説したってしょうがないし オレオレDIではない。俺が考える真のDIの説明である この世の他のどこにもない。俺だけの真のDIこそが。唯一正しいDIである つーか俺のほうがすごいだろ
マーチンファウラーなんかより いや、このハゲ、マジで何を作ったのかわからない
そもそも前線で働いてるのか？ 数十年にわたってビジネスへのオブジェクト指向の適用に尽力する独立コンサルタント。
ヘルスケア、金融取引、企業財務などの分野におけるシステムのコンサル経験を持つ。
顧客にはクライスラー、シティバンク、英国民保健サービス、アンダーセン・コンサルティング、ネットスケープ・コミュニケーションズなどが名を連ねる
『リファクタリング 既存のコードを安全に改善する』より そんな凄い人が提唱したDIに
一介のドカタがケチ付けてるってホント？ 人として凄いかどうかはセオリーの正当性とは関係がないんだよね つまりマーチンファウラーが正しいとは限らないということは
俺が正しいってことになりませんか？ 別の惑星では違う定義で同じことやってるかもしれない
誰が決めたから正しいなんてのは文系的で馬鹿馬鹿しいか細い理だよ つまり他人は正しいとは限らない
俺のこと信じる気になりましたか？ DIアンチはファウラーを持ち上げたいの？貶したいの？ DIアンチじゃねーし
ファウラーは尊敬してるが
DIとDIコンテナは別の話だ
それだけ んで？
工数削減なのか？
品質向上なのか？
どっちに効果あるの？
このハゲは >>88
マーチンファウラーを貶めることで
俺の言うことをが正しいと証明したい ハゲだぞ、こいつハゲだぞ、俺はふさふさだ
ハゲと言うだけで、もう結論出てるだろ ほら、いねーだろ。つまりどういうことか
俺が正しいってことになりませんか マーチンファウラーを叩くことで自分の説得力を
あげようとする卑怯な手が失敗した今、こいつは何をする気だろうか？ はい、茶番は終わりだ
DIとService Locatorの定義
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
https://kakutani.com/trans/fowler/injector.gif
> Service Locator を利用する
> Service Locator の背後にある基本的な考え方は、あるアプリケーションが必要とするであろうサービスの
> すべてを保持する、単一のオブジェクトを用意するというものだ。したがって、今回のアプリケーション用
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
https://kakutani.com/trans/fowler/locator.gif >>100
メリットの話ではない。DIのちゃんとした定義を明確にしてるだけだ >>101
その定義が正しいという証明がない
おっさんが勝手に定義だっていってるだけ >>102
ドカタが証明とかの言葉を使うなって言ってんだろ
無能を自覚しろ >>104
すごく困る。ファウラーの定義とは違うことを言ってるから >>104
問題はないがDIコンテナが必須というのは正確ではない
というだけの話 必須じゃなくてもDIコンテナを使わないと
手動でDIコンテナ相当のことをしないといけないのでもっと大変
だから開発効率上、DIコンテナを使うのは必須 リポジトリでオブジェクトを作るときってDIコンテナ使う？ >>109
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？ ファウラーの定義にはこう書かれています
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。 つまり
独立したオブジェクトをAssembler(組み立て係)として用意します
MovieFinder インタフェースの実装をMovieLister クラスのフィールドへ適切に設定させまます。
これがDependency Injection の基本的な考え方です もうね既存の用語を違う意味で使ってる時点でダメダメなんだよな。 既存の用語っていのなら、DependencyもInjectionも
英語なわけで、昔からあった用語
だから、ファウラーが勝手に定義して言い訳がない
人それぞれのDependency Injectionというのがある
俺のDependency Injectionは俺だけのものだ
他人が勝手に決めつけていいものではない >>113
じゃあmain()の中でインジェクションして回っても、main()が何かのオブジェクトに属する言語なら
main()を持つオブジェクト = Assembler(組み立て係)
という解釈が成立するからファウラーのDIになるね >>116
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？ >>117
>>109は「もっと大変」とかいう感想を語ってるけど
>>116はどこが感想なの？ 勝手な解釈するなってことですよ
解釈はファウラーが言った言葉ではない >>119
うっせー、みとめん
コンストラクタにオブジェクトを指定したら
それはDI ファウラーはハゲだ。それだけで疑うのに十分だろ。はい論破 >>120
ファウラーの定義にDIコンテナなんて言葉は出てこないので
DIコンテナ必須なんて勝手な解釈するなってことですね、わかります >>121
なら上のリポジトリにissue上げてみて ＤＩについて一番まともな事書いてある本ってどれでしょうか？ >>128
AmazonでDependency Injectionで検索した？ >>127
つまり、ファウラーの定義に従え！って何度もコピペしてたDIアンチ自身が
ファウラーの定義を勝手に解釈して歪めてたってことね デコレーター使いたいなぁとかパラメーターで分岐する生成したいなぁとか細かく制御しようとするとDIコンテナじゃ物足りないんだよね
コンテナに登録するのとファクトリー書くのじゃ手間に大差ないし
DIは便利だけどDIコンテナとないうゴミパターンを必須にされたら困るよ >>133
DIってそういうときに使うもんじゃないし。
基本的にアプリケーション内でインスタンスが一つしか
必要ないときだけ使用する
ウェブアプリのように独立したセッションがある場合
そのセッションごとに使用することもある ないけど、事実上そうだよ。
でないとサービスロケーターになってしまう
DIパターンにおけるインスタンスを生成するオブジェクト（通常DIコンテナ）に
依存せずにインスタンスを生成するには、上の層でインスタンスを生成してもらわないといけない
上の層っていうのはフレームワークに隠蔽されたアクションに相当する処理の開始部分
「DIパターンにおけるインスタンスを生成するオブジェクト」を上の層以外の
部分で使うことは、それに依存してしまうことになってしまい、
それは事実上サービスロケーターと同じことになる >>135
明示的にスコープ指定するから当たり前じゃない？ >>136
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
https://kakutani.com/trans/fowler/locator.gif
MovieLister から ServiceLocator への参照が発生するのがサービスアロケータだろ
ファウラーの定義を勝手に解釈するの止めてもらえませんかね？ >>134
DIの仕事だよ
デコレーターなんてまさにDIコンテナがよしなに処理してくれるべき仕事だし
パラメーターはよくあるパターンだとデータベースの接続先だけが異なる場合などに必要
そもそもアプリにインスタンスが1つなら全部シングルトンになってしまうが一般的なDIコンテナの設計はそんな風にはなってない
あくまでシングルトンは特別な場合 >>138
MovieLister から ServiceLocatorを使わずに、
何かしらのインスタンスを作成するにはどうすればいい？
newならもちろん普通にできる。だけどnewではDIにならない >>139
> デコレーターなんてまさにDIコンテナがよしなに処理してくれるべき仕事だし
いや、むり。DIコンテナから複数のインスタンスを生成する方法がない >>139
> パラメーターはよくあるパターンだとデータベースの接続先だけが異なる場合などに必要
そのように、最初に一回やってしまえばOKみたいなものにしか使えない >>139
> そもそもアプリにインスタンスが1つなら全部シングルトンになってしまうが一般的なDIコンテナの設計はそんな風にはなってない
> あくまでシングルトンは特別な場合
だから独立したセッションがある場合はセッションごとって書いたろ？
セッション単位とかスレッド単位とか他と独立した処理が
フレームワークなどから開始される場合、その単位で一つ作成されることはあるよ
セッション単位のシングルトンみたいな
だけど一つのクラスやメソッドでインスタンスを複数生成して使うような場合には使えない。 >>141
DIコンテナはファクトリの下位互換ってことか >>145
やっぱ使いにくいな
DIコンテナよりファクトリの方が柔軟で便利だな
やっぱりDIコンテナは不要なんじゃないか？ DIコンテナってさインフラへの依存を断ち切ろうってコンセプトに喧嘩売ってるよな
他サービスへの依存は切れるけどDIフレームワークそのものにべったり依存してしまう
Javaのプログラムを.net coreに移植しようとしたらなんか全部のクラスに@Injectとか書いてあんの
普通にFactoryを作ればいいじゃんっての
ほんとDIコンテナってバカみたいだよな >>148
.NET CoreこそフレームワークレベルでDIフル活用してるだろ >>147
そもそも使う目的がシステムの何かの機能を実現するために必要だからじゃなくて
DI使っていればクラスに依存せずにインターフェースだけに依存すれば良くなるし、
だから同じインターフェースの違う実装に入れ替え可能
そうしておけば、後々便利なこともあるじゃない？みたいな
今それいらないよね？って突っ込まれること請け合いだからねｗ
クラスを入れ替えたいだけなら、ソースコードを修正すれば十分なのさ
DIは生成するクラスをアプリの実行状態に応じて柔軟に変更可能なものなんかじゃなくて、
生成するクラスを実行の初期化時に決められるってだけだからね >>149
DIはいいんだよ別に
DIコンテナ(asp.net coreだとServiceCollectionだが)を強制されるのがダメ
まあMicrosoftはまだ@Injectみたいなロックインのための仕組みを盛り込まないだけマシだけど
DIコンテナの制約を意識してオブジェクトモデル設計を変えなきゃいけない場面が時々ある
DIコンテナの罪は大きい
DIそのものは便利で合理的なのにね
DIコンテナがすべてを台無しにしてる
自由が約束されたファクトリーを使うべき >>150
違う違う
DIは、じゃなくて、DIコンテナは、な
ここ重要な
DIは必要だけどDIコンテナは邪魔 >>151
そうすると、コンストラクタで渡す部分が、
特定のクラスに依存してしまう
そうやって特定のクラスに依存するものが
あちこちにできてしまうと、本末転倒になってしまうから、
DIでは、依存関係を定義する部分をひとまとめにして
そこだけは諦めてクラス名をずらずら書くんだよ。 >>153
DIコンテナを使わないで、手動でDIコンテナの代わりの
コードを書くと、大変なことになるぞ。
メンテナンス性が極端に落ちる >>154
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？ >>156
いや事実
コンストラクタで渡す場合、以下のように
ClassAはClassBやClassCに依存してしまう
Class A {
foo() {
ClassB b = new ClassB();
ClassC c = new ClassC(b);
}
} >>155
アンチはDIコンテナだとカバーできない部分があるから、ファクトリを使うんだってさ >>157
了解
もちろんこのようにすればClassBにもClassCにも依存しないが
今度は、DIContainerに依存してしまう。
Class A {
foo() {
IC c = DIContainer.create("ClassC");
}
}
これがそもそもService LocatorでDIContainer
（という名前にしているが実際はServiceLocatorとすべき）
に依存しないようにしたほうがDI >>152
Microsoftも@inject使ってることすら知らないお馬鹿さん >>159
> アンチはDIコンテナだとカバーできない部分があるから、ファクトリを使うんだってさ
うん。ファクトリだとDIみたいに依存関係をひとまとめにする部分はないので
メンテナンス性は下がらない。ファクトリは関連するものだけを生成するのでね >>155
全然落ちんよ
むしろファクトリーのほうが保守性が高い
生成箇所が明確で書いてあることを読めばそれで理解できるから >>158
ファウラーが定義してるかどうか聞いてるんですけど？
いつもみたいに引用してくださいよ >>166
はいどうぞ
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
https://kakutani.com/trans/fowler/injector.gif
> Service Locator を利用する
> Service Locator の背後にある基本的な考え方は、あるアプリケーションが必要とするであろうサービスの
> すべてを保持する、単一のオブジェクトを用意するというものだ。したがって、今回のアプリケーション用
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
https://kakutani.com/trans/fowler/locator.gif >>164
> むしろファクトリーのほうが保守性が高い
そりゃDIは保守性低いんで、
必要な部分にファクトリー使いましょうと
言ってるんだから当然だなｗ ちなみにDIの保守性の悪さを示す例
誰か有名でそれなりの規模のものを知ってると嬉しいんだが、
まあ適当に見つけてきた
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/applicationContext.xml
DIコンテナを使わない場合でも、これ相当のことをコードで書く必要がある。 リンク先見ない気がするんでコピペしてみるｗ
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (C) 2015 - 2016 - Open Source Geospatial Foundation. All rights reserved.
This code is licensed under the GPL 2.0 license, available at the root
application directory.
-->
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd";>
<beans>
<bean class="org.geoserver.platform.ModuleStatusImpl">
<constructor-arg index="0" value="gs-main"/>
<constructor-arg index="1" value="GeoServer Main"/>
</bean>
<bean class="org.geoserver.platform.RenderingEngineStatus"/>
<bean class="org.geoserver.platform.SystemPropertyStatus"/>
<bean class="org.geoserver.platform.SystemEnvironmentStatus"/>
<!-- lock providers -->
<bean id="nullLockProvider" class="org.geoserver.platform.resource.NullLockProvider"/>
<bean id="memoryLockProvider" class="org.geoserver.platform.resource.MemoryLockProvider"/>
<bean id="fileLockProvider" class="org.geoserver.platform.resource.FileLockProvider"/>
<bean id="lockProvider" class="org.geoserver.platform.resource.GlobalLockProvider">
<property name="delegate" ref="nullLockProvider"/>
</bean>
<bean id="lockProviderInitializer" class="org.geoserver.config.LockProviderInitializer"/>
<!-- used by alternative resource stores -->
<bean id="resourceNotificationDispatcher" class="org.geoserver.platform.resource.SimpleResourceNotificationDispatcher"/> <!-- resources -->
<bean id="dataDirectoryResourceStore" class="org.geoserver.platform.resource.DataDirectoryResourceStore">
<property name="lockProvider" ref="lockProvider"/>
</bean>
<bean id="resourceStore" class="org.geoserver.platform.resource.ResourceStoreFactory" />
<bean id="resourceLoader" class="org.geoserver.platform.GeoServerResourceLoader">
<constructor-arg ref="resourceStore"/>
</bean>
<bean id="dataDirectory" class="org.geoserver.config.GeoServerDataDirectory">
<constructor-arg ref="resourceLoader"/>
</bean>
<bean id="manifestLoader" class="org.geoserver.ManifestLoader" lazy-init="false">
<constructor-arg ref="resourceLoader"/>
</bean>
<!-- extensions -->
<bean id="extensions" class="org.geoserver.platform.GeoServerExtensions"/>
<!-- environments -->
<bean id="environments" class="org.geoserver.platform.GeoServerEnvironment" depends-on="extensions"/>
<!-- the shared filter factory -->
<bean id="filterFactory" class="org.geotools.filter.FilterFactoryImpl"/>
<!-- geotools factory iterator provider, commented
<bean id="factoryIteratorProvider" depends-on="extensions"
class="org.geoserver.platform.GeoServerFactoryIteratorProvider"/>
--> <!--
core modules
-->
<!-- configuration module -->
<!-- note: we use depends to ensure that all datastore plugins are
loaded from the spring container before processing hte catalog -->
<bean id="rawCatalog" class="org.geoserver.catalog.impl.CatalogImpl" depends-on="configurationLock">
<property name="resourceLoader" ref="resourceLoader"/>
</bean>
<bean id="secureCatalog" class="org.geoserver.security.SecureCatalogImpl" depends-on="accessRulesDao,extensions">
<constructor-arg ref="rawCatalog" />
</bean>
<bean id="advertisedCatalog" class="org.geoserver.catalog.impl.AdvertisedCatalog">
<constructor-arg ref="secureCatalog" />
<property name="layerGroupVisibilityPolicy">
<bean id="org.geoserver.catalog.LayerGroupVisibilityPolicy.HIDE_NEVER"
class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean"/>
</property>
</bean>
<bean id="localWorkspaceCatalog" class="org.geoserver.catalog.impl.LocalWorkspaceCatalog">
<constructor-arg ref="advertisedCatalog" />
</bean>
<bean id="disabledResourceFilter" class="org.geoserver.security.DisabledResourceFilter"/>
<!-- Switch this when you want to enable the secure catalog by default -->
<!--alias name="secureCatalog" alias="catalog"/-->
<alias name="localWorkspaceCatalog" alias="catalog"/> <bean id="geoServer" class="org.geoserver.config.impl.GeoServerImpl">
<property name="catalog" ref="catalog"/>
</bean>
<bean id="geoServerLoader" class="org.geoserver.config.GeoServerLoaderProxy">
<constructor-arg ref="resourceLoader"/>
</bean>
<!--
service strategies
-->
<bean id="serviceStrategyFactory"
class="org.vfny.geoserver.servlets.ServiceStrategyFactory">
<constructor-arg ref="geoServer"/>
</bean>
<bean id="speedServiceStrategy" name="SPEED"
class="org.vfny.geoserver.servlets.SpeedStrategy"/>
<bean id="fileServiceStrategy" name="FILE"
class="org.vfny.geoserver.servlets.FileStrategy"/>
<bean id="bufferServiceStrategy" name="BUFFER"
class="org.vfny.geoserver.servlets.BufferStrategy"/>
<bean id="partialBufferServiceStrategy2" name="PARTIAL-BUFFER2"
class="org.vfny.geoserver.servlets.PartialBufferStrategy2"/>
<!--
custom property editors
--> >>168
コンストラクタで設定しちゃダメって書いてないどころか、
コンストラクタインジェクションの例すら書いてあるんですがw >>175
コンストラクタで設定したらだめなんて
一言も言ってないけど？
思い込みで発言すんなや >>177
じゃあ>>140への回答はコンストラクタで設定すれば良い、でFAだな
コンストラクタで渡せばDIコンテナなんて不要なことすら分からないなんてお前はホントにアホだなw DIの使われ方を見ると依存関係がどうこうというより、
クラスに対する設定を記述しているだけな気がするな なんでアンチは自分が考えたオレオレDIをファウラーのDIみたいに言うの？
もっと提唱者に敬意を払うべきでは？ オブジェクト指向にしろＤＩにしろ
実際に困ったことありました→ある手法を使ったことでこんなに便利になりました
ってことが明確にわかる実例がないから悪いんだよね
xmlのこのクソなげえ設定ファイルが必要ですがそれを補って有り余る程DIには利点があり
こんなに便利になりましたってのが１ミリもわからない
そこら編を死ぬほど詳しく書いた本とか売れそうな気もするんだけど誰も書かないな >>178
> じゃあ>>140への回答はコンストラクタで設定すれば良い、でFAだな
コンストラクタで設定するのはnew相当を行うときだ。
質問はnew相当のことをどうやって行うかだ
俺なら、インスタンスの作成をするにはどうすればいい？の答えに
new演算子を使用すると答えるが、
お前は、コンストラクタで設定すればいいって答えるのか？
回答が意味不明だぞ >>181
実際は新しい言葉作ってバカなPGを手玉に取ってお金を集めちゃう商売だからそんな資料は作れないよ >>183
それが大事だよね
ここのドカタが何言ってるかよりも >>181
デザインパターンのカタログは、書式がしっかりしていて
ちゃんとどういう問題を解決するのか？を書く項目があるぞ
https://qiita.com/ndxbn/items/6557646c5398e06aea49#%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3-is-%E3%81%AA%E3%81%AB
> パターン名
> そのパターンが解決する問題
> そのパターンが如何にして問題を解決するかの、解法
> 結果発生する、トレードオフ
それに対してDIは解決する問題がなくて、
依存関係を分離しておけば、将来なにかの役に立つでしょ？になってる >>182
もともとは>>138の
> MovieLister から ServiceLocator への参照が発生するのがサービスアロケータだろ
に対して、>>140が参照持たないためにはnewするしかないって言ってる
で、その回答として
コンストラクタで渡せばMovieLister から ServiceLocator への参照が発生しません
って言ってるわけ。何が意味不明なの？ >>187
> コンストラクタで渡せばMovieLister から ServiceLocator への参照が発生しません
だからその場合、どうやってインスタンスを作成するのかって話をしてるんだが？
お前はインスタンス作成後の話しかしてねーじゃねーか
わざとか？
ちゃんと話を読め↓
> ないけど、事実上そうだよ。
> でないとサービスロケーターになってしまう
>
> DIパターンにおけるインスタンスを生成するオブジェクト（通常DIコンテナ）に
> 依存せずにインスタンスを生成するには、上の層でインスタンスを生成してもらわないといけない
> 上の層っていうのはフレームワークに隠蔽されたアクションに相当する処理の開始部分
>
> 「DIパターンにおけるインスタンスを生成するオブジェクト」を上の層以外の
> 部分で使うことは、それに依存してしまうことになってしまい、
> それは事実上サービスロケーターと同じことになる >>191
サービスアロケータになってしまうと言うのは貴方の感想であって
ファウラーの定義では参照がなかったらサービスアロケータではありません >>189
いいのか、その話をして？
依存関係を一箇所に書くんじゃなくて、
今は各クラスにアノテーションとして書きましょう
に変わったって言いたいんだろう？ >>192
残念ながら事実だよ。
手動でnewしてしまうと、依存関係の定義情報が使用できない >>194
なんでファウラーの定義を離れて勝手なオレオレDIの話をするの？ >>195-196
はい？ DIの話なんかしてませんよ？
DIにならないって話をしてるんですが
この場合、DIの定義である↓を満たせない
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
DIじゃない方を使いましょうって言ってるんでしょ？ DIコンテナが無くてもDIできる。
ただしメンテナンス性が大きく下がる >>199
DIコンテナが無くてもDIできる、でFAね
良かった良かった そりゃオレオレDIコンテナを作ればできるだろうけど、
こいつ何を言ってるんだろう？ ファウラーのDIをドカタが勝手に独自解釈してるから正しただけだが？
提唱者には敬意を払わないとね >>201
オレオレDIコンテナって何それ？
ファウラーの定義に出てきますか？ そうだ！Factoryが生成するインスタンスのClassを、設定ファイルに記述するようにしたらいいんじゃないかな？ DIコンテナもxml設定ファイルもウンコ言語Javaが産んだドカタ文化だろ
Javaのゴミさを理由にDIを貶めてんじゃねーよ services.AddTransient<IUnko>(c =>
new LogDecorator(
new TransactionScopeDecorator(
new IOValidationDecorator(
new UnkoImpl(c => c.GetService<IDepend1>(),
c.GetService<IDepend2>(),
...
))));
DIコンテナを使うとこんな馬鹿みたいな定義がずらずらと並んでしまう
これはもはやXMLより酷い
こんなんならファクトリークラスとして責務分割したほうがマシ
DIコンテナはおぞましく巨大な泥団子そのもの
オブジェクト指向信者が使っていいものじゃない >>209
Factoryで責務分割すると、どういうこーどになるの？ >>211
> Factoryで責務分割すると、どういうこーどになるの？
違う違う。Factoryで責務分割するのではない
依存関係を外部から注入するから、こういう結果になるということなんだから
依存関係を埋め込むことで、シンプルになる。
依存関係を埋め込んでるだけでSOLID原則を破るわけではないので問題はない
（SOLID原則には依存関係を埋め込んではいけないなどという原則は無い）
またFactoryを使うなって話でもない。設計上必要な場所にはFactoryを使う
単に依存関係を分離するためにDIだかFactoryだかを使わないって話 スマンちょっと研究したらDecoratorふつうに出来たわ
DIコンテナは神。ファクトリーはゴミという結果になってしまった >>216
どうやって？ DIではDecoratorはできないはずだけど？ >>219
DIは依存関係を注入するだけだからだよ 依存関係注入が悪い翻訳だからね
加えて
コンポーネントはパラメーターで渡そう
コンポーネント組立は設定ファイルで
いや属性でやるだろ
とか議論の軸も整理されてない ファウラーのDIが、DIの正しい定義だって
言ってるのにそれを無視するからこうなるんだよ
ファウラーは依存関係を分離するために
依存関係を注入する側の仕組みをどうするかの話をしてるのに
依存関係が注入される側の仕組みの方を見て
注入する側の仕組みは何でも構わない、変数の型をインターフェースにしておいて、
内部でnewしなければなんでもDIだって言ってるから意味不明なことになる
議論の筋の整理のレベルじゃなくて、間違った理解をしてる >>223
ファウラーは依存関係を注入する側の仕組みについてなんて定義してるの？
って聞いてみたけど、また引用じゃなくて独自解釈を垂れるんだろうな...w >>224
書いてあるやん。
「Assemblerが適切に設定させる」というように設定部分の話をしてる
クラスにインターフェースの変数を用意してコンストラクタで渡してもらうなんて話はしてない
http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。 依存関係を解決する側はなんでもいい
ファクトリーでもいいし
DIコンテナでもいい(というかこれはモロにファクトリー)
貧者のDIでもいいし
メインで初期化でもいい
あくまでオプション Dependency Injection の基本的な考え方は
って書いてるのに、オプションとか意味不明
基本的な考え方ぐらい理解しましょうや 工場（ファクトリー）に鉄製品を作る機能をもたせたものを製鉄所というのであって、
工場だったら必ず製鉄所になるわけじゃない。
依存関係を解決する機能をもたせたものがDIなのであって
FactoryだったらかならずDIコンテナになるわけじゃない もうさ、用語として組み込み系で使いづらいんだよなぁ >>227
基本的な考え方は依存するクラスをインターフェースに置き換えて外部から与えましょうってだけ
ここまでがDIの本質
でもそうすると規模が大きくなった時に外部から与える処理自体が複雑になってくるよね
って副次的な課題に対しての解決策が幾つかあって
それがファクトリーやDIコンテナや貧者のDI
DIを語る上ではこれらは必須ではない
という意味でのオプション >>230
> 基本的な考え方は依存するクラスをインターフェースに置き換えて外部から与えましょうってだけ
いえ、
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
です Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 >>231
なんか、DI嫌いな人が、DI使ってる人を「マーチンファウラーを盲信する教条主義者」として貶めようとしてるようにしか見えない。 もともとな、外部から依存関係を与えるなんてことをしなければ、
obj = new MyObject();
これだけで使えたんだよ。
MyObjectがどんなクラスに依存していたって、
それは内部実装の話で使う側からすれば関係ないからな
これをコンストラクタなどで渡すとしたら
a = new A
b = new B
c = new C(b);
obj = new MyObject(a, b);
みたいに長くなってしまうわけよ。
本末転倒じゃん？
だからこれを今までの形に近い
obj = DIContainer.create(MyObject);
とかけるようにしましょうっていうのが、DIパターンなんだよ
独立したオブジェクト（この場合はDIContainer）を組み立て役として用意してる いやいや。依存性が切れてないバージョンを出してきて「長くなったでしょ？」って…… DIContainerの生成メソッドを自分で呼び出すことはないよ > DIContainerの生成メソッドを自分で呼び出すことはないよ
そりゃフレームワークが呼び出してるからな
そのフレームワークが呼び出せるようにするためには
絶対に依存関係の定義が必要になるわけよ。
長ったらしいApplicationContext.xmlのようなやつな 直接インスタンス化すると開発する時に何かと不便じゃん
インフラが正常稼動してないと開発できない
ちょっとした動作確認にも時間がかかる
ビルド時間が長すぎる >>240
反論しろよｗ
>>241
クラス自体に依存関係をアノテーションで埋め込むんですよね？ｗ
依存関係をクラス自体に書くわけですねーｗ >>244
それ以外ないよ？
あるって言うなら言ってくれてもいいけど、
でもないからな〜な。何を言うつもりだろー？ >>242
開発中なんだからソースコード修正して開発すれば良いんだよ 今の王道DIComtainerは単純な登録タイプ
このインターフェースはこのタイプを生成しろ
あのインターフェースはこのファクトリーデリゲート使って生成しろ
みたいなやつね
KISSの原則に従って無意味な設定ファイルや制御しにくくわかりにくいアノテーションは駆逐された
シンプルなコードで普通にコンテナをビルドして実行するだけ >>251
> シンプルなコードで普通にコンテナをビルドして実行するだけ
ふーん？そのコンテナの名前は？
何で隠すの？ >>253
サービスロケーターじゃないよ
マーチン・ファウラーのDIの説明ででてくるPicoContainerでもそうなってるでしょ？
https://kakutani.com/trans/fowler/injection.html#ConstructorInjectionWithPicocontainer
> MutablePicoContainer pico = configureContainer();
> MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
最近の人は、フレームワークに隠されて、詳細を知らない
DIコンテナを使ったら何故か魔法のように何もしなくても勝手に設定されると思っちゃう
でも内部的になこのようなメソッドが呼び出されてる >>255
>>236ではこれを
＞obj = new MyObject();
こう書くって言ってんだろ
＞obj = DIContainer.create(MyObject);
こんなの完全に Service Locator だろ。 DIContainerへの参照を持ってしまってるからな
ほらファウラーの引用
> したがって、今回のアプリケーション用 ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。 >>257
その理屈で、
> MutablePicoContainer pico = configureContainer();
> MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
これがService Locatorにならないことの説明はできるの？
picoの参照を持ってしまっているよね？
答えを言うと、各クラスの内部で参照を持ってしまうことがService Locator うん>>236は外部から依存関係を与えずに
各クラスの内部で参照を持つと言っているからService Locator > 各クラスの内部で参照を持つと言っているからService Locator
言ってないよね？
サンプルコードもMyObjectの外部でしか使ってないよね？ こう書かないと理解できないのかな？
a = new A
b = new B
c = new C(b);
obj = new MyObject(a, c);
みたいに長くなってしまうわけよ。
本末転倒じゃん？
だからこれを今までの形に近い
a = DIContainer.create(A);
b = DIContainer.create(B);
c = DIContainer.create(C, b);
obj = DIContainer.create(MyObject, a, c); >>261は依存関係の定義がない場合
依存関係の定義情報があれば
MyObjectからそれに依存する情報はわかるので
内部で以下相当のことをやることが可能になる
a = DIContainer.create(A);
b = DIContainer.create(B);
c = DIContainer.create(C, b);
だから、これだけでインスタンスを生成できる
obj = DIContainer.create(MyObject);
（MyObjectがaとcが必要であることも依存関係の定義からわかる）
obj = new MyObject(); を
obj = DIContainer.create(MyObject); こう書けるようにするためには
依存関係の定義が重要だってことがわかるだろう これぐらいDIコンテナを自分で作ったことがあれば
わかると思うんだけどな。 > 内部で以下相当のことをやることが可能になる
内部っていうのは、DIContainer.create関数内部って話ね。
MyObjectやA、B、Cクラスのことではないぞ お前らコテハンつけろ、誰が誰に何言ってるのかわからん。
とくに皮肉っぽいこと言うやつと、
皮肉言われてるやつは、コテハン必須な。 アンチは分かりやすくドカタってコテハンつけると良いぞ >>262
＞obj = new MyObject(); を
＞obj = DIContainer.create(MyObject); こう書けるようにするためには
だからそれService Locator
依存を注入される側でDIContainerの参照持ってるから DIContainerとServiceLocatorの区別もついてないやつがDI DIって騒いでたってこと？ >>267
> 依存を注入される側でDIContainerの参照持ってるから
依存を注入される側ってどれのこと？
具体的にクラス名言って >>268
だろうね。
依存性を注入される側のコードなんて書いて無いのに
注入される側にDIContainerの参照があるとか
幻が見えてるようだしｗ >>268
> DIContainerとServiceLocatorの区別もついてないやつがDI DIって騒いでたってこと？
まさにそれがスレタイの狙い
DIとService Locatorの区別ができる、つまり違いを知ってる人は
Service Locatorはこう〜だけど、DIはこう〜とDIの本質を言うことができる
コンストラクタで依存しているオブジェクトを渡すという構造は
単に依存関係を分離した構造というだけで、依存関係を注入する方法を表していない
独立したオブジェクトをAssembler(組み立て係)として用意して注入する方法こそがDIなわけだよ
依存性の注入 = Dependency Injection なんだから >>272
GoFのデザインパターンにあるのはFactory MethodとAbstract Factoryであって
ファクトリーもコンテナもないので、そう聞かれても正確な答えにはならない
ファクトリー = オブジェクトを生成するもの
コンテナ = 何かの入れ物
っていうアバウトな定義でいいのであれば、その通りだが。
更に言うなら「ファクトリー＋コンテナ」には、インターフェースの実装を
生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が
抜けてるので「ファクトリー＋コンテナ＋依存関係の解決」がDIコンテナと言える。
これに実際のDIコンテナはAOPの機能がついてたりするんだがこっちはおまけだな >>271
Service Locatorにも組み立て係いるんだけど？ おまえがたひれば相対的に世界が滅亡したようなものだぞ。 >>280
俺から反物質が生成されるまで生きてみる 最後の話題がこれ
DIとService Locatorの区別もつ無いやつが
DIマンセーしてましたっと
274 返信：仕様書無しさん[sage] 投稿日：2018/07/12(木) 20:26:31.22
>>271
Service Locatorにも組み立て係いるんだけど？
275 自分：仕様書無しさん[sage] 投稿日：2018/07/12(木) 20:49:03.06
その組立係を何処から参照しているかの違いですね Service Locatorで検索したら
Service Locator パターンについて
https://qiita.com/tassi-yuzukko/items/a81a7b9aaa42198df689
という記事がトップに見つかり、そこから超参考になる記事として以下が紹介されていた
Service LocatorとDependency InjectionパターンとDI Container
http://www.nuits.jp/entry/servicelocator-vs-dependencyinjection
さすがちゃんとわかっている
> 利用箇所の結合度をさげる
> まずはServiceLocatorもDIも関係ない領域です。
> GeolocationServiceからIGeolocationServiceインターフェースを抽出して利用箇所の結合度を下げます。
インターフェースを使って結合度を下げるのはServiceLocatorでもDIでもないと
ちゃーんとわかっている
Service LocatorもDIも、依存関係を解決する方法で
そのやり方が違うものである インターフェースで結合度を下げる->SLもDIも関係ない
実装インスタンスをクラスの外部で生成して渡す-> DI
注意: つまりSLはDIではない
DIのための生成手順を管理->ファクトリー
ファクトリーの実装パターンの1つ->DIContainer これも忘れずに
GoFのデザインパターンにあるのはFactory MethodとAbstract Factoryであって
ファクトリーもコンテナもないので、そう聞かれても正確な答えにはならない
ファクトリー = オブジェクトを生成するもの
コンテナ = 何かの入れ物
っていうアバウトな定義でいいのであれば、その通りだが。
更に言うなら「ファクトリー＋コンテナ」には、インターフェースの実装を
生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が
抜けてるので「ファクトリー＋コンテナ＋依存関係の解決」がDIコンテナと言える。
これに実際のDIコンテナはAOPの機能がついてたりするんだがこっちはおまけだな デザインパターンは、プログラマの間で正確に意味を伝わるようにした
共通の用語なんだから当然。
それに対してファクトリーはデザインパターンではなく正確な用語じゃない
だから意味が正確に伝わらない。
それを言っておかないと、ファクトリーとDI が同一のものとか言い出しかねないからな。
ファクトリーにオブジェクトのコンテナと依存関係を解決したものがDI
通常ファクトリーといったらオブジェクトの生成ぐらいしか意味を持たない
（つまりコンテナ機能はないので毎回作成だし、依存関係の解決もしない） デザインパターンが実装まで定義してるなんて初耳だな。 実装を定義してるなんて書いてないが？
さっきから言葉の定義の話しかしてないよね？
ファクトリーはこうで、DIはこうって 設計だよなぁ。DIの実装なんて各フレームワークで全然違うし でも明らかに粒度が違うよなぁ
デザインパターンが基本設計なら、DIは詳細設計だろ？
なんで同じステージで語るの？ DI厨はこういう理屈であることがわかったなｗ
席は一つしかありません。
基本設計の椅子にデザインパターンが座りました
空きは詳細設計のみです。
だからDIは詳細設計になります。
詳細設計というのはプログラミングのことです。
プログラミングというのは実装です。
だからDIは実装になります
DIが何をやるかには興味がありません。
詳細設計しか椅子がないのだからDIは実装です UMLで言うところの、黒いひし形か白いひし形かの違いを
延々と言い合うスレって事でいい？ >>305
違うな。ひし形の色だけじゃない。
すべての形、その数、依存関係、まあ要するに
設計なんだが、それを言い合うスレだ デザインパターンが基本設計なら、DIも基本設計だろ？
同じステージの話なんだから どうみてって何を見たの？
見た実装とやらを言ってみて だから見た実装とやらを言ってみて
ま、答えずに逃げてる所みれば
どういうことか、わかりますけどねｗ お前が見た「実装」とやらを持って
上司に「実装」しました！って言ってこいよｗｗｗ >>312
は？
このスレのどこを見ても実装の話しかして無いだろw >>1に書いてあるだろ
■ DI（ゴミ）
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。 1つ言えるのはオブジェクト指向のなんかよりも
データ構造とアルゴリズムの方がよっぽど重要だということ。
昔はオブジェクト指向の勉強を頑張っていたけどそのときは
全然プログラミングがうまくならなかった。
現代の世の中はガチガチに設計されたライブラリを使って
コードを書くだけだから生半可なオブジェクト指向の知識なんて
ゴミ同然だよ。80年代90年代に考えられた思想とか、もうゴミに
なってしまった思想が多くて有害だよ。
結局現場でやることは「メソッドの使い方を求めてQiitaやStack OverFlowを
漁って成功するコードを見つけるまで疲れ果てる」ことに変わりはない。
せっかく勉強した内容が時代遅れで「裏切られる」ことのほうが多い。 一方、データ構造とアルゴリズムをガッツリと勉強してから
様々なデータ構造の使い方、問題の解決がうまくなった。
ブロックチェーンのアルゴリズムの理解や
データ分析の数学的演算がコーディング
できるようになってプログラミングが格段に楽しくなった。
スマートにオブジェクト指向で設計する力なんかより
「ゴリゴリとアルゴリズムを書く力」の方がよっぽど重要。
「再利用性」？「変更の影響」だって？そんなものゴミだね。
それは自分以外の人間のメリットのための技術であって、
自分へ還元されるためのメリットではない。
再利用性は自分の書いたコードなら信頼できるしコピペして使えばいい。
自分の書いたコードのコピペは全然ありだと思う。
適したメソッドが見つからなかったらQiitaを漁ったりせずに
自分でゼロから実装したほうが速い。
その場で手っ取り早くコードを生成しているから、
どんな既存コードにも頼っていないから俺の実装したコードは
依存性は低い。 天才が作ったライブラリないとお前何にもできないじゃん >>320-321
DIの話から逃げるなら、
こんなところにそのクソ文章をコピペしてないで
こっちに逃げ帰りな
データ構造,アルゴリズム,デザインパターン総合ｽﾚ 3©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1466315249/814
早速お前ボロクソに言われてるけどなｗ そんなにアルゴリズム好きなら
量子アルゴリズムでも探せば喜ばれるぞ diは無知なんだが、これは品質確保のための手法ってことで良いの？
未熟な奴に任せて設計させるとカオスな構造を生み出すから
分かってる奴があらかじめ枠組み組んでここでやれって言う奴？ 前提条件として、どんな開発場面を想定してんだろ？
このスレ見てても分かる通り、前提条件の共有も分からんのが多いだろ？
そのこと自体が、何かしらの標準や型が必要であることを示唆してるよね 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。 ■ このスレッドは過去ログ倉庫に格納されています
