TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
登録型派遣って有りですか？
【SE】結婚障害【PG】
プログラマに求められる資質が判明
コボラーのびっくりすること
14歳、発達障害の登校拒否ですが...1
初心者プログラマの雑談部屋
不登校でプログラミング勉強してる僕に助言してって
14歳、発達障害の登校拒否ですが...1
teratailもりあがっtail? 35問目
無能ほどよく席を立つ

ｵﾌﾞｼﾞｪｸﾄ指向、DIとService Locatorの違いを教えて4


1 ：2018/07/07 〜 最終レス ：2018/11/04
■ オブジェクト指向・デザインパターン（有用）
　
　わかり易い例
　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.2ch.sc/test/read.cgi/prog/1521869966/

オブジェクト指向を分かりやすく例えて教えてくれ 2
https://medaka.2ch.sc/test/read.cgi/prog/1525660302/

ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
https://medaka.2ch.sc/test/read.cgi/prog/1526733859/

2 ：
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コンテナ）がある

3 ：
https://msdn.microsoft.com/ja-jp/magazine/mt707534.aspx

サービス実装への参照がハードコーディングされる問題を解決するために用意されているのが、
DI による間接参照です。DI では、サービスのインスタンスを new 演算子で直接作成するのではなく、
クライアント (アプリケーション) はサービスのインスタンスを、サービス コレクションや「ファクトリ」に要求します。

4 ：
DIされるクラスはDIコンテナを直接利用しないようにしようね終わり

5 ：
だからDIコンテナの話がないのはDIじゃない

6 ：
正しいDIの説明をしている人たち

* https://www.martinfowler.com/articles/injection.html (本家本元DIという用語を作った人）
* http://kakutani.com/trans/fowler/injection.html


間違ったDIの説明をしている人たち晒し上げ（これから続々追加）

* https://qiita.com/sudachi808/items/364add4e96a8d6edc82b

7 ：
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:

8 ：
https://github.com/google/guice/wiki/GettingStarted

Guiceとの依存関係注入を始める方法。

入門
依存性注入の場合、オブジェクトはコンストラクタの依存関係を受け入れます。
オブジェクトを構築するには、まずその依存関係を構築します。しかし、
各依存関係を構築するには、その依存関係などが必要です。したがって、
オブジェクトを作成するときは、実際にオブジェクトグラフを作成する必要があります。

手作業でオブジェクトグラフを作成すると、労力がかかり、エラーが発生しやすくなり、
テストが困難になります。代わりに、Guiceはオブジェクトグラフを作成することができます。
しかし、まずGuiceは、あなたが望むように正確にグラフを構築するように構成する必要があります。

モジュールはインジェクタのビルディングブロックであり、Guiceのオブジェクトグラフビルダーです。
まず、インジェクタを作成し、それを使用して以下をビルドしBillingServiceます。

billingServiceを構築することで、Guiceを使って小さなオブジェクトグラフを構築しました。
グラフには、請求サービスとそれに依存するクレジットカードプロセッサとトランザクションログが含まれています。

9 ：
これは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);
　}
}

10 ：
このようなインジェクタを使ってインスタンスを作成するのが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);
　　...
}

11 ：
動機・・・なになにしたい
それをどうやって解決するかの一つの方法がDIパターンで
そのDIパターンは

　http://kakutani.com/trans/fowler/injection.html

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

12 ：
Assemblerを使う場合のDI
https://github.com/google/guice/wiki/Motivation#dependency-injection-with-guice

Assemblerを使わない場合のDI
https://github.com/google/guice/wiki/Motivation#dependency-injection

13 ：
Assemblerを使わない場合のDI（正確には手動のAssember）を
見てみるとわかると思うがすごく面倒で、
こんなことやってられない。

その批判を避けるためにDIパターンでは
DIコンテナを使うことが事実上の必須になっている。

14 ：
面倒だと書いた、手動の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);
　...
}

15 ：
単体テストでモックに差し替えるのにDIコンテナ使うの？

16 ：
>>15
結局の所、それがDIを使う目的になっちゃってる

で、モックに差し替えるためにDI使わなくてもできるなら
DIいらないよね？って話

そのためのツールがJavaだとMockitoとかEasyMockとかJMockitになる

モックにすげ替えることができるように設計レベルで歪めてしまうDIと違って
単純な設計のまま、モックにすげ替えることが可能になる

17 ：
前スレでストレージを他に変えるときDI使ってるという話忘れた？

18 ：
>>17
それは単なるストラテジーパターンを使えばいいだけの話で、
mainにずらずら依存関係書いたりする必要がないから
DIじゃなくていいんだよっていう話なの理解してないの？

19 ：
結局手動でやってるんだ
フレームワークで簡単にできるように用意されてるの使えばいいのに

20 ：
小さいものしか作ってないんだからいらんよ
mainに手動で書いていれば事足りる

21 ：
DIコンテナに登録しておけば自動でインジェクションしてくれたりするのに

22 ：
面倒やん、その定義書くの
DIコンテナ用のライブラリも必要になるし
そんな事するぐらいならもうDIなんていらねーってなる

23 ：
ですね。だからみんなDIはいらないって言ってる

24 ：
ドカタが無理して数学について語るスレはここですか？

25 ：
とりあえず 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

26 ：
>>24
言葉の定義の問題であって数学の話じゃないで
元のスレにお帰りください。

27 ：
DIは必須と言っていいぐらい有益だがDIコンテナは別にいらんな
Factoryを自分で書いたほうが柔軟で良い

28 ：
>>26
ドカタに数学は無理ですもんね
身の程を知るのは良いことですよ

29 ：
>>28
http://proofcafe.org/k27c8/math/math/set_theoryII/page/definition/

定義は大切！！
もう「定義」と「定理」とは、全くの別物であることは分かりましたね？
「定理」とは、命題の一種です。
一方「定義」とは「言葉決め」のことであり「命題」では決してございません。。。

30 ：
公理1: 無能に数学はできない
公理2: ドカタは無能である

定理: ドカタに数学はできない

証明:
ドカタに数学ができると仮定する。
すると公理1よりドカタは無能ではない。
しかしドカタが無能ではないとすると公理2と矛盾する。
ゆえにドカタに数学はできない。Q.E.D

31 ：
ようやく定義だと気づいたかｗ
ドカタをからかうのは楽しいな
またくるからよ。じゃあなｗ

32 ：
>>30
なんで公理（命題）が２つ出てきてるんだよｗ
お前、本当は数学わかってないだろ

33 ：
>>32
え？www

34 ：
>>30

> 定理: ドカタに数学はできない
> ゆえにドカタに数学はできない。Q.E.D

お前、定理（証明ずみなので、証明無しで使ってもいいはずのもの）を証明してるで？

35 ：
>>32
自然数の公理系（ペアノの公理）は5個の公理で成り立ってるよ

36 ：
>>33
公理=仮定なんだから
仮定をもとにもう一方の仮定を証明なんかできないって
マジレスしたらだめな流れ？

37 ：
>>34
その定理の証明だろw
そして定理には証明が必要だろ
ホント数学知らんのな

38 ：
>>36
公理は仮定じゃないよ
このスレに出てきた言葉で一番近いニュアンスなら定義

39 ：
>>37
仮定から証明をすることは不可能って話なんだけど
理解してる？

40 ：
>>39
>>38

41 ：
>>38
ふーん、そういう理屈で行くのなら
定義を証明して見せてっていうだけの話だけど

42 ：
定義の数学的証明まだかなー？ｗ

43 ：
定理ってのはさ、公理が真のときに真になる命題のことなんだよね
だから公理が成り立って証明がつく命題は真といえる

もちろん、全く別の公理を立てることもできて、数学では互いに矛盾するようないろんな公理系がある

44 ：
定義の数学的証明はやく！

45 ：
話逸れてるけど、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

46 ：
>>45
OK

47 ：
物理法則と矛盾した世界を定義することも出来るのが数学だから
ドカタが無能でない世界も定義できる。数学ならね

でもこのスレのドカタは無能だねw

48 ：
で、定義の数学的証明は？

49 ：
>>47
> 物理法則と矛盾した世界を定義することも出来るのが
なるほど、物理法則と矛盾した世界を定義したわけか

50 ：
男は俺だけの世界を定義して、

俺以外はみんな女、ハーレムじゃぁ
って感じかな？

ちょっと虚しいね

51 ：
>>49
そりゃ無能でないドカタもいるだろ実際には

でも、このスレのドカタは無能w

52 ：
ファウラーとかいうおじさんがこれがDIって言ってるだけだろ
真のDIがその定義であるかどうかはまた別の問題だな

53 ：
良く知りもしない数学的証明なんて言葉でマウント取ろうとしたヤツが悪い
誰だよ最初に言いだしたヤツ

54 ：
>>52
そのファウラーがDIという言葉を作り出したんだよｗ
正確には有識者の意見をまとめてDIという呼び方が適切であると同意をとったんだけどな
だからDIと言う言葉を使うなら生みの親のファウラーの定義に従わなければいけない

55 ：
なんだ。ファウラーがDIという言葉を定義した人か

56 ：
>>53
まあいいじゃん。いいおもちゃになってくれたしｗ

57 ：
>>54
ファウラーが生み出したということ
有識者が同意をとったこと
その同意が一般に認識されていて認められていること
ファウラーの定義に従わなければならないこと

この4つを数学的に証明して
できなきゃ嘘ってことだ

58 ：
>>57
定義なんで証明する必要なし
いい加減学習しろ

59 ：
お、今度のドカタは知恵をつけてきたじゃん

今度は「数学的証明さん」はどんなふうに対抗するのかな？ｗ

60 ：
有能なドカタ登場だな

61 ：
>>58
ファウラーが言ってるのはオレオレファウラーDIの定義な
真のDIの定義とオレオレファウラー定義が同一のものなのかはまだわからない
なのでファウラーの定義を引用して、真のDIとはこういうものである、と言うことはできない
ファウラーによると、オレオレファウラーDIとはこういうものである、ならば言って良い

62 ：
真のDIってなんだよｗｗｗｗ
お前の定義のDIが真のDIだとでも思ってんの？
それこそオレオレDIだろ

63 ：
> オレオレファウラーDI

ファウラーの時点でオレオレじゃないが？

64 ：
ファウラーの定義にはAssemblerについて「独立したオブジェクトをAssembler(組み立て係)として用意し」としか書いてないね

ってことはAssemblerが一つであることも、ましてや依存関係をひとまとめに定義することもDIに必須じゃないわけだ？

65 ：
>>64
図を見れば一つしかないことはわかる。
あと英語なら複数なら複数形になってるはず

66 ：
>>65
図には作られる側のクラスやインターフェースも一個しかないけど？

67 ：
マーチンファウラーって何を作った人？

68 ：
>>67
世界のソフトウェアの設計の基礎を作り上げた人

69 ：
この業界でマーチンファウラーを知らないとかモグリだろ

70 ：
>>68
へー、すごい人なんだね。

>>69
すまん。モグリやったｗ

71 ：
>>68
作ってないの？

72 ：
>>71
嫉妬すんなよｗ

73 ：
で？マーティン・ファウラーのDIの定義がそれとして、だからどうしたと？

74 ：
DIの定義を正しく知ってないと、DIの説明はできないってことでしょう？
オレオレDIの解説したってしょうがないし

75 ：
オレオレDIではない。俺が考える真のDIの説明である

76 ：
この世の他のどこにもない。俺だけの真のDIこそが。唯一正しいDIである

77 ：
つーか俺のほうがすごいだろ
マーチンファウラーなんかより

78 ：
いや、このハゲ、マジで何を作ったのかわからない
そもそも前線で働いてるのか？

79 ：
>>78
お前本読んだことある？
天才だよこの人

80 ：
数十年にわたってビジネスへのオブジェクト指向の適用に尽力する独立コンサルタント。
ヘルスケア、金融取引、企業財務などの分野におけるシステムのコンサル経験を持つ。
顧客にはクライスラー、シティバンク、英国民保健サービス、アンダーセン・コンサルティング、ネットスケープ・コミュニケーションズなどが名を連ねる
『リファクタリング 既存のコードを安全に改善する』より

81 ：
そんな凄い人が提唱したDIに
一介のドカタがケチ付けてるってホント？

82 ：
人として凄いかどうかはセオリーの正当性とは関係がないんだよね

83 ：
つまりマーチンファウラーが正しいとは限らないということは
俺が正しいってことになりませんか？

84 ：
それは暴論すぎるw

85 ：
別の惑星では違う定義で同じことやってるかもしれない
誰が決めたから正しいなんてのは文系的で馬鹿馬鹿しいか細い理だよ

86 ：
つまり他人は正しいとは限らない
俺のこと信じる気になりましたか？

87 ：
お前も他人

88 ：
DIアンチはファウラーを持ち上げたいの？貶したいの？

89 ：
DIアンチじゃねーし
ファウラーは尊敬してるが
DIとDIコンテナは別の話だ
それだけ

90 ：
んで？
工数削減なのか？
品質向上なのか？
どっちに効果あるの？
このハゲは

91 ：
>>88
マーチンファウラーを貶めることで
俺の言うことをが正しいと証明したい

92 ：
お前らハゲのいうことを聞くのか？

93 ：
ハゲだぞ、こいつハゲだぞ、俺はふさふさだ
ハゲと言うだけで、もう結論出てるだろ

94 ：
なんか仕組みを説明できた奴いないよね？

95 ：
ほら、いねーだろ。つまりどういうことか
俺が正しいってことになりませんか

96 ：
あなたが正しい
あなたは神だ

97 ：
お前がこの世界の髪だ

98 ：
マーチンファウラーを叩くことで自分の説得力を
あげようとする卑怯な手が失敗した今、こいつは何をする気だろうか？

99 ：
はい、茶番は終わりだ

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 ：
>>99
メリットが見えない


100〜のスレッドの続きを読む
給料比較　公務員＞ＳＥ＞ﾌﾟﾛｸﾞﾗﾏー
なぜ日本ではオープンソースが普及しないのか？
teratailもりあがっtail? 44問目
まともなプログラマってどのくらいの割合でいる？
んなもんさあ、grepしてsedしてawkすれば簡単じゃん
残業代出るってよく考えるとおかしいよな
◆個人事業主専門スレ50本目(法人立入禁止)◆
日本ユニシス
テストを軽視する者ども
フリーランスって早い話日雇いだろ？
--------------------
【縦笛】 リコーダー 総合 【part.2】
【TOX・TOX2】エリーゼマジ天使3【姫】
【PSP】バトマスMk.2 part2【cwc】
【メドレー】競泳日本代表リレー総合【フリー】
†桐朋中学校・高等学校† Part21
【赤坂アカ】かぐや様は告らせたい〜天才たちの恋愛頭脳戦〜 ☆462
宮崎県釣り情報8
普通に市販されてる加工食品でベジタリアンが食えそうなものを語るスレ
長野県の風景写真
【TDS】ビッグバンドビートの評価も下さい84【BBB】
1600ccの車ってなんで1500ccとして出さなかったの？たった100ccの違いで税金上がるんだが？
【柿】とことんクマの味方になるスレ３【大好き】
【北朝鮮船】「瀬取り」の疑い　海自護衛艦「はたかぜ」が東シナ海で確認[6/18]
ヌメロロジー/西洋数秘術
日刊スポーツ等の佐藤哲三の予想について ★14
【悲報】国民が嫌いなモノ一位は野球に決定！
【台鐵】台湾的鐵道模型　2次【高鐵】
イナズマイレブン　爆熱サッカーバトル
実質13852
【ボイメン】BOYS AND MEN 64【名古屋】
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼