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

1 ：仕様書無しさん：2018/07/07(土) 10:47:57.49 .net

■ オブジェクト指向・デザインパターン（有用）
　
　わかり易い例
　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/

2 ：仕様書無しさん：2018/07/07(土) 10:48:31.89 .net

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 ：仕様書無しさん：2018/07/07(土) 10:57:37.64 .net

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

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

4 ：仕様書無しさん：2018/07/07(土) 10:58:16.24 .net

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

5 ：仕様書無しさん：2018/07/07(土) 11:03:09.05 .net

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

6 ：仕様書無しさん：2018/07/07(土) 11:06:18.19 .net

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

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


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

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

7 ：仕様書無しさん：2018/07/07(土) 11:17:32.41 .net

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 ：仕様書無しさん：2018/07/07(土) 11:24:24.91 .net

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

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

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

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

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

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

9 ：仕様書無しさん：2018/07/07(土) 11:28:13.78 .net

これは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 ：仕様書無しさん：2018/07/07(土) 11:29:36.18 .net

このようなインジェクタを使ってインスタンスを作成するのが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 ：仕様書無しさん：2018/07/07(土) 11:31:38.36 .net

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

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

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

12 ：仕様書無しさん：2018/07/07(土) 11:31:48.23 .net

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 ：仕様書無しさん：2018/07/07(土) 11:34:23.44 .net

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

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

14 ：仕様書無しさん：2018/07/07(土) 11:37:00.20 .net

面倒だと書いた、手動の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 ：仕様書無しさん：2018/07/07(土) 11:39:46.57 .net

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

16 ：仕様書無しさん：2018/07/07(土) 11:45:13.85 .net

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

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

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

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

17 ：仕様書無しさん：2018/07/07(土) 11:57:18.64 .net

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

18 ：仕様書無しさん：2018/07/07(土) 11:58:20.59 .net

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

19 ：仕様書無しさん：2018/07/07(土) 12:24:04.12 .net

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

20 ：仕様書無しさん：2018/07/07(土) 12:41:45.09 .net

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

21 ：仕様書無しさん：2018/07/07(土) 12:44:28.79 .net

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

22 ：仕様書無しさん：2018/07/07(土) 13:13:55.89 .net

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

23 ：仕様書無しさん：2018/07/07(土) 15:37:14.44 .net

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

24 ：仕様書無しさん：2018/07/07(土) 15:40:55.85 .net

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

25 ：仕様書無しさん：2018/07/07(土) 15:42:21.15 .net

とりあえず 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 ：仕様書無しさん：2018/07/07(土) 15:43:32.63 .net

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

27 ：仕様書無しさん：2018/07/07(土) 15:44:10.89 .net

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

28 ：仕様書無しさん：2018/07/07(土) 15:44:54.36 .net

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

29 ：仕様書無しさん：2018/07/07(土) 15:45:32.65 .net

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

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

30 ：仕様書無しさん：2018/07/07(土) 15:51:23.00 .net

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

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

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

31 ：仕様書無しさん：2018/07/07(土) 15:51:25.87 .net

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

32 ：仕様書無しさん：2018/07/07(土) 15:52:38.12 .net

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

33 ：仕様書無しさん：2018/07/07(土) 15:53:16.19 .net

>>32
え？www

34 ：仕様書無しさん：2018/07/07(土) 15:55:47.59 .net

>>30

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

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

35 ：仕様書無しさん：2018/07/07(土) 15:56:54.26 .net

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

36 ：仕様書無しさん：2018/07/07(土) 15:57:46.39 .net

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

37 ：仕様書無しさん：2018/07/07(土) 15:57:52.36 .net

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

38 ：仕様書無しさん：2018/07/07(土) 15:59:33.60 .net

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

39 ：仕様書無しさん：2018/07/07(土) 16:00:02.98 .net

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

40 ：仕様書無しさん：2018/07/07(土) 16:00:36.35 .net

>>39
>>38

41 ：仕様書無しさん：2018/07/07(土) 16:01:01.64 .net

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

42 ：仕様書無しさん：2018/07/07(土) 16:01:49.95 .net

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

43 ：仕様書無しさん：2018/07/07(土) 16:03:54.46 .net

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

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

44 ：仕様書無しさん：2018/07/07(土) 16:04:13.50 .net

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

45 ：仕様書無しさん：2018/07/07(土) 16:05:22.44 .net

話逸れてるけど、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 ：仕様書無しさん：2018/07/07(土) 16:05:59.87 .net

>>45
OK

47 ：仕様書無しさん：2018/07/07(土) 16:08:08.71 .net

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

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

48 ：仕様書無しさん：2018/07/07(土) 16:09:36.13 .net

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

49 ：仕様書無しさん：2018/07/07(土) 16:15:57.41 .net

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

50 ：仕様書無しさん：2018/07/07(土) 16:17:12.38 .net

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

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

ちょっと虚しいね

51 ：仕様書無しさん：2018/07/07(土) 16:18:36.41 .net

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

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

52 ：仕様書無しさん：2018/07/07(土) 16:19:17.66 .net

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

53 ：仕様書無しさん：2018/07/07(土) 16:20:42.61 .net

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

54 ：仕様書無しさん：2018/07/07(土) 16:21:13.40 .net

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

55 ：仕様書無しさん：2018/07/07(土) 16:22:57.98 .net

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

56 ：仕様書無しさん：2018/07/07(土) 16:24:47.75 .net

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

57 ：仕様書無しさん：2018/07/07(土) 16:25:42.27 .net

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

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

58 ：仕様書無しさん：2018/07/07(土) 16:26:20.52 .net

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

59 ：仕様書無しさん：2018/07/07(土) 16:27:31.44 .net

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

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

60 ：仕様書無しさん：2018/07/07(土) 16:28:00.61 .net

有能なドカタ登場だな

61 ：仕様書無しさん：2018/07/07(土) 16:29:07.53 .net

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

62 ：仕様書無しさん：2018/07/07(土) 16:30:09.70 .net

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

63 ：仕様書無しさん：2018/07/07(土) 16:30:53.87 .net

> オレオレファウラーDI

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

64 ：仕様書無しさん：2018/07/07(土) 16:32:45.55 .net

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

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

65 ：仕様書無しさん：2018/07/07(土) 16:33:14.35 .net

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

66 ：仕様書無しさん：2018/07/07(土) 16:35:47.87 .net

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

67 ：仕様書無しさん：2018/07/07(土) 16:39:11.21 .net

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

68 ：仕様書無しさん：2018/07/07(土) 16:42:22.02 .net

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

69 ：仕様書無しさん：2018/07/07(土) 16:43:53.06 .net

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

70 ：仕様書無しさん：2018/07/07(土) 16:45:23.08 .net

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

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

71 ：仕様書無しさん：2018/07/07(土) 17:01:34.33 .net

>>68
作ってないの？

72 ：仕様書無しさん：2018/07/07(土) 17:28:24.74 .net

>>71
嫉妬すんなよｗ

73 ：仕様書無しさん：2018/07/07(土) 17:56:44.64 .net

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

74 ：仕様書無しさん：2018/07/07(土) 18:03:22.11 .net

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

75 ：仕様書無しさん：2018/07/07(土) 18:05:31.04 .net

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

76 ：仕様書無しさん：2018/07/07(土) 18:06:38.22 .net

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

77 ：仕様書無しさん：2018/07/07(土) 18:51:31.87 .net

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

78 ：仕様書無しさん：2018/07/07(土) 19:09:59.29 .net

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

79 ：仕様書無しさん：2018/07/07(土) 19:27:59.48 .net

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

80 ：仕様書無しさん：2018/07/07(土) 19:41:38.54 .net

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

81 ：仕様書無しさん：2018/07/07(土) 19:51:05.32 .net

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

82 ：仕様書無しさん：2018/07/07(土) 19:53:40.39 .net

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

83 ：仕様書無しさん：2018/07/07(土) 20:02:47.41 .net

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

84 ：仕様書無しさん：2018/07/07(土) 20:05:26.78 .net

それは暴論すぎるw

85 ：仕様書無しさん：2018/07/07(土) 20:08:47.35 .net

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

86 ：仕様書無しさん：2018/07/07(土) 20:13:13.14 .net

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

87 ：仕様書無しさん：2018/07/07(土) 20:13:54.88 .net

お前も他人

88 ：仕様書無しさん：2018/07/07(土) 20:19:26.22 .net

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

89 ：仕様書無しさん：2018/07/07(土) 20:20:36.25 .net

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

90 ：仕様書無しさん：2018/07/07(土) 20:27:50.48 .net

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

91 ：仕様書無しさん：2018/07/07(土) 20:33:38.39 .net

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

92 ：仕様書無しさん：2018/07/07(土) 20:34:00.88 .net

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

93 ：仕様書無しさん：2018/07/07(土) 20:34:29.00 .net

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

94 ：仕様書無しさん：2018/07/07(土) 20:35:30.51 .net

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

95 ：仕様書無しさん：2018/07/07(土) 20:39:33.40 .net

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

96 ：仕様書無しさん：2018/07/07(土) 20:53:02.22 .net

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

97 ：仕様書無しさん：2018/07/07(土) 20:56:14.92 .net

お前がこの世界の髪だ

98 ：仕様書無しさん：2018/07/07(土) 21:16:09.29 .net

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

99 ：仕様書無しさん：2018/07/07(土) 21:33:00.43 .net

はい、茶番は終わりだ

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 ：仕様書無しさん：2018/07/07(土) 21:55:36.65 .net

>>99
メリットが見えない

101 ：仕様書無しさん：2018/07/07(土) 21:56:50.89 .net

>>100
メリットの話ではない。DIのちゃんとした定義を明確にしてるだけだ

102 ：仕様書無しさん：2018/07/07(土) 22:35:31.73 .net

>>101
その定義が正しいという証明がない
おっさんが勝手に定義だっていってるだけ

103 ：仕様書無しさん：2018/07/07(土) 22:47:30.00 .net

>>102
ドカタが証明とかの言葉を使うなって言ってんだろ
無能を自覚しろ

104 ：仕様書無しさん：2018/07/07(土) 23:24:29.60 .net

ファウラーの定義で何か問題あるの？

105 ：仕様書無しさん：2018/07/07(土) 23:32:25.33 .net

>>104
ハゲでどうしても致命的なエラーが出る

106 ：仕様書無しさん：2018/07/08(日) 05:30:00.74 .net

>>104
すごく困る。ファウラーの定義とは違うことを言ってるから

107 ：仕様書無しさん：2018/07/08(日) 08:42:54.33 .net

>>99に何か問題が？

108 ：仕様書無しさん：2018/07/08(日) 08:45:43.22 .net

>>104
問題はないがDIコンテナが必須というのは正確ではない
というだけの話

109 ：仕様書無しさん：2018/07/08(日) 08:48:57.07 .net

必須じゃなくてもDIコンテナを使わないと
手動でDIコンテナ相当のことをしないといけないのでもっと大変
だから開発効率上、DIコンテナを使うのは必須

110 ：仕様書無しさん：2018/07/08(日) 09:21:13.07 .net

リポジトリでオブジェクトを作るときってDIコンテナ使う？

111 ：仕様書無しさん：2018/07/08(日) 09:27:22.19 .net

>>109
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？

112 ：仕様書無しさん：2018/07/08(日) 09:46:40.70 .net

ファウラーの定義にはこう書かれています

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

113 ：仕様書無しさん：2018/07/08(日) 09:48:05.12 .net

つまり

独立したオブジェクトをAssembler(組み立て係)として用意します
MovieFinder インタフェースの実装をMovieLister クラスのフィールドへ適切に設定させまます。
これがDependency Injection の基本的な考え方です

114 ：仕様書無しさん：2018/07/08(日) 09:51:40.62 .net

もうね既存の用語を違う意味で使ってる時点でダメダメなんだよな。

115 ：仕様書無しさん：2018/07/08(日) 10:24:14.09 .net

既存の用語っていのなら、DependencyもInjectionも
英語なわけで、昔からあった用語
だから、ファウラーが勝手に定義して言い訳がない
人それぞれのDependency Injectionというのがある
俺のDependency Injectionは俺だけのものだ
他人が勝手に決めつけていいものではない

116 ：仕様書無しさん：2018/07/08(日) 10:29:50.73 .net

>>113
じゃあmain()の中でインジェクションして回っても、main()が何かのオブジェクトに属する言語なら

main()を持つオブジェクト = Assembler(組み立て係)

という解釈が成立するからファウラーのDIになるね

117 ：仕様書無しさん：2018/07/08(日) 10:31:08.86 .net

>>116
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？

118 ：仕様書無しさん：2018/07/08(日) 10:34:43.11 .net

>>117
>>109は「もっと大変」とかいう感想を語ってるけど
>>116はどこが感想なの？

119 ：仕様書無しさん：2018/07/08(日) 10:36:41.69 .net

>>115
ファウラーのDIが一般的
https://msdn.microsoft.com/ja-jp/magazine/mt707534.aspx
https://github.com/google/guice/wiki/Motivation#dependency-injection-with-guice

120 ：仕様書無しさん：2018/07/08(日) 10:37:13.42 .net

勝手な解釈するなってことですよ
解釈はファウラーが言った言葉ではない

121 ：仕様書無しさん：2018/07/08(日) 10:37:44.79 .net

>>119
うっせー、みとめん
コンストラクタにオブジェクトを指定したら
それはDI

122 ：仕様書無しさん：2018/07/08(日) 10:39:21.69 .net

ファウラーはハゲだ。それだけで疑うのに十分だろ。はい論破

123 ：仕様書無しさん：2018/07/08(日) 10:40:25.89 .net

>>120
ファウラーの定義にDIコンテナなんて言葉は出てこないので
DIコンテナ必須なんて勝手な解釈するなってことですね、わかります

124 ：仕様書無しさん：2018/07/08(日) 10:45:22.43 .net

独立したオブジェクトが必要とは書いてあるね

125 ：仕様書無しさん：2018/07/08(日) 10:48:20.83 .net

>>121
なら上のリポジトリにissue上げてみて

126 ：仕様書無しさん：2018/07/08(日) 12:34:07.90 .net

>>124
だから何？

127 ：仕様書無しさん：2018/07/08(日) 12:53:57.42 .net

>>126
言葉遊びだってこと

128 ：仕様書無しさん：2018/07/08(日) 12:58:52.27 .net

ＤＩについて一番まともな事書いてある本ってどれでしょうか？

129 ：仕様書無しさん：2018/07/08(日) 13:02:06.08 .net

>>128
AmazonでDependency Injectionで検索した？

130 ：仕様書無しさん：2018/07/08(日) 13:49:26.30 .net

>>127
つまり、ファウラーの定義に従え！って何度もコピペしてたDIアンチ自身が
ファウラーの定義を勝手に解釈して歪めてたってことね

131 ：仕様書無しさん：2018/07/08(日) 16:20:09.56 .net

ヤフーのブログのサイトで初心者にはわかりやすいブログを発見したよ。
https://blogs.yahoo.co.jp/kamyu_2010/35417803.html

132 ：仕様書無しさん：2018/07/08(日) 17:07:13.23 .net

>>131
またお前か自演？

133 ：仕様書無しさん：2018/07/08(日) 18:23:51.57 .net

デコレーター使いたいなぁとかパラメーターで分岐する生成したいなぁとか細かく制御しようとするとDIコンテナじゃ物足りないんだよね
コンテナに登録するのとファクトリー書くのじゃ手間に大差ないし
DIは便利だけどDIコンテナとないうゴミパターンを必須にされたら困るよ

134 ：仕様書無しさん：2018/07/08(日) 18:31:04.30 .net

>>133
DIってそういうときに使うもんじゃないし。
基本的にアプリケーション内でインスタンスが一つしか
必要ないときだけ使用する
ウェブアプリのように独立したセッションがある場合
そのセッションごとに使用することもある

135 ：仕様書無しさん：2018/07/08(日) 18:34:53.00 .net

そういう説明って公式に書いてあったりする？

136 ：仕様書無しさん：2018/07/08(日) 18:46:10.73 .net

ないけど、事実上そうだよ。
でないとサービスロケーターになってしまう

DIパターンにおけるインスタンスを生成するオブジェクト（通常DIコンテナ）に
依存せずにインスタンスを生成するには、上の層でインスタンスを生成してもらわないといけない
上の層っていうのはフレームワークに隠蔽されたアクションに相当する処理の開始部分

「DIパターンにおけるインスタンスを生成するオブジェクト」を上の層以外の
部分で使うことは、それに依存してしまうことになってしまい、
それは事実上サービスロケーターと同じことになる

137 ：仕様書無しさん：2018/07/08(日) 18:57:27.02 .net

>>135
明示的にスコープ指定するから当たり前じゃない？

138 ：仕様書無しさん：2018/07/08(日) 19:08:44.71 .net

>>136

> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。

https://kakutani.com/trans/fowler/locator.gif

MovieLister から ServiceLocator への参照が発生するのがサービスアロケータだろ
ファウラーの定義を勝手に解釈するの止めてもらえませんかね？

139 ：仕様書無しさん：2018/07/08(日) 19:58:38.85 .net

>>134
DIの仕事だよ
デコレーターなんてまさにDIコンテナがよしなに処理してくれるべき仕事だし
パラメーターはよくあるパターンだとデータベースの接続先だけが異なる場合などに必要
そもそもアプリにインスタンスが1つなら全部シングルトンになってしまうが一般的なDIコンテナの設計はそんな風にはなってない
あくまでシングルトンは特別な場合

140 ：仕様書無しさん：2018/07/08(日) 19:59:53.61 .net

>>138
MovieLister から ServiceLocatorを使わずに、
何かしらのインスタンスを作成するにはどうすればいい？
newならもちろん普通にできる。だけどnewではDIにならない

141 ：仕様書無しさん：2018/07/08(日) 20:00:47.64 .net

>>139
> デコレーターなんてまさにDIコンテナがよしなに処理してくれるべき仕事だし
いや、むり。DIコンテナから複数のインスタンスを生成する方法がない

142 ：仕様書無しさん：2018/07/08(日) 20:01:14.00 .net

>>139
> パラメーターはよくあるパターンだとデータベースの接続先だけが異なる場合などに必要

そのように、最初に一回やってしまえばOKみたいなものにしか使えない

143 ：仕様書無しさん：2018/07/08(日) 20:04:35.58 .net

このスレ勉強になる

144 ：仕様書無しさん：2018/07/08(日) 20:17:40.56 .net

>>39
http://eroolove.chuko.net/2018/04/24226

エロいお姉さんｗｗｗｗｗｗｗｗvvｗｗｗｗvvｗｗｗｗｗ

145 ：仕様書無しさん：2018/07/08(日) 20:19:09.61 .net

>>139
> そもそもアプリにインスタンスが1つなら全部シングルトンになってしまうが一般的なDIコンテナの設計はそんな風にはなってない
> あくまでシングルトンは特別な場合
だから独立したセッションがある場合はセッションごとって書いたろ？

セッション単位とかスレッド単位とか他と独立した処理が
フレームワークなどから開始される場合、その単位で一つ作成されることはあるよ
セッション単位のシングルトンみたいな
だけど一つのクラスやメソッドでインスタンスを複数生成して使うような場合には使えない。

146 ：仕様書無しさん：2018/07/08(日) 20:21:40.82 .net

>>141
DIコンテナはファクトリの下位互換ってことか

147 ：仕様書無しさん：2018/07/08(日) 20:23:48.57 .net

>>145
やっぱ使いにくいな
DIコンテナよりファクトリの方が柔軟で便利だな
やっぱりDIコンテナは不要なんじゃないか？

148 ：仕様書無しさん：2018/07/08(日) 20:30:29.16 .net

DIコンテナってさインフラへの依存を断ち切ろうってコンセプトに喧嘩売ってるよな
他サービスへの依存は切れるけどDIフレームワークそのものにべったり依存してしまう
Javaのプログラムを.net coreに移植しようとしたらなんか全部のクラスに@Injectとか書いてあんの
普通にFactoryを作ればいいじゃんっての
ほんとDIコンテナってバカみたいだよな

149 ：仕様書無しさん：2018/07/08(日) 20:32:24.62 .net

>>148
.NET CoreこそフレームワークレベルでDIフル活用してるだろ

150 ：仕様書無しさん：2018/07/08(日) 20:41:08.67 .net

>>147
そもそも使う目的がシステムの何かの機能を実現するために必要だからじゃなくて
DI使っていればクラスに依存せずにインターフェースだけに依存すれば良くなるし、
だから同じインターフェースの違う実装に入れ替え可能
そうしておけば、後々便利なこともあるじゃない？みたいな
今それいらないよね？って突っ込まれること請け合いだからねｗ
クラスを入れ替えたいだけなら、ソースコードを修正すれば十分なのさ

DIは生成するクラスをアプリの実行状態に応じて柔軟に変更可能なものなんかじゃなくて、
生成するクラスを実行の初期化時に決められるってだけだからね

151 ：仕様書無しさん：2018/07/08(日) 20:43:00.93 .net

>>140
https://kakutani.com/trans/fowler/injection.html#ConstructorInjectionWithPicocontainer

コンストラクタで渡せば良いってファウラーが言ってるよ

152 ：仕様書無しさん：2018/07/08(日) 20:43:49.16 .net

>>149
DIはいいんだよ別に
DIコンテナ(asp.net coreだとServiceCollectionだが)を強制されるのがダメ
まあMicrosoftはまだ@Injectみたいなロックインのための仕組みを盛り込まないだけマシだけど
DIコンテナの制約を意識してオブジェクトモデル設計を変えなきゃいけない場面が時々ある

DIコンテナの罪は大きい
DIそのものは便利で合理的なのにね
DIコンテナがすべてを台無しにしてる
自由が約束されたファクトリーを使うべき

153 ：仕様書無しさん：2018/07/08(日) 20:45:46.85 .net

>>150
違う違う
DIは、じゃなくて、DIコンテナは、な
ここ重要な
DIは必要だけどDIコンテナは邪魔

154 ：仕様書無しさん：2018/07/08(日) 20:47:25.86 .net

>>151
そうすると、コンストラクタで渡す部分が、
特定のクラスに依存してしまう

そうやって特定のクラスに依存するものが
あちこちにできてしまうと、本末転倒になってしまうから、
DIでは、依存関係を定義する部分をひとまとめにして
そこだけは諦めてクラス名をずらずら書くんだよ。

155 ：仕様書無しさん：2018/07/08(日) 20:48:43.32 .net

>>153
DIコンテナを使わないで、手動でDIコンテナの代わりの
コードを書くと、大変なことになるぞ。
メンテナンス性が極端に落ちる

156 ：仕様書無しさん：2018/07/08(日) 21:09:50.58 .net

>>154
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？

157 ：仕様書無しさん：2018/07/08(日) 21:13:14.96 .net

もっとバカにもわかるように議論してくれ

158 ：仕様書無しさん：2018/07/08(日) 21:14:25.18 .net

>>156
いや事実

コンストラクタで渡す場合、以下のように
ClassAはClassBやClassCに依存してしまう

Class A {
　foo() {
　　ClassB b = new ClassB();
　　ClassC c = new ClassC(b);
　}
}

159 ：仕様書無しさん：2018/07/08(日) 21:14:31.06 .net

>>155
アンチはDIコンテナだとカバーできない部分があるから、ファクトリを使うんだってさ

160 ：仕様書無しさん：2018/07/08(日) 21:19:12.80 .net

>>157
了解
もちろんこのようにすればClassBにもClassCにも依存しないが
今度は、DIContainerに依存してしまう。

Class A {
　foo() {
　　IC c = DIContainer.create("ClassC");
　}
}


これがそもそもService LocatorでDIContainer
（という名前にしているが実際はServiceLocatorとすべき）
に依存しないようにしたほうがDI

161 ：仕様書無しさん：2018/07/08(日) 21:19:36.16 .net

>>152
Microsoftも@inject使ってることすら知らないお馬鹿さん

162 ：仕様書無しさん：2018/07/08(日) 21:20:19.53 .net

>>159
> アンチはDIコンテナだとカバーできない部分があるから、ファクトリを使うんだってさ

うん。ファクトリだとDIみたいに依存関係をひとまとめにする部分はないので
メンテナンス性は下がらない。ファクトリは関連するものだけを生成するのでね

163 ：仕様書無しさん：2018/07/08(日) 21:24:13.81 .net

>>152
ばーか
https://docs.microsoft.com/en-us/aspnet/core/mvc/views/dependency-injection?view=aspnetcore-2.1

164 ：仕様書無しさん：2018/07/08(日) 21:24:41.41 .net

>>155
全然落ちんよ
むしろファクトリーのほうが保守性が高い
生成箇所が明確で書いてあることを読めばそれで理解できるから

165 ：仕様書無しさん：2018/07/08(日) 21:25:42.22 .net

>>163
小学生？

166 ：仕様書無しさん：2018/07/08(日) 21:26:00.64 .net

>>158
ファウラーが定義してるかどうか聞いてるんですけど？
いつもみたいに引用してくださいよ

167 ：仕様書無しさん：2018/07/08(日) 21:28:06.71 .net

>>165
せやで

168 ：仕様書無しさん：2018/07/08(日) 21:31:55.83 .net

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

169 ：仕様書無しさん：2018/07/08(日) 21:32:33.62 .net

>>164
> むしろファクトリーのほうが保守性が高い
そりゃDIは保守性低いんで、
必要な部分にファクトリー使いましょうと
言ってるんだから当然だなｗ

170 ：仕様書無しさん：2018/07/08(日) 21:36:17.46 .net

ちなみにDIの保守性の悪さを示す例
誰か有名でそれなりの規模のものを知ってると嬉しいんだが、
まあ適当に見つけてきた

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/applicationContext.xml

DIコンテナを使わない場合でも、これ相当のことをコードで書く必要がある。

171 ：仕様書無しさん：2018/07/08(日) 21:36:49.87 .net

リンク先見ない気がするんでコピペしてみるｗ

<?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"/>

172 ：仕様書無しさん：2018/07/08(日) 21:37:07.83 .net

<!-- 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"/>
-->

173 ：仕様書無しさん：2018/07/08(日) 21:38:13.99 .net

<!--
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"/>

174 ：仕様書無しさん：2018/07/08(日) 21:38:49.57 .net

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

175 ：仕様書無しさん：2018/07/08(日) 21:39:14.68 .net

>>168
コンストラクタで設定しちゃダメって書いてないどころか、
コンストラクタインジェクションの例すら書いてあるんですがw

176 ：仕様書無しさん：2018/07/08(日) 21:39:32.86 .net

ここいらで止めといてあげるが、まだ半分ｗ

177 ：仕様書無しさん：2018/07/08(日) 21:40:39.93 .net

>>175
コンストラクタで設定したらだめなんて
一言も言ってないけど？
思い込みで発言すんなや

178 ：仕様書無しさん：2018/07/08(日) 21:43:15.80 .net

>>177
じゃあ>>140への回答はコンストラクタで設定すれば良い、でFAだな

コンストラクタで渡せばDIコンテナなんて不要なことすら分からないなんてお前はホントにアホだなw

179 ：仕様書無しさん：2018/07/08(日) 21:47:59.56 .net

DIの使われ方を見ると依存関係がどうこうというより、
クラスに対する設定を記述しているだけな気がするな

180 ：仕様書無しさん：2018/07/08(日) 21:50:34.12 .net

なんでアンチは自分が考えたオレオレDIをファウラーのDIみたいに言うの？
もっと提唱者に敬意を払うべきでは？

181 ：仕様書無しさん：2018/07/08(日) 21:51:14.33 .net

オブジェクト指向にしろＤＩにしろ
実際に困ったことありました→ある手法を使ったことでこんなに便利になりました
ってことが明確にわかる実例がないから悪いんだよね
xmlのこのクソなげえ設定ファイルが必要ですがそれを補って有り余る程DIには利点があり
こんなに便利になりましたってのが１ミリもわからない
そこら編を死ぬほど詳しく書いた本とか売れそうな気もするんだけど誰も書かないな

182 ：仕様書無しさん：2018/07/08(日) 21:51:21.18 .net

>>178
> じゃあ>>140への回答はコンストラクタで設定すれば良い、でFAだな

コンストラクタで設定するのはnew相当を行うときだ。
質問はnew相当のことをどうやって行うかだ

俺なら、インスタンスの作成をするにはどうすればいい？の答えに
new演算子を使用すると答えるが、
お前は、コンストラクタで設定すればいいって答えるのか？
回答が意味不明だぞ

183 ：仕様書無しさん：2018/07/08(日) 21:51:20.69 .net

ハゲは何つってるの？

184 ：仕様書無しさん：2018/07/08(日) 21:53:01.50 .net

>>181
実際は新しい言葉作ってバカなPGを手玉に取ってお金を集めちゃう商売だからそんな資料は作れないよ

185 ：仕様書無しさん：2018/07/08(日) 21:53:33.94 .net

>>183
それが大事だよね
ここのドカタが何言ってるかよりも

186 ：仕様書無しさん：2018/07/08(日) 21:54:32.74 .net

>>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は解決する問題がなくて、
依存関係を分離しておけば、将来なにかの役に立つでしょ？になってる

187 ：仕様書無しさん：2018/07/08(日) 22:02:25.42 .net

>>182
もともとは>>138の

> MovieLister から ServiceLocator への参照が発生するのがサービスアロケータだろ

に対して、>>140が参照持たないためにはnewするしかないって言ってる

で、その回答として

コンストラクタで渡せばMovieLister から ServiceLocator への参照が発生しません

って言ってるわけ。何が意味不明なの？

188 ：仕様書無しさん：2018/07/08(日) 22:04:07.09 .net

要するに>>136は間違いってことね

189 ：仕様書無しさん：2018/07/08(日) 22:04:51.15 .net

>>181
xmlとかいつの時代ですか？

190 ：仕様書無しさん：2018/07/08(日) 22:06:45.43 .net

>>152
アンチはこの程度かｗｗｗ

191 ：仕様書無しさん：2018/07/08(日) 22:19:21.85 .net

>>187
> コンストラクタで渡せばMovieLister から ServiceLocator への参照が発生しません

だからその場合、どうやってインスタンスを作成するのかって話をしてるんだが？
お前はインスタンス作成後の話しかしてねーじゃねーか
わざとか？


ちゃんと話を読め↓

> ないけど、事実上そうだよ。
> でないとサービスロケーターになってしまう
>
> DIパターンにおけるインスタンスを生成するオブジェクト（通常DIコンテナ）に
> 依存せずにインスタンスを生成するには、上の層でインスタンスを生成してもらわないといけない
> 上の層っていうのはフレームワークに隠蔽されたアクションに相当する処理の開始部分
>
> 「DIパターンにおけるインスタンスを生成するオブジェクト」を上の層以外の
> 部分で使うことは、それに依存してしまうことになってしまい、
> それは事実上サービスロケーターと同じことになる

192 ：仕様書無しさん：2018/07/08(日) 22:22:31.15 .net

>>191
サービスアロケータになってしまうと言うのは貴方の感想であって
ファウラーの定義では参照がなかったらサービスアロケータではありません

193 ：仕様書無しさん：2018/07/08(日) 22:23:25.10 .net

>>189
いいのか、その話をして？

依存関係を一箇所に書くんじゃなくて、
今は各クラスにアノテーションとして書きましょう
に変わったって言いたいんだろう？

194 ：仕様書無しさん：2018/07/08(日) 22:24:51.24 .net

>>192
残念ながら事実だよ。
手動でnewしてしまうと、依存関係の定義情報が使用できない

195 ：仕様書無しさん：2018/07/08(日) 22:27:02.53 .net

>>194
なんでファウラーの定義を離れて勝手なオレオレDIの話をするの？

196 ：仕様書無しさん：2018/07/08(日) 22:27:30.06 .net

>>194
それはファウラーの定義と関係ないよね

197 ：仕様書無しさん：2018/07/08(日) 22:31:30.46 .net

DIコンテナが無くてもDIできる、でFA？

198 ：仕様書無しさん：2018/07/08(日) 22:32:14.64 .net

>>195-196
はい？ DIの話なんかしてませんよ？
DIにならないって話をしてるんですが

この場合、DIの定義である↓を満たせない

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

DIじゃない方を使いましょうって言ってるんでしょ？

199 ：仕様書無しさん：2018/07/08(日) 22:32:59.99 .net

DIコンテナが無くてもDIできる。
ただしメンテナンス性が大きく下がる

200 ：仕様書無しさん：2018/07/08(日) 22:34:25.00 .net

>>199
DIコンテナが無くてもDIできる、でFAね
良かった良かった

201 ：仕様書無しさん：2018/07/08(日) 22:35:07.84 .net

そりゃオレオレDIコンテナを作ればできるだろうけど、
こいつ何を言ってるんだろう？

202 ：仕様書無しさん：2018/07/08(日) 22:37:03.26 .net

ファウラーのDIをドカタが勝手に独自解釈してるから正しただけだが？
提唱者には敬意を払わないとね

203 ：仕様書無しさん：2018/07/08(日) 22:38:07.70 .net

>>201
オレオレDIコンテナって何それ？
ファウラーの定義に出てきますか？

204 ：仕様書無しさん：2018/07/08(日) 23:11:01.67 .net

>>193
ｗｗｗ

205 ：仕様書無しさん：2018/07/08(日) 23:19:03.24 .net

>>193
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1

206 ：仕様書無しさん：2018/07/09(月) 08:52:36.11 .net

そうだ！Factoryが生成するインスタンスのClassを、設定ファイルに記述するようにしたらいいんじゃないかな？

207 ：仕様書無しさん：2018/07/09(月) 09:18:47.02 .net

そもそもクラス構成なんかそうそう変えないだろ？

208 ：仕様書無しさん：2018/07/09(月) 10:50:12.45 .net

DIコンテナもxml設定ファイルもウンコ言語Javaが産んだドカタ文化だろ
Javaのゴミさを理由にDIを貶めてんじゃねーよ

209 ：仕様書無しさん：2018/07/10(火) 06:59:02.50 .net

services.AddTransient<IUnko>(c =>
new LogDecorator(
new TransactionScopeDecorator(
new IOValidationDecorator(
new UnkoImpl(c => c.GetService<IDepend1>(),
c.GetService<IDepend2>(),
...
))));

DIコンテナを使うとこんな馬鹿みたいな定義がずらずらと並んでしまう
これはもはやXMLより酷い
こんなんならファクトリークラスとして責務分割したほうがマシ
DIコンテナはおぞましく巨大な泥団子そのもの
オブジェクト指向信者が使っていいものじゃない

210 ：仕様書無しさん：2018/07/10(火) 07:51:34.10 .net

DIコンテナと言うよりDecorator

211 ：仕様書無しさん：2018/07/10(火) 08:14:56.54 .net

>>209
Factoryで責務分割すると、どういうこーどになるの？

212 ：仕様書無しさん：2018/07/10(火) 08:15:21.22 .net

>>209
妄想おつ

213 ：仕様書無しさん：2018/07/10(火) 08:21:14.51 .net

知ったかアンチ

214 ：仕様書無しさん：2018/07/10(火) 20:03:09.78 .net

>>211
> Factoryで責務分割すると、どういうこーどになるの？
違う違う。Factoryで責務分割するのではない

依存関係を外部から注入するから、こういう結果になるということなんだから
依存関係を埋め込むことで、シンプルになる。

依存関係を埋め込んでるだけでSOLID原則を破るわけではないので問題はない
（SOLID原則には依存関係を埋め込んではいけないなどという原則は無い）

またFactoryを使うなって話でもない。設計上必要な場所にはFactoryを使う
単に依存関係を分離するためにDIだかFactoryだかを使わないって話

215 ：214：2018/07/10(火) 20:03:50.30 .net

俺は>>209ではないので念の為

216 ：仕様書無しさん：2018/07/10(火) 23:16:15.34 .net

スマンちょっと研究したらDecoratorふつうに出来たわ
DIコンテナは神。ファクトリーはゴミという結果になってしまった

217 ：仕様書無しさん：2018/07/10(火) 23:28:22.82 .net

>>214
それが209の言おうとしたこと？

218 ：仕様書無しさん：2018/07/11(水) 01:09:38.82 .net

>>216
どうやって？ DIではDecoratorはできないはずだけど？

219 ：仕様書無しさん：2018/07/11(水) 04:10:40.54 .net

>>218
「できないはず」の根拠がわからんww

220 ：仕様書無しさん：2018/07/11(水) 10:23:42.31 .net

バカには出来ないってことだろね

221 ：仕様書無しさん：2018/07/11(水) 10:38:27.10 .net

>>219
DIは依存関係を注入するだけだからだよ

222 ：仕様書無しさん：2018/07/11(水) 10:43:43.24 .net

依存関係注入が悪い翻訳だからね

加えて
コンポーネントはパラメーターで渡そう
コンポーネント組立は設定ファイルで
いや属性でやるだろ
とか議論の軸も整理されてない

223 ：仕様書無しさん：2018/07/11(水) 12:24:16.60 .net

ファウラーのDIが、DIの正しい定義だって
言ってるのにそれを無視するからこうなるんだよ

ファウラーは依存関係を分離するために
依存関係を注入する側の仕組みをどうするかの話をしてるのに
依存関係が注入される側の仕組みの方を見て
注入する側の仕組みは何でも構わない、変数の型をインターフェースにしておいて、
内部でnewしなければなんでもDIだって言ってるから意味不明なことになる

議論の筋の整理のレベルじゃなくて、間違った理解をしてる

224 ：仕様書無しさん：2018/07/11(水) 13:32:11.18 .net

>>223
ファウラーは依存関係を注入する側の仕組みについてなんて定義してるの？

って聞いてみたけど、また引用じゃなくて独自解釈を垂れるんだろうな...w

225 ：仕様書無しさん：2018/07/11(水) 14:42:49.06 .net

>>224
書いてあるやん。
「Assemblerが適切に設定させる」というように設定部分の話をしてる
クラスにインターフェースの変数を用意してコンストラクタで渡してもらうなんて話はしてない

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

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

226 ：仕様書無しさん：2018/07/11(水) 15:09:17.69 .net

依存関係を解決する側はなんでもいい
ファクトリーでもいいし
DIコンテナでもいい(というかこれはモロにファクトリー)
貧者のDIでもいいし
メインで初期化でもいい
あくまでオプション

227 ：仕様書無しさん：2018/07/11(水) 15:26:33.40 .net

Dependency Injection の基本的な考え方は
って書いてるのに、オプションとか意味不明
基本的な考え方ぐらい理解しましょうや

228 ：仕様書無しさん：2018/07/11(水) 15:39:36.80 .net

工場（ファクトリー）に鉄製品を作る機能をもたせたものを製鉄所というのであって、
工場だったら必ず製鉄所になるわけじゃない。

依存関係を解決する機能をもたせたものがDIなのであって
FactoryだったらかならずDIコンテナになるわけじゃない

229 ：仕様書無しさん：2018/07/11(水) 16:41:44.12 .net

もうさ、用語として組み込み系で使いづらいんだよなぁ

230 ：仕様書無しさん：2018/07/11(水) 17:26:15.92 .net

>>227
基本的な考え方は依存するクラスをインターフェースに置き換えて外部から与えましょうってだけ
ここまでがDIの本質

でもそうすると規模が大きくなった時に外部から与える処理自体が複雑になってくるよね
って副次的な課題に対しての解決策が幾つかあって
それがファクトリーやDIコンテナや貧者のDI
DIを語る上ではこれらは必須ではない
という意味でのオプション

231 ：仕様書無しさん：2018/07/11(水) 18:02:05.87 .net

>>230
> 基本的な考え方は依存するクラスをインターフェースに置き換えて外部から与えましょうってだけ
いえ、

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

です

232 ：仕様書無しさん：2018/07/11(水) 18:34:13.08 .net

なるほど
DIはMovieFinderだったのか

233 ：仕様書無しさん：2018/07/11(水) 18:44:24.82 .net

Dependency Injection の基本的な考え方は、独立したオブジェクトを
　> Assembler(組み立て係)として用意し、

234 ：仕様書無しさん：2018/07/11(水) 18:52:10.97 .net

ということはつまりMovieFinderですね

235 ：仕様書無しさん：2018/07/11(水) 18:56:03.57 .net

>>231
なんか、DI嫌いな人が、DI使ってる人を「マーチンファウラーを盲信する教条主義者」として貶めようとしてるようにしか見えない。

236 ：仕様書無しさん：2018/07/11(水) 19:15:13.17 .net

もともとな、外部から依存関係を与えるなんてことをしなければ、

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）を組み立て役として用意してる

237 ：仕様書無しさん：2018/07/11(水) 19:26:56.11 .net

いやいや。依存性が切れてないバージョンを出してきて「長くなったでしょ？」って……

238 ：仕様書無しさん：2018/07/11(水) 19:27:06.90 .net

DIContainerの生成メソッドを自分で呼び出すことはないよ

239 ：仕様書無しさん：2018/07/11(水) 19:29:46.80 .net

> DIContainerの生成メソッドを自分で呼び出すことはないよ

そりゃフレームワークが呼び出してるからな

そのフレームワークが呼び出せるようにするためには
絶対に依存関係の定義が必要になるわけよ。
長ったらしいApplicationContext.xmlのようなやつな

240 ：仕様書無しさん：2018/07/11(水) 19:31:40.65 .net

>>236
お前DI知らねーだろｗｗｗ

241 ：仕様書無しさん：2018/07/11(水) 19:32:11.19 .net

>>239
xmlとかいつの時代の話ですか…

242 ：仕様書無しさん：2018/07/11(水) 19:32:40.31 .net

直接インスタンス化すると開発する時に何かと不便じゃん
インフラが正常稼動してないと開発できない
ちょっとした動作確認にも時間がかかる
ビルド時間が長すぎる

243 ：仕様書無しさん：2018/07/11(水) 19:33:08.29 .net

>>240
反論しろよｗ

>>241
クラス自体に依存関係をアノテーションで埋め込むんですよね？ｗ
依存関係をクラス自体に書くわけですねーｗ

244 ：仕様書無しさん：2018/07/11(水) 19:33:37.95 .net

>>243
それも古い

245 ：仕様書無しさん：2018/07/11(水) 19:34:43.07 .net

>>244
それ以外ないよ？
あるって言うなら言ってくれてもいいけど、
でもないからな〜な。何を言うつもりだろー？

246 ：仕様書無しさん：2018/07/11(水) 19:35:29.14 .net

>>242
開発中なんだからソースコード修正して開発すれば良いんだよ

247 ：仕様書無しさん：2018/07/11(水) 19:47:04.74 .net

>>243
アノテーションｗｗｗ

248 ：仕様書無しさん：2018/07/11(水) 19:47:37.69 .net

>>245
>>205

249 ：仕様書無しさん：2018/07/11(水) 19:51:21.35 .net

アンチは妄想に囚われすぎ

250 ：仕様書無しさん：2018/07/11(水) 19:56:03.42 .net

べつにxml書くスタイルでも、古くはなくない？

251 ：仕様書無しさん：2018/07/11(水) 19:57:43.60 .net

今の王道DIComtainerは単純な登録タイプ

このインターフェースはこのタイプを生成しろ
あのインターフェースはこのファクトリーデリゲート使って生成しろ
みたいなやつね

KISSの原則に従って無意味な設定ファイルや制御しにくくわかりにくいアノテーションは駆逐された
シンプルなコードで普通にコンテナをビルドして実行するだけ

252 ：仕様書無しさん：2018/07/11(水) 22:30:44.35 .net

>>236
バーカw

253 ：仕様書無しさん：2018/07/11(水) 22:32:45.64 .net

>>236
サービスロケータが何だって？

254 ：仕様書無しさん：2018/07/12(木) 05:09:02.12 .net

>>251
> シンプルなコードで普通にコンテナをビルドして実行するだけ
ふーん？そのコンテナの名前は？
何で隠すの？

255 ：仕様書無しさん：2018/07/12(木) 05:12:09.92 .net

>>253
サービスロケーターじゃないよ

マーチン・ファウラーのDIの説明ででてくるPicoContainerでもそうなってるでしょ？
https://kakutani.com/trans/fowler/injection.html#ConstructorInjectionWithPicocontainer

> MutablePicoContainer pico = configureContainer();
> MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);

最近の人は、フレームワークに隠されて、詳細を知らない
DIコンテナを使ったら何故か魔法のように何もしなくても勝手に設定されると思っちゃう
でも内部的になこのようなメソッドが呼び出されてる

256 ：仕様書無しさん：2018/07/12(木) 05:21:33.17 .net

>>254
>>205

257 ：仕様書無しさん：2018/07/12(木) 06:32:20.62 .net

>>255

>>236ではこれを
＞obj = new MyObject();

こう書くって言ってんだろ
＞obj = DIContainer.create(MyObject);

こんなの完全に Service Locator だろ。 DIContainerへの参照を持ってしまってるからな

ほらファウラーの引用
> したがって、今回のアプリケーション用 ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。

258 ：仕様書無しさん：2018/07/12(木) 08:11:31.68 .net

>>257
その理屈で、

> MutablePicoContainer pico = configureContainer();
> MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);

これがService Locatorにならないことの説明はできるの？
picoの参照を持ってしまっているよね？


答えを言うと、各クラスの内部で参照を持ってしまうことがService Locator

259 ：仕様書無しさん：2018/07/12(木) 08:45:59.54 .net

うん>>236は外部から依存関係を与えずに
各クラスの内部で参照を持つと言っているからService Locator

260 ：仕様書無しさん：2018/07/12(木) 08:52:46.71 .net

> 各クラスの内部で参照を持つと言っているからService Locator

言ってないよね？
サンプルコードもMyObjectの外部でしか使ってないよね？

261 ：仕様書無しさん：2018/07/12(木) 08:54:37.27 .net

こう書かないと理解できないのかな？

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);

262 ：仕様書無しさん：2018/07/12(木) 08:58:11.42 .net

>>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); こう書けるようにするためには
依存関係の定義が重要だってことがわかるだろう

263 ：仕様書無しさん：2018/07/12(木) 08:59:22.67 .net

これぐらいDIコンテナを自分で作ったことがあれば
わかると思うんだけどな。

264 ：仕様書無しさん：2018/07/12(木) 09:36:10.66 .net

> 内部で以下相当のことをやることが可能になる

内部っていうのは、DIContainer.create関数内部って話ね。
MyObjectやA、B、Cクラスのことではないぞ

265 ：仕様書無しさん：2018/07/12(木) 10:09:47.52 .net

お前らコテハンつけろ、誰が誰に何言ってるのかわからん。
とくに皮肉っぽいこと言うやつと、
皮肉言われてるやつは、コテハン必須な。

266 ：仕様書無しさん：2018/07/12(木) 10:25:40.51 .net

アンチは分かりやすくドカタってコテハンつけると良いぞ

267 ：仕様書無しさん：2018/07/12(木) 10:34:11.16 .net

>>262
＞obj = new MyObject(); を
＞obj = DIContainer.create(MyObject); こう書けるようにするためには

だからそれService Locator
依存を注入される側でDIContainerの参照持ってるから

268 ：仕様書無しさん：2018/07/12(木) 12:16:33.28 .net

DIContainerとServiceLocatorの区別もついてないやつがDI DIって騒いでたってこと？

269 ：仕様書無しさん：2018/07/12(木) 13:53:06.70 .net

>>267
> 依存を注入される側でDIContainerの参照持ってるから

依存を注入される側ってどれのこと？
具体的にクラス名言って

270 ：仕様書無しさん：2018/07/12(木) 13:54:17.71 .net

>>268
だろうね。
依存性を注入される側のコードなんて書いて無いのに
注入される側にDIContainerの参照があるとか
幻が見えてるようだしｗ

271 ：仕様書無しさん：2018/07/12(木) 14:22:31.54 .net

>>268
> DIContainerとServiceLocatorの区別もついてないやつがDI DIって騒いでたってこと？
まさにそれがスレタイの狙い
DIとService Locatorの区別ができる、つまり違いを知ってる人は
Service Locatorはこう〜だけど、DIはこう〜とDIの本質を言うことができる

コンストラクタで依存しているオブジェクトを渡すという構造は
単に依存関係を分離した構造というだけで、依存関係を注入する方法を表していない

独立したオブジェクトをAssembler(組み立て係)として用意して注入する方法こそがDIなわけだよ
依存性の注入 = Dependency Injection なんだから

272 ：仕様書無しさん：2018/07/12(木) 14:36:24.22 .net

それって、ファクトリー＋コンテナ？

273 ：仕様書無しさん：2018/07/12(木) 14:47:58.38 .net

>>272
GoFのデザインパターンにあるのはFactory MethodとAbstract Factoryであって
ファクトリーもコンテナもないので、そう聞かれても正確な答えにはならない

ファクトリー = オブジェクトを生成するもの
コンテナ = 何かの入れ物
っていうアバウトな定義でいいのであれば、その通りだが。

更に言うなら「ファクトリー＋コンテナ」には、インターフェースの実装を
生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が
抜けてるので「ファクトリー＋コンテナ＋依存関係の解決」がDIコンテナと言える。
これに実際のDIコンテナはAOPの機能がついてたりするんだがこっちはおまけだな

274 ：仕様書無しさん：2018/07/12(木) 20:26:31.22 .net

>>271
Service Locatorにも組み立て係いるんだけど？

275 ：仕様書無しさん：2018/07/12(木) 20:49:03.06 .net

その組立係を何処から参照しているかの違いですね

276 ：仕様書無しさん：2018/07/12(木) 20:57:48.71 .net

何回言えば区別できるようになるんだ

277 ：仕様書無しさん：2018/07/12(木) 21:01:47.76 .net

言っただけで世界が平和になったらいいね

278 ：仕様書無しさん：2018/07/12(木) 21:07:41.83 .net

人間には感情があるからね

279 ：仕様書無しさん：2018/07/12(木) 21:08:13.57 .net

人類を滅ぼしたいね

280 ：仕様書無しさん：2018/07/13(金) 00:17:32.78 .net

>>279
どうやる？

281 ：仕様書無しさん：2018/07/13(金) 09:17:22.69 .net

おまえがたひれば相対的に世界が滅亡したようなものだぞ。

282 ：仕様書無しさん：2018/07/13(金) 22:02:01.14 .net

>>280
俺から反物質が生成されるまで生きてみる

283 ：仕様書無しさん：2018/07/14(土) 11:09:10.34 .net

JavaScriptのDIコンテナはどれですか？

284 ：仕様書無しさん：2018/07/14(土) 12:30:26.98 .net

>>283
こんなのとかどうですか？
https://qiita.com/Quramy/items/e65ee58cf1fba589c81b

285 ：仕様書無しさん：2018/07/17(火) 00:02:57.12 .net

終わりですか？

286 ：仕様書無しさん：2018/07/17(火) 06:05:16.35 .net

>>285
はい、もう出し尽くしました

287 ：仕様書無しさん：2018/07/17(火) 06:11:34.16 .net

最後の話題がこれ
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
その組立係を何処から参照しているかの違いですね

288 ：仕様書無しさん：2018/07/17(火) 06:17:54.62 .net

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も、依存関係を解決する方法で
そのやり方が違うものである

289 ：仕様書無しさん：2018/07/17(火) 06:48:57.74 .net

インターフェースで結合度を下げる->SLもDIも関係ない

実装インスタンスをクラスの外部で生成して渡す-> DI
注意: つまりSLはDIではない

DIのための生成手順を管理->ファクトリー

ファクトリーの実装パターンの1つ->DIContainer

290 ：仕様書無しさん：2018/07/17(火) 10:25:22.27 .net

これも忘れずに

GoFのデザインパターンにあるのはFactory MethodとAbstract Factoryであって
ファクトリーもコンテナもないので、そう聞かれても正確な答えにはならない

ファクトリー = オブジェクトを生成するもの
コンテナ = 何かの入れ物
っていうアバウトな定義でいいのであれば、その通りだが。

更に言うなら「ファクトリー＋コンテナ」には、インターフェースの実装を
生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が
抜けてるので「ファクトリー＋コンテナ＋依存関係の解決」がDIコンテナと言える。
これに実際のDIコンテナはAOPの機能がついてたりするんだがこっちはおまけだな

291 ：仕様書無しさん：2018/07/17(火) 10:42:01.75 .net

パターンをそんなに厳密に使ってる奴居るんだw

292 ：仕様書無しさん：2018/07/17(火) 14:22:13.35 .net

デザインパターンは、プログラマの間で正確に意味を伝わるようにした
共通の用語なんだから当然。

それに対してファクトリーはデザインパターンではなく正確な用語じゃない
だから意味が正確に伝わらない。

それを言っておかないと、ファクトリーとDI が同一のものとか言い出しかねないからな。
ファクトリーにオブジェクトのコンテナと依存関係を解決したものがDI

通常ファクトリーといったらオブジェクトの生成ぐらいしか意味を持たない
（つまりコンテナ機能はないので毎回作成だし、依存関係の解決もしない）

293 ：仕様書無しさん：2018/07/17(火) 14:24:12.12 .net

デザインパターンが実装まで定義してるなんて初耳だな。

294 ：仕様書無しさん：2018/07/17(火) 14:31:49.23 .net

実装を定義してるなんて書いてないが？
さっきから言葉の定義の話しかしてないよね？
ファクトリーはこうで、DIはこうって

295 ：仕様書無しさん：2018/07/17(火) 20:23:57.65 .net

だって、DIって、実装レベルの話だろ？

296 ：仕様書無しさん：2018/07/17(火) 20:47:34.95 .net

設計手法かな

297 ：仕様書無しさん：2018/07/17(火) 21:33:00.27 .net

>>287
DIアンチじゃね？

298 ：仕様書無しさん：2018/07/17(火) 21:46:46.14 .net

ドリルインポ

299 ：仕様書無しさん：2018/07/17(火) 21:59:55.68 .net

設計だよなぁ。DIの実装なんて各フレームワークで全然違うし

300 ：仕様書無しさん：2018/07/17(火) 22:01:41.16 .net

DI=ドリルインポ

301 ：仕様書無しさん：2018/07/17(火) 22:06:47.83 .net

大好きインぽ

302 ：仕様書無しさん：2018/07/17(火) 22:11:16.15 .net

でも明らかに粒度が違うよなぁ
デザインパターンが基本設計なら、DIは詳細設計だろ？
なんで同じステージで語るの？

303 ：仕様書無しさん：2018/07/18(水) 00:51:59.32 .net

コンポーネントの切り分けと依存関係は基本設計やろ

304 ：仕様書無しさん：2018/07/18(水) 03:30:15.55 .net

DI厨はこういう理屈であることがわかったなｗ

席は一つしかありません。
基本設計の椅子にデザインパターンが座りました
空きは詳細設計のみです。
だからDIは詳細設計になります。
詳細設計というのはプログラミングのことです。
プログラミングというのは実装です。
だからDIは実装になります
DIが何をやるかには興味がありません。
詳細設計しか椅子がないのだからDIは実装です

305 ：仕様書無しさん：2018/07/18(水) 08:36:06.34 .net

UMLで言うところの、黒いひし形か白いひし形かの違いを
延々と言い合うスレって事でいい？

306 ：仕様書無しさん：2018/07/18(水) 08:48:55.14 .net

キチガイはスルー

307 ：仕様書無しさん：2018/07/18(水) 10:19:28.61 .net

>>305
違うな。ひし形の色だけじゃない。
すべての形、その数、依存関係、まあ要するに
設計なんだが、それを言い合うスレだ

308 ：仕様書無しさん：2018/07/18(水) 10:20:02.92 .net

デザインパターンが基本設計なら、DIも基本設計だろ？
同じステージの話なんだから

309 ：仕様書無しさん：2018/07/18(水) 10:22:29.33 .net

いやいや、どう見てもDIは実装の話だろ？

310 ：仕様書無しさん：2018/07/18(水) 10:35:41.07 .net

どうみてって何を見たの？
見た実装とやらを言ってみて

311 ：仕様書無しさん：2018/07/18(水) 10:37:34.47 .net

だって実装の話しかして無いじゃん。

312 ：仕様書無しさん：2018/07/18(水) 10:38:36.20 .net

だから見た実装とやらを言ってみて

ま、答えずに逃げてる所みれば
どういうことか、わかりますけどねｗ

313 ：仕様書無しさん：2018/07/18(水) 10:39:15.30 .net

お前が見た「実装」とやらを持って
上司に「実装」しました！って言ってこいよｗｗｗ

314 ：仕様書無しさん：2018/07/18(水) 10:40:41.89 .net

>>312
は？
このスレのどこを見ても実装の話しかして無いだろw

315 ：仕様書無しさん：2018/07/18(水) 10:40:57.66 .net

ほらまた逃げたｗ

316 ：仕様書無しさん：2018/07/18(水) 12:10:28.59 .net

よこからスマンけどDIってなーに？

317 ：仕様書無しさん：2018/07/18(水) 12:23:53.14 .net

>>1に書いてあるだろ

■ DI（ゴミ）

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

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

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

318 ：仕様書無しさん：2018/07/18(水) 17:38:16.22 .net

>>316
ドリルインポ

319 ：仕様書無しさん：2018/07/18(水) 21:57:47.93 .net

キチガイはスルー

320 ：仕様書無しさん：2018/07/21(土) 21:55:01.84 .net

1つ言えるのはオブジェクト指向のなんかよりも
データ構造とアルゴリズムの方がよっぽど重要だということ。
昔はオブジェクト指向の勉強を頑張っていたけどそのときは
全然プログラミングがうまくならなかった。
現代の世の中はガチガチに設計されたライブラリを使って
コードを書くだけだから生半可なオブジェクト指向の知識なんて
ゴミ同然だよ。80年代90年代に考えられた思想とか、もうゴミに
なってしまった思想が多くて有害だよ。
結局現場でやることは「メソッドの使い方を求めてQiitaやStack OverFlowを
漁って成功するコードを見つけるまで疲れ果てる」ことに変わりはない。
せっかく勉強した内容が時代遅れで「裏切られる」ことのほうが多い。

321 ：仕様書無しさん：2018/07/21(土) 21:55:37.69 .net

一方、データ構造とアルゴリズムをガッツリと勉強してから
様々なデータ構造の使い方、問題の解決がうまくなった。
ブロックチェーンのアルゴリズムの理解や
データ分析の数学的演算がコーディング
できるようになってプログラミングが格段に楽しくなった。
スマートにオブジェクト指向で設計する力なんかより
「ゴリゴリとアルゴリズムを書く力」の方がよっぽど重要。
「再利用性」？「変更の影響」だって？そんなものゴミだね。
それは自分以外の人間のメリットのための技術であって、
自分へ還元されるためのメリットではない。
再利用性は自分の書いたコードなら信頼できるしコピペして使えばいい。
自分の書いたコードのコピペは全然ありだと思う。
適したメソッドが見つからなかったらQiitaを漁ったりせずに
自分でゼロから実装したほうが速い。
その場で手っ取り早くコードを生成しているから、
どんな既存コードにも頼っていないから俺の実装したコードは
依存性は低い。

322 ：仕様書無しさん：2018/07/21(土) 22:01:01.01 .net

天才が作ったライブラリないとお前何にもできないじゃん

323 ：仕様書無しさん：2018/07/21(土) 22:23:31.55 .net

>>320-321
DIの話から逃げるなら、
こんなところにそのクソ文章をコピペしてないで
こっちに逃げ帰りな

データ構造,アルゴリズム,デザインパターン総合ｽﾚ 3&#169;2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1466315249/814

早速お前ボロクソに言われてるけどなｗ

324 ：仕様書無しさん：2018/08/22(水) 21:32:26.82 .net

そんなにアルゴリズム好きなら
量子アルゴリズムでも探せば喜ばれるぞ

325 ：仕様書無しさん：2018/09/18(火) 12:10:45.11 .net

diは無知なんだが、これは品質確保のための手法ってことで良いの？
未熟な奴に任せて設計させるとカオスな構造を生み出すから
分かってる奴があらかじめ枠組み組んでここでやれって言う奴？

326 ：仕様書無しさん：2018/09/18(火) 12:18:07.62 .net

前提条件として、どんな開発場面を想定してんだろ？
このスレ見てても分かる通り、前提条件の共有も分からんのが多いだろ？
そのこと自体が、何かしらの標準や型が必要であることを示唆してるよね

327 ：仕様書無しさん：2018/10/15(月) 21:19:07.09 .net

　私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。

328 ：仕様書無しさん：2018/10/20(土) 20:45:19.62 .net

このヤフーブロはこのページからおもろいし、ためになるわ。
https://blogs.yahoo.co.jp/kamyu_2010/35442561.html

329 ：仕様書無しさん：2018/11/04(日) 11:30:33.87 .net

ブリッジパターンの応用手順のブログみたい。パッケージを開発する時を前提にしているね。
https://blogs.yahoo.co.jp/kamyu_2010/35480077.html

330 ：仕様書無しさん：2020/11/10(火) 12:19:04.44 .net

俺は頑なにmain一本グソ職人

331 ：仕様書無しさん：2023/08/13(日) 11:33:03.36 ID:G2S35OhhY

松野博―は、拉致ガ━とか些末な昔話してないて゛、大量破壞兵器て゛あるクソ航空機による強盗殺人という重大な人権侵害か゛存在すること．また
個人の尊厳や人権の意義について，じっくりとてめえこそが考えとけや力ス，税金で地球破壞支援，世界最惡の脱炭素拒否テ□國家に送られる
化石賞連続受賞して．世界中から非難されていながら．力による‐方的な現状変更によって滑走路にクソ航空機にと倍増させて閑静な住宅地
から都心まて゛数珠つなぎで鉄道の３０倍以上もの莫大な温室効果カ゛スまき散らして騒音まみれにして静音か゛生命線の知的産業壞滅させて子供の
学習環境破壊して氣侯変動させて海水温上昇させてかつてない量の水蒸氣を日本列島に供給させて土砂崩れ，洪水．暴風，突風．灼熱地獄にと
住民の生命と財産を徹底的に破壊することで私腹を肥やしてる世界最惡のマッチポンプ殺人テ□組織公明党天下り犯罪集団國土破壊省齋藤鉄夫
とともに好き放題破壊と殺人を繰り返して隣国挑發して原爆落とした世界最惡ならず者国家まで崇拝して白々しい軍拡増税．物事の本質も理解
て゛きない孑と゛も増やして洗腦して兵隊にして殺してさらに私腹を肥やそうというテ□組織自民党に乗っ取られた日本で孑とか産むのはバカだけ

創価学会員は．何百万人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まて゛出てる世界最悪の殺人腐敗組織公明党を
池田センセ一か゛□をきけて容認するとか本氣で思ってるとしたら侮辱にもほと゛か゛あるそ゛！
ｈＴｔрｓ：／／ｉ，ｉｍｇｕｒ．сｏｍ／hnli1ga.jpeg

332 ：仕様書無しさん：2023/10/18(水) 04:32:22.39 ID:oA20Nhs6c

私利私欲のために莫大な温室効果カ゛スまき散らして気候変動させて災害連発させて人殺して石油需給逼迫させて物価暴騰させて
社会に甚大な損害を与えながらスーダンた゛のイスラエルだのに行ってなにやら巻き込まれてるボケどもか゛クソ税金泥棒公務員利権の
ネタにされながら無関係な国民から強奪した税金使って送迎とか唖然とするよな
こいつらひとり100０万は徴収すべきだし今後は邦人出国税ひとり100０万は徴収しないとな
入管収容で税金泥棒１００%クソ公務員の過失責任を税金で肩代わりするとかやってるカ゛イジン入国税も100０萬は徴収するのが筋
クソ航空機は航空燃料税1KL1千万円離発着税1回1億圓上空通過税1Кm100万円さらにスティンガー解禁して私有地からのクソ航空機撃墜合法化は
住民としての普遍的な権利だし憲法ガン無視て゛都心まて゛数珠つなぎでクソ航空機飛ばして私権侵害して私腹を肥やす強盜殺人の首魁
斉藤鉄夫ら世界最悪の殺人腐敗組織公明党を殲滅しないとお前らの生命と財産は奪われる一方だぞ
（羽田)ttps://www.call4.jｐ／info.рhP?tуpe=iTｅms&id=I00００062 , tΤｐs：/／haneda-project.jimdofreе.Ｃom/
(成田)ttрs://n-souonhigaisosyoudan.amebaownd.com/
(テロ組織］ttps://i.imgur.com/hnli1ga.jpeg