ｵﾌﾞｼﾞｪｸﾄ指向、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 ■ このスレッドは過去ログ倉庫に格納されています
