1仕様書無しさん2018/07/07(土) 10:47:57.49
2仕様書無しさん2018/07/07(土) 10:48:31.89
Service Locator と Dependency Injection の違いから
正しいDependency Injectionの意味を理解しよう！
■ Service Locator と Dependency Injection ってなにが違うの？
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
の図より
Service Locator には、サービスロケーターがあって、
Dependency Injection には、その代わりに
ビルダーっていうのがあるのはわかった。
そのビルダーっていうのがDIコンテナと
呼ばれているものであることもわかった
重要な違いは、
Service Locator は、サービスロケーター があって
Dependency Injection には、ビルダー（DIコンテナ）がある 3仕様書無しさん2018/07/07(土) 10:57:37.64
4仕様書無しさん2018/07/07(土) 10:58:16.24
DIされるクラスはDIコンテナを直接利用しないようにしようね終わり
5仕様書無しさん2018/07/07(土) 11:03:09.05
だからDIコンテナの話がないのはDIじゃない
6仕様書無しさん2018/07/07(土) 11:06:18.19
7仕様書無しさん2018/07/07(土) 11:17:32.41
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
https://github.com/google/guice/wiki/GettingStarted
Guiceとの依存関係注入を始める方法。
入門
依存性注入の場合、オブジェクトはコンストラクタの依存関係を受け入れます。
オブジェクトを構築するには、まずその依存関係を構築します。しかし、
各依存関係を構築するには、その依存関係などが必要です。したがって、
オブジェクトを作成するときは、実際にオブジェクトグラフを作成する必要があります。
手作業でオブジェクトグラフを作成すると、労力がかかり、エラーが発生しやすくなり、
テストが困難になります。代わりに、Guiceはオブジェクトグラフを作成することができます。
しかし、まずGuiceは、あなたが望むように正確にグラフを構築するように構成する必要があります。
モジュールはインジェクタのビルディングブロックであり、Guiceのオブジェクトグラフビルダーです。
まず、インジェクタを作成し、それを使用して以下をビルドしBillingServiceます。
billingServiceを構築することで、Guiceを使って小さなオブジェクトグラフを構築しました。
グラフには、請求サービスとそれに依存するクレジットカードプロセッサとトランザクションログが含まれています。 9仕様書無しさん2018/07/07(土) 11:28:13.78
これは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
このようなインジェクタを使ってインスタンスを作成するのが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
動機・・・なになにしたい
それをどうやって解決するかの一つの方法が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
13仕様書無しさん2018/07/07(土) 11:34:23.44
Assemblerを使わない場合のDI（正確には手動のAssember）を
見てみるとわかると思うがすごく面倒で、
こんなことやってられない。
その批判を避けるためにDIパターンでは
DIコンテナを使うことが事実上の必須になっている。
14仕様書無しさん2018/07/07(土) 11:37:00.20
面倒だと書いた、手動の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
単体テストでモックに差し替えるのにDIコンテナ使うの？
16仕様書無しさん2018/07/07(土) 11:45:13.85
>>15
結局の所、それがDIを使う目的になっちゃってる
で、モックに差し替えるためにDI使わなくてもできるなら
DIいらないよね？って話
そのためのツールがJavaだとMockitoとかEasyMockとかJMockitになる
モックにすげ替えることができるように設計レベルで歪めてしまうDIと違って
単純な設計のまま、モックにすげ替えることが可能になる 17仕様書無しさん2018/07/07(土) 11:57:18.64
前スレでストレージを他に変えるときDI使ってるという話忘れた？
18仕様書無しさん2018/07/07(土) 11:58:20.59
>>17
それは単なるストラテジーパターンを使えばいいだけの話で、
mainにずらずら依存関係書いたりする必要がないから
DIじゃなくていいんだよっていう話なの理解してないの？ 19仕様書無しさん2018/07/07(土) 12:24:04.12
結局手動でやってるんだ
フレームワークで簡単にできるように用意されてるの使えばいいのに
20仕様書無しさん2018/07/07(土) 12:41:45.09
小さいものしか作ってないんだからいらんよ
mainに手動で書いていれば事足りる
21仕様書無しさん2018/07/07(土) 12:44:28.79
DIコンテナに登録しておけば自動でインジェクションしてくれたりするのに
22仕様書無しさん2018/07/07(土) 13:13:55.89
面倒やん、その定義書くの
DIコンテナ用のライブラリも必要になるし
そんな事するぐらいならもうDIなんていらねーってなる
23仕様書無しさん2018/07/07(土) 15:37:14.44
ですね。だからみんなDIはいらないって言ってる
24仕様書無しさん2018/07/07(土) 15:40:55.85
ドカタが無理して数学について語るスレはここですか？
25仕様書無しさん2018/07/07(土) 15:42:21.15
とりあえず https://kakutani.com/trans/fowler/injection.html の中から
Dependency Injection と Service Locator の違いが書いてある部分を抜き出してみた
これがそれぞれのパターンの重要な特徴だと思われる
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
> Service Locator を利用する
> Service Locator の背後にある基本的な考え方は、あるアプリケーションが必要とするであろうサービスの
> すべてを保持する、単一のオブジェクトを用意するというものだ。したがって、今回のアプリケーション用
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
26仕様書無しさん2018/07/07(土) 15:43:32.63
>>24
言葉の定義の問題であって数学の話じゃないで
元のスレにお帰りください。 27仕様書無しさん2018/07/07(土) 15:44:10.89
DIは必須と言っていいぐらい有益だがDIコンテナは別にいらんな
Factoryを自分で書いたほうが柔軟で良い
28仕様書無しさん2018/07/07(土) 15:44:54.36
>>26
ドカタに数学は無理ですもんね
身の程を知るのは良いことですよ 29仕様書無しさん2018/07/07(土) 15:45:32.65
30仕様書無しさん2018/07/07(土) 15:51:23.00
公理1: 無能に数学はできない
公理2: ドカタは無能である
定理: ドカタに数学はできない
証明:
ドカタに数学ができると仮定する。
すると公理1よりドカタは無能ではない。
しかしドカタが無能ではないとすると公理2と矛盾する。
ゆえにドカタに数学はできない。Q.E.D
31仕様書無しさん2018/07/07(土) 15:51:25.87
ようやく定義だと気づいたかｗ
ドカタをからかうのは楽しいな
またくるからよ。じゃあなｗ
32仕様書無しさん2018/07/07(土) 15:52:38.12
>>30
なんで公理（命題）が２つ出てきてるんだよｗ
お前、本当は数学わかってないだろ 33仕様書無しさん2018/07/07(土) 15:53:16.19
34仕様書無しさん2018/07/07(土) 15:55:47.59
>>30
> 定理: ドカタに数学はできない
> ゆえにドカタに数学はできない。Q.E.D
お前、定理（証明ずみなので、証明無しで使ってもいいはずのもの）を証明してるで？ 35仕様書無しさん2018/07/07(土) 15:56:54.26
>>32
自然数の公理系（ペアノの公理）は5個の公理で成り立ってるよ 36仕様書無しさん2018/07/07(土) 15:57:46.39
>>33
公理=仮定なんだから
仮定をもとにもう一方の仮定を証明なんかできないって
マジレスしたらだめな流れ？ 37仕様書無しさん2018/07/07(土) 15:57:52.36
>>34
その定理の証明だろw
そして定理には証明が必要だろ
ホント数学知らんのな 38仕様書無しさん2018/07/07(土) 15:59:33.60
>>36
公理は仮定じゃないよ
このスレに出てきた言葉で一番近いニュアンスなら定義 39仕様書無しさん2018/07/07(土) 16:00:02.98
>>37
仮定から証明をすることは不可能って話なんだけど
理解してる？ 40仕様書無しさん2018/07/07(土) 16:00:36.35
41仕様書無しさん2018/07/07(土) 16:01:01.64
>>38
ふーん、そういう理屈で行くのなら
定義を証明して見せてっていうだけの話だけど 42仕様書無しさん2018/07/07(土) 16:01:49.95
定義の数学的証明まだかなー？ｗ
43仕様書無しさん2018/07/07(土) 16:03:54.46
定理ってのはさ、公理が真のときに真になる命題のことなんだよね
だから公理が成り立って証明がつく命題は真といえる
もちろん、全く別の公理を立てることもできて、数学では互いに矛盾するようないろんな公理系がある
44仕様書無しさん2018/07/07(土) 16:04:13.50
定義の数学的証明はやく！
45仕様書無しさん2018/07/07(土) 16:05:22.44
話逸れてるけど、DIとService Locatorの定義はこれであってるんだよね？
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
> Service Locator を利用する
> Service Locator の背後にある基本的な考え方は、あるアプリケーションが必要とするであろうサービスの
> すべてを保持する、単一のオブジェクトを用意するというものだ。したがって、今回のアプリケーション用
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
46仕様書無しさん2018/07/07(土) 16:05:59.87
47仕様書無しさん2018/07/07(土) 16:08:08.71
物理法則と矛盾した世界を定義することも出来るのが数学だから
ドカタが無能でない世界も定義できる。数学ならね
でもこのスレのドカタは無能だねw
48仕様書無しさん2018/07/07(土) 16:09:36.13
で、定義の数学的証明は？
49仕様書無しさん2018/07/07(土) 16:15:57.41
>>47
> 物理法則と矛盾した世界を定義することも出来るのが
なるほど、物理法則と矛盾した世界を定義したわけか 50仕様書無しさん2018/07/07(土) 16:17:12.38
男は俺だけの世界を定義して、
俺以外はみんな女、ハーレムじゃぁ
って感じかな？
ちょっと虚しいね
51仕様書無しさん2018/07/07(土) 16:18:36.41
>>49
そりゃ無能でないドカタもいるだろ実際には
でも、このスレのドカタは無能w 52仕様書無しさん2018/07/07(土) 16:19:17.66
ファウラーとかいうおじさんがこれがDIって言ってるだけだろ
真のDIがその定義であるかどうかはまた別の問題だな
53仕様書無しさん2018/07/07(土) 16:20:42.61
良く知りもしない数学的証明なんて言葉でマウント取ろうとしたヤツが悪い
誰だよ最初に言いだしたヤツ
54仕様書無しさん2018/07/07(土) 16:21:13.40
>>52
そのファウラーがDIという言葉を作り出したんだよｗ
正確には有識者の意見をまとめてDIという呼び方が適切であると同意をとったんだけどな
だからDIと言う言葉を使うなら生みの親のファウラーの定義に従わなければいけない 55仕様書無しさん2018/07/07(土) 16:22:57.98
なんだ。ファウラーがDIという言葉を定義した人か
56仕様書無しさん2018/07/07(土) 16:24:47.75
>>53
まあいいじゃん。いいおもちゃになってくれたしｗ 57仕様書無しさん2018/07/07(土) 16:25:42.27
>>54
ファウラーが生み出したということ
有識者が同意をとったこと
その同意が一般に認識されていて認められていること
ファウラーの定義に従わなければならないこと
この4つを数学的に証明して
できなきゃ嘘ってことだ 58仕様書無しさん2018/07/07(土) 16:26:20.52
>>57
定義なんで証明する必要なし
いい加減学習しろ 59仕様書無しさん2018/07/07(土) 16:27:31.44
お、今度のドカタは知恵をつけてきたじゃん
今度は「数学的証明さん」はどんなふうに対抗するのかな？ｗ
60仕様書無しさん2018/07/07(土) 16:28:00.61
有能なドカタ登場だな
61仕様書無しさん2018/07/07(土) 16:29:07.53
>>58
ファウラーが言ってるのはオレオレファウラーDIの定義な
真のDIの定義とオレオレファウラー定義が同一のものなのかはまだわからない
なのでファウラーの定義を引用して、真のDIとはこういうものである、と言うことはできない
ファウラーによると、オレオレファウラーDIとはこういうものである、ならば言って良い 62仕様書無しさん2018/07/07(土) 16:30:09.70
真のDIってなんだよｗｗｗｗ
お前の定義のDIが真のDIだとでも思ってんの？
それこそオレオレDIだろ
63仕様書無しさん2018/07/07(土) 16:30:53.87
> オレオレファウラーDI
ファウラーの時点でオレオレじゃないが？
64仕様書無しさん2018/07/07(土) 16:32:45.55
ファウラーの定義にはAssemblerについて「独立したオブジェクトをAssembler(組み立て係)として用意し」としか書いてないね
ってことはAssemblerが一つであることも、ましてや依存関係をひとまとめに定義することもDIに必須じゃないわけだ？
65仕様書無しさん2018/07/07(土) 16:33:14.35
>>64
図を見れば一つしかないことはわかる。
あと英語なら複数なら複数形になってるはず 66仕様書無しさん2018/07/07(土) 16:35:47.87
>>65
図には作られる側のクラスやインターフェースも一個しかないけど？ 67仕様書無しさん2018/07/07(土) 16:39:11.21
マーチンファウラーって何を作った人？
68仕様書無しさん2018/07/07(土) 16:42:22.02
>>67
世界のソフトウェアの設計の基礎を作り上げた人 69仕様書無しさん2018/07/07(土) 16:43:53.06
この業界でマーチンファウラーを知らないとかモグリだろ
70仕様書無しさん2018/07/07(土) 16:45:23.08
71仕様書無しさん2018/07/07(土) 17:01:34.33
72仕様書無しさん2018/07/07(土) 17:28:24.74
73仕様書無しさん2018/07/07(土) 17:56:44.64
で？マーティン・ファウラーのDIの定義がそれとして、だからどうしたと？
74仕様書無しさん2018/07/07(土) 18:03:22.11
DIの定義を正しく知ってないと、DIの説明はできないってことでしょう？
オレオレDIの解説したってしょうがないし
75仕様書無しさん2018/07/07(土) 18:05:31.04
オレオレDIではない。俺が考える真のDIの説明である
76仕様書無しさん2018/07/07(土) 18:06:38.22
この世の他のどこにもない。俺だけの真のDIこそが。唯一正しいDIである
77仕様書無しさん2018/07/07(土) 18:51:31.87
つーか俺のほうがすごいだろ
マーチンファウラーなんかより
78仕様書無しさん2018/07/07(土) 19:09:59.29
いや、このハゲ、マジで何を作ったのかわからない
そもそも前線で働いてるのか？
79仕様書無しさん2018/07/07(土) 19:27:59.48
80仕様書無しさん2018/07/07(土) 19:41:38.54
数十年にわたってビジネスへのオブジェクト指向の適用に尽力する独立コンサルタント。
ヘルスケア、金融取引、企業財務などの分野におけるシステムのコンサル経験を持つ。
顧客にはクライスラー、シティバンク、英国民保健サービス、アンダーセン・コンサルティング、ネットスケープ・コミュニケーションズなどが名を連ねる
『リファクタリング 既存のコードを安全に改善する』より
81仕様書無しさん2018/07/07(土) 19:51:05.32
そんな凄い人が提唱したDIに
一介のドカタがケチ付けてるってホント？
82仕様書無しさん2018/07/07(土) 19:53:40.39
人として凄いかどうかはセオリーの正当性とは関係がないんだよね
83仕様書無しさん2018/07/07(土) 20:02:47.41
つまりマーチンファウラーが正しいとは限らないということは
俺が正しいってことになりませんか？
84仕様書無しさん2018/07/07(土) 20:05:26.78
それは暴論すぎるw
85仕様書無しさん2018/07/07(土) 20:08:47.35
別の惑星では違う定義で同じことやってるかもしれない
誰が決めたから正しいなんてのは文系的で馬鹿馬鹿しいか細い理だよ
86仕様書無しさん2018/07/07(土) 20:13:13.14
つまり他人は正しいとは限らない
俺のこと信じる気になりましたか？
87仕様書無しさん2018/07/07(土) 20:13:54.88
お前も他人
88仕様書無しさん2018/07/07(土) 20:19:26.22
DIアンチはファウラーを持ち上げたいの？貶したいの？
89仕様書無しさん2018/07/07(土) 20:20:36.25
DIアンチじゃねーし
ファウラーは尊敬してるが
DIとDIコンテナは別の話だ
それだけ
90仕様書無しさん2018/07/07(土) 20:27:50.48
んで？
工数削減なのか？
品質向上なのか？
どっちに効果あるの？
このハゲは
91仕様書無しさん2018/07/07(土) 20:33:38.39
>>88
マーチンファウラーを貶めることで
俺の言うことをが正しいと証明したい 92仕様書無しさん2018/07/07(土) 20:34:00.88
お前らハゲのいうことを聞くのか？
93仕様書無しさん2018/07/07(土) 20:34:29.00
ハゲだぞ、こいつハゲだぞ、俺はふさふさだ
ハゲと言うだけで、もう結論出てるだろ
94仕様書無しさん2018/07/07(土) 20:35:30.51
なんか仕組みを説明できた奴いないよね？
95仕様書無しさん2018/07/07(土) 20:39:33.40
ほら、いねーだろ。つまりどういうことか
俺が正しいってことになりませんか
96仕様書無しさん2018/07/07(土) 20:53:02.22
あなたが正しい
あなたは神だ
97仕様書無しさん2018/07/07(土) 20:56:14.92
お前がこの世界の髪だ
98仕様書無しさん2018/07/07(土) 21:16:09.29
マーチンファウラーを叩くことで自分の説得力を
あげようとする卑怯な手が失敗した今、こいつは何をする気だろうか？
99仕様書無しさん2018/07/07(土) 21:33:00.43
はい、茶番は終わりだ
DIとService Locatorの定義
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
> Service Locator を利用する
> Service Locator の背後にある基本的な考え方は、あるアプリケーションが必要とするであろうサービスの
> すべてを保持する、単一のオブジェクトを用意するというものだ。したがって、今回のアプリケーション用
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
100仕様書無しさん2018/07/07(土) 21:55:36.65
101仕様書無しさん2018/07/07(土) 21:56:50.89
>>100
メリットの話ではない。DIのちゃんとした定義を明確にしてるだけだ 102仕様書無しさん2018/07/07(土) 22:35:31.73
>>101
その定義が正しいという証明がない
おっさんが勝手に定義だっていってるだけ 103仕様書無しさん2018/07/07(土) 22:47:30.00
>>102
ドカタが証明とかの言葉を使うなって言ってんだろ
無能を自覚しろ 104仕様書無しさん2018/07/07(土) 23:24:29.60
ファウラーの定義で何か問題あるの？
105仕様書無しさん2018/07/07(土) 23:32:25.33
106仕様書無しさん2018/07/08(日) 05:30:00.74
>>104
すごく困る。ファウラーの定義とは違うことを言ってるから 107仕様書無しさん2018/07/08(日) 08:42:54.33
108仕様書無しさん2018/07/08(日) 08:45:43.22
>>104
問題はないがDIコンテナが必須というのは正確ではない
というだけの話 109仕様書無しさん2018/07/08(日) 08:48:57.07
必須じゃなくてもDIコンテナを使わないと
手動でDIコンテナ相当のことをしないといけないのでもっと大変
だから開発効率上、DIコンテナを使うのは必須
110仕様書無しさん2018/07/08(日) 09:21:13.07
リポジトリでオブジェクトを作るときってDIコンテナ使う？
111仕様書無しさん2018/07/08(日) 09:27:22.19
>>109
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？ 112仕様書無しさん2018/07/08(日) 09:46:40.70
ファウラーの定義にはこう書かれています
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
113仕様書無しさん2018/07/08(日) 09:48:05.12
つまり
独立したオブジェクトをAssembler(組み立て係)として用意します
MovieFinder インタフェースの実装をMovieLister クラスのフィールドへ適切に設定させまます。
これがDependency Injection の基本的な考え方です
114仕様書無しさん2018/07/08(日) 09:51:40.62
もうね既存の用語を違う意味で使ってる時点でダメダメなんだよな。
115仕様書無しさん2018/07/08(日) 10:24:14.09
既存の用語っていのなら、DependencyもInjectionも
英語なわけで、昔からあった用語
だから、ファウラーが勝手に定義して言い訳がない
人それぞれのDependency Injectionというのがある
俺のDependency Injectionは俺だけのものだ
他人が勝手に決めつけていいものではない
116仕様書無しさん2018/07/08(日) 10:29:50.73
>>113
じゃあmain()の中でインジェクションして回っても、main()が何かのオブジェクトに属する言語なら
main()を持つオブジェクト = Assembler(組み立て係)
という解釈が成立するからファウラーのDIになるね 117仕様書無しさん2018/07/08(日) 10:31:08.86
>>116
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？ 118仕様書無しさん2018/07/08(日) 10:34:43.11
119仕様書無しさん2018/07/08(日) 10:36:41.69
120仕様書無しさん2018/07/08(日) 10:37:13.42
勝手な解釈するなってことですよ
解釈はファウラーが言った言葉ではない
121仕様書無しさん2018/07/08(日) 10:37:44.79
>>119
うっせー、みとめん
コンストラクタにオブジェクトを指定したら
それはDI 122仕様書無しさん2018/07/08(日) 10:39:21.69
ファウラーはハゲだ。それだけで疑うのに十分だろ。はい論破
123仕様書無しさん2018/07/08(日) 10:40:25.89
>>120
ファウラーの定義にDIコンテナなんて言葉は出てこないので
DIコンテナ必須なんて勝手な解釈するなってことですね、わかります 124仕様書無しさん2018/07/08(日) 10:45:22.43
独立したオブジェクトが必要とは書いてあるね
125仕様書無しさん2018/07/08(日) 10:48:20.83
>>121
なら上のリポジトリにissue上げてみて 126仕様書無しさん2018/07/08(日) 12:34:07.90
127仕様書無しさん2018/07/08(日) 12:53:57.42
128仕様書無しさん2018/07/08(日) 12:58:52.27
ＤＩについて一番まともな事書いてある本ってどれでしょうか？
129仕様書無しさん2018/07/08(日) 13:02:06.08
>>128
AmazonでDependency Injectionで検索した？ 130仕様書無しさん2018/07/08(日) 13:49:26.30
>>127
つまり、ファウラーの定義に従え！って何度もコピペしてたDIアンチ自身が
ファウラーの定義を勝手に解釈して歪めてたってことね 131仕様書無しさん2018/07/08(日) 16:20:09.56
132仕様書無しさん2018/07/08(日) 17:07:13.23
133仕様書無しさん2018/07/08(日) 18:23:51.57
デコレーター使いたいなぁとかパラメーターで分岐する生成したいなぁとか細かく制御しようとするとDIコンテナじゃ物足りないんだよね
コンテナに登録するのとファクトリー書くのじゃ手間に大差ないし
DIは便利だけどDIコンテナとないうゴミパターンを必須にされたら困るよ
134仕様書無しさん2018/07/08(日) 18:31:04.30
>>133
DIってそういうときに使うもんじゃないし。
基本的にアプリケーション内でインスタンスが一つしか
必要ないときだけ使用する
ウェブアプリのように独立したセッションがある場合
そのセッションごとに使用することもある 135仕様書無しさん2018/07/08(日) 18:34:53.00
そういう説明って公式に書いてあったりする？
136仕様書無しさん2018/07/08(日) 18:46:10.73
ないけど、事実上そうだよ。
でないとサービスロケーターになってしまう
DIパターンにおけるインスタンスを生成するオブジェクト（通常DIコンテナ）に
依存せずにインスタンスを生成するには、上の層でインスタンスを生成してもらわないといけない
上の層っていうのはフレームワークに隠蔽されたアクションに相当する処理の開始部分
「DIパターンにおけるインスタンスを生成するオブジェクト」を上の層以外の
部分で使うことは、それに依存してしまうことになってしまい、
それは事実上サービスロケーターと同じことになる
137仕様書無しさん2018/07/08(日) 18:57:27.02
>>135
明示的にスコープ指定するから当たり前じゃない？ 138仕様書無しさん2018/07/08(日) 19:08:44.71
>>136
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
MovieLister から ServiceLocator への参照が発生するのがサービスアロケータだろ
ファウラーの定義を勝手に解釈するの止めてもらえませんかね？ 139仕様書無しさん2018/07/08(日) 19:58:38.85
>>134
DIの仕事だよ
デコレーターなんてまさにDIコンテナがよしなに処理してくれるべき仕事だし
パラメーターはよくあるパターンだとデータベースの接続先だけが異なる場合などに必要
そもそもアプリにインスタンスが1つなら全部シングルトンになってしまうが一般的なDIコンテナの設計はそんな風にはなってない
あくまでシングルトンは特別な場合 140仕様書無しさん2018/07/08(日) 19:59:53.61
>>138
MovieLister から ServiceLocatorを使わずに、
何かしらのインスタンスを作成するにはどうすればいい？
newならもちろん普通にできる。だけどnewではDIにならない 141仕様書無しさん2018/07/08(日) 20:00:47.64
>>139
> デコレーターなんてまさにDIコンテナがよしなに処理してくれるべき仕事だし
いや、むり。DIコンテナから複数のインスタンスを生成する方法がない 142仕様書無しさん2018/07/08(日) 20:01:14.00
>>139
> パラメーターはよくあるパターンだとデータベースの接続先だけが異なる場合などに必要
そのように、最初に一回やってしまえばOKみたいなものにしか使えない 143仕様書無しさん2018/07/08(日) 20:04:35.58
このスレ勉強になる
144仕様書無しさん2018/07/08(日) 20:17:40.56
145仕様書無しさん2018/07/08(日) 20:19:09.61
>>139
> そもそもアプリにインスタンスが1つなら全部シングルトンになってしまうが一般的なDIコンテナの設計はそんな風にはなってない
> あくまでシングルトンは特別な場合
だから独立したセッションがある場合はセッションごとって書いたろ？
セッション単位とかスレッド単位とか他と独立した処理が
フレームワークなどから開始される場合、その単位で一つ作成されることはあるよ
セッション単位のシングルトンみたいな
だけど一つのクラスやメソッドでインスタンスを複数生成して使うような場合には使えない。 146仕様書無しさん2018/07/08(日) 20:21:40.82
>>141
DIコンテナはファクトリの下位互換ってことか 147仕様書無しさん2018/07/08(日) 20:23:48.57
>>145
やっぱ使いにくいな
DIコンテナよりファクトリの方が柔軟で便利だな
やっぱりDIコンテナは不要なんじゃないか？ 148仕様書無しさん2018/07/08(日) 20:30:29.16
DIコンテナってさインフラへの依存を断ち切ろうってコンセプトに喧嘩売ってるよな
他サービスへの依存は切れるけどDIフレームワークそのものにべったり依存してしまう
Javaのプログラムを.net coreに移植しようとしたらなんか全部のクラスに@Injectとか書いてあんの
普通にFactoryを作ればいいじゃんっての
ほんとDIコンテナってバカみたいだよな
149仕様書無しさん2018/07/08(日) 20:32:24.62
>>148
.NET CoreこそフレームワークレベルでDIフル活用してるだろ 150仕様書無しさん2018/07/08(日) 20:41:08.67
>>147
そもそも使う目的がシステムの何かの機能を実現するために必要だからじゃなくて
DI使っていればクラスに依存せずにインターフェースだけに依存すれば良くなるし、
だから同じインターフェースの違う実装に入れ替え可能
そうしておけば、後々便利なこともあるじゃない？みたいな
今それいらないよね？って突っ込まれること請け合いだからねｗ
クラスを入れ替えたいだけなら、ソースコードを修正すれば十分なのさ
DIは生成するクラスをアプリの実行状態に応じて柔軟に変更可能なものなんかじゃなくて、
生成するクラスを実行の初期化時に決められるってだけだからね 151仕様書無しさん2018/07/08(日) 20:43:00.93
152仕様書無しさん2018/07/08(日) 20:43:49.16
>>149
DIはいいんだよ別に
DIコンテナ(asp.net coreだとServiceCollectionだが)を強制されるのがダメ
まあMicrosoftはまだ@Injectみたいなロックインのための仕組みを盛り込まないだけマシだけど
DIコンテナの制約を意識してオブジェクトモデル設計を変えなきゃいけない場面が時々ある
DIコンテナの罪は大きい
DIそのものは便利で合理的なのにね
DIコンテナがすべてを台無しにしてる
自由が約束されたファクトリーを使うべき 153仕様書無しさん2018/07/08(日) 20:45:46.85
>>150
違う違う
DIは、じゃなくて、DIコンテナは、な
ここ重要な
DIは必要だけどDIコンテナは邪魔 154仕様書無しさん2018/07/08(日) 20:47:25.86
>>151
そうすると、コンストラクタで渡す部分が、
特定のクラスに依存してしまう
そうやって特定のクラスに依存するものが
あちこちにできてしまうと、本末転倒になってしまうから、
DIでは、依存関係を定義する部分をひとまとめにして
そこだけは諦めてクラス名をずらずら書くんだよ。 155仕様書無しさん2018/07/08(日) 20:48:43.32
>>153
DIコンテナを使わないで、手動でDIコンテナの代わりの
コードを書くと、大変なことになるぞ。
メンテナンス性が極端に落ちる 156仕様書無しさん2018/07/08(日) 21:09:50.58
>>154
それ貴方の感想ですよね？
ファウラーの定義にない事を勝手に追加しないでくれますか？ 157仕様書無しさん2018/07/08(日) 21:13:14.96
もっとバカにもわかるように議論してくれ
158仕様書無しさん2018/07/08(日) 21:14:25.18
>>156
いや事実
コンストラクタで渡す場合、以下のように
ClassAはClassBやClassCに依存してしまう
Class A {
foo() {
ClassB b = new ClassB();
ClassC c = new ClassC(b);
}
} 159仕様書無しさん2018/07/08(日) 21:14:31.06
>>155
アンチはDIコンテナだとカバーできない部分があるから、ファクトリを使うんだってさ 160仕様書無しさん2018/07/08(日) 21:19:12.80
>>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
>>152
Microsoftも@inject使ってることすら知らないお馬鹿さん 162仕様書無しさん2018/07/08(日) 21:20:19.53
>>159
> アンチはDIコンテナだとカバーできない部分があるから、ファクトリを使うんだってさ
うん。ファクトリだとDIみたいに依存関係をひとまとめにする部分はないので
メンテナンス性は下がらない。ファクトリは関連するものだけを生成するのでね 163仕様書無しさん2018/07/08(日) 21:24:13.81
164仕様書無しさん2018/07/08(日) 21:24:41.41
>>155
全然落ちんよ
むしろファクトリーのほうが保守性が高い
生成箇所が明確で書いてあることを読めばそれで理解できるから 165仕様書無しさん2018/07/08(日) 21:25:42.22
166仕様書無しさん2018/07/08(日) 21:26:00.64
>>158
ファウラーが定義してるかどうか聞いてるんですけど？
いつもみたいに引用してくださいよ 167仕様書無しさん2018/07/08(日) 21:28:06.71
168仕様書無しさん2018/07/08(日) 21:31:55.83
>>166
はいどうぞ
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
> Service Locator を利用する
> Service Locator の背後にある基本的な考え方は、あるアプリケーションが必要とするであろうサービスの
> すべてを保持する、単一のオブジェクトを用意するというものだ。したがって、今回のアプリケーション用
> ServiceLocator は、必要に応じて MovieFinder を返すメソッドを持つことになる。
> そうなると当然、MovieLister から ServiceLocator への参照が発生してしまい、結果として図3のような依存関係を示すことになる。
169仕様書無しさん2018/07/08(日) 21:32:33.62
>>164
> むしろファクトリーのほうが保守性が高い
そりゃDIは保守性低いんで、
必要な部分にファクトリー使いましょうと
言ってるんだから当然だなｗ 170仕様書無しさん2018/07/08(日) 21:36:17.46
171仕様書無しさん2018/07/08(日) 21:36:49.87
リンク先見ない気がするんでコピペしてみるｗ
<?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
<!-- 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
<!--
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
<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
>>168
コンストラクタで設定しちゃダメって書いてないどころか、
コンストラクタインジェクションの例すら書いてあるんですがw 176仕様書無しさん2018/07/08(日) 21:39:32.86
ここいらで止めといてあげるが、まだ半分ｗ
177仕様書無しさん2018/07/08(日) 21:40:39.93
>>175
コンストラクタで設定したらだめなんて
一言も言ってないけど？
思い込みで発言すんなや 178仕様書無しさん2018/07/08(日) 21:43:15.80
>>177
じゃあ>>140への回答はコンストラクタで設定すれば良い、でFAだな
コンストラクタで渡せばDIコンテナなんて不要なことすら分からないなんてお前はホントにアホだなw 179仕様書無しさん2018/07/08(日) 21:47:59.56
DIの使われ方を見ると依存関係がどうこうというより、
クラスに対する設定を記述しているだけな気がするな
180仕様書無しさん2018/07/08(日) 21:50:34.12
なんでアンチは自分が考えたオレオレDIをファウラーのDIみたいに言うの？
もっと提唱者に敬意を払うべきでは？
181仕様書無しさん2018/07/08(日) 21:51:14.33
オブジェクト指向にしろＤＩにしろ
実際に困ったことありました→ある手法を使ったことでこんなに便利になりました
ってことが明確にわかる実例がないから悪いんだよね
xmlのこのクソなげえ設定ファイルが必要ですがそれを補って有り余る程DIには利点があり
こんなに便利になりましたってのが１ミリもわからない
そこら編を死ぬほど詳しく書いた本とか売れそうな気もするんだけど誰も書かないな
182仕様書無しさん2018/07/08(日) 21:51:21.18
>>178
> じゃあ>>140への回答はコンストラクタで設定すれば良い、でFAだな
コンストラクタで設定するのはnew相当を行うときだ。
質問はnew相当のことをどうやって行うかだ
俺なら、インスタンスの作成をするにはどうすればいい？の答えに
new演算子を使用すると答えるが、
お前は、コンストラクタで設定すればいいって答えるのか？
回答が意味不明だぞ 183仕様書無しさん2018/07/08(日) 21:51:20.69
ハゲは何つってるの？
184仕様書無しさん2018/07/08(日) 21:53:01.50
>>181
実際は新しい言葉作ってバカなPGを手玉に取ってお金を集めちゃう商売だからそんな資料は作れないよ 185仕様書無しさん2018/07/08(日) 21:53:33.94
>>183
それが大事だよね
ここのドカタが何言ってるかよりも 186仕様書無しさん2018/07/08(日) 21:54:32.74
187仕様書無しさん2018/07/08(日) 22:02:25.42
>>182
もともとは>>138の
> MovieLister から ServiceLocator への参照が発生するのがサービスアロケータだろ
に対して、>>140が参照持たないためにはnewするしかないって言ってる
で、その回答として
コンストラクタで渡せばMovieLister から ServiceLocator への参照が発生しません
って言ってるわけ。何が意味不明なの？ 188仕様書無しさん2018/07/08(日) 22:04:07.09
189仕様書無しさん2018/07/08(日) 22:04:51.15
190仕様書無しさん2018/07/08(日) 22:06:45.43
191仕様書無しさん2018/07/08(日) 22:19:21.85
>>187
> コンストラクタで渡せばMovieLister から ServiceLocator への参照が発生しません
だからその場合、どうやってインスタンスを作成するのかって話をしてるんだが？
お前はインスタンス作成後の話しかしてねーじゃねーか
わざとか？
ちゃんと話を読め↓
> ないけど、事実上そうだよ。
> でないとサービスロケーターになってしまう
>
> DIパターンにおけるインスタンスを生成するオブジェクト（通常DIコンテナ）に
> 依存せずにインスタンスを生成するには、上の層でインスタンスを生成してもらわないといけない
> 上の層っていうのはフレームワークに隠蔽されたアクションに相当する処理の開始部分
>
> 「DIパターンにおけるインスタンスを生成するオブジェクト」を上の層以外の
> 部分で使うことは、それに依存してしまうことになってしまい、
> それは事実上サービスロケーターと同じことになる 192仕様書無しさん2018/07/08(日) 22:22:31.15
>>191
サービスアロケータになってしまうと言うのは貴方の感想であって
ファウラーの定義では参照がなかったらサービスアロケータではありません 193仕様書無しさん2018/07/08(日) 22:23:25.10
>>189
いいのか、その話をして？
依存関係を一箇所に書くんじゃなくて、
今は各クラスにアノテーションとして書きましょう
に変わったって言いたいんだろう？ 194仕様書無しさん2018/07/08(日) 22:24:51.24
>>192
残念ながら事実だよ。
手動でnewしてしまうと、依存関係の定義情報が使用できない 195仕様書無しさん2018/07/08(日) 22:27:02.53
>>194
なんでファウラーの定義を離れて勝手なオレオレDIの話をするの？ 196仕様書無しさん2018/07/08(日) 22:27:30.06
197仕様書無しさん2018/07/08(日) 22:31:30.46
DIコンテナが無くてもDIできる、でFA？
198仕様書無しさん2018/07/08(日) 22:32:14.64
>>195-196
はい？ DIの話なんかしてませんよ？
DIにならないって話をしてるんですが
この場合、DIの定義である↓を満たせない
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
DIじゃない方を使いましょうって言ってるんでしょ？ 199仕様書無しさん2018/07/08(日) 22:32:59.99
DIコンテナが無くてもDIできる。
ただしメンテナンス性が大きく下がる
200仕様書無しさん2018/07/08(日) 22:34:25.00
>>199
DIコンテナが無くてもDIできる、でFAね
良かった良かった 201仕様書無しさん2018/07/08(日) 22:35:07.84
そりゃオレオレDIコンテナを作ればできるだろうけど、
こいつ何を言ってるんだろう？
202仕様書無しさん2018/07/08(日) 22:37:03.26
ファウラーのDIをドカタが勝手に独自解釈してるから正しただけだが？
提唱者には敬意を払わないとね
203仕様書無しさん2018/07/08(日) 22:38:07.70
>>201
オレオレDIコンテナって何それ？
ファウラーの定義に出てきますか？ 204仕様書無しさん2018/07/08(日) 23:11:01.67
205仕様書無しさん2018/07/08(日) 23:19:03.24
206仕様書無しさん2018/07/09(月) 08:52:36.11
そうだ！Factoryが生成するインスタンスのClassを、設定ファイルに記述するようにしたらいいんじゃないかな？
207仕様書無しさん2018/07/09(月) 09:18:47.02
そもそもクラス構成なんかそうそう変えないだろ？
208仕様書無しさん2018/07/09(月) 10:50:12.45
DIコンテナもxml設定ファイルもウンコ言語Javaが産んだドカタ文化だろ
Javaのゴミさを理由にDIを貶めてんじゃねーよ
209仕様書無しさん2018/07/10(火) 06:59:02.50
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
DIコンテナと言うよりDecorator
211仕様書無しさん2018/07/10(火) 08:14:56.54
>>209
Factoryで責務分割すると、どういうこーどになるの？ 212仕様書無しさん2018/07/10(火) 08:15:21.22
213仕様書無しさん2018/07/10(火) 08:21:14.51
知ったかアンチ
214仕様書無しさん2018/07/10(火) 20:03:09.78
>>211
> Factoryで責務分割すると、どういうこーどになるの？
違う違う。Factoryで責務分割するのではない
依存関係を外部から注入するから、こういう結果になるということなんだから
依存関係を埋め込むことで、シンプルになる。
依存関係を埋め込んでるだけでSOLID原則を破るわけではないので問題はない
（SOLID原則には依存関係を埋め込んではいけないなどという原則は無い）
またFactoryを使うなって話でもない。設計上必要な場所にはFactoryを使う
単に依存関係を分離するためにDIだかFactoryだかを使わないって話 2152142018/07/10(火) 20:03:50.30
216仕様書無しさん2018/07/10(火) 23:16:15.34
スマンちょっと研究したらDecoratorふつうに出来たわ
DIコンテナは神。ファクトリーはゴミという結果になってしまった
217仕様書無しさん2018/07/10(火) 23:28:22.82
218仕様書無しさん2018/07/11(水) 01:09:38.82
>>216
どうやって？ DIではDecoratorはできないはずだけど？ 219仕様書無しさん2018/07/11(水) 04:10:40.54
220仕様書無しさん2018/07/11(水) 10:23:42.31
バカには出来ないってことだろね
221仕様書無しさん2018/07/11(水) 10:38:27.10
>>219
DIは依存関係を注入するだけだからだよ 222仕様書無しさん2018/07/11(水) 10:43:43.24
依存関係注入が悪い翻訳だからね
加えて
コンポーネントはパラメーターで渡そう
コンポーネント組立は設定ファイルで
いや属性でやるだろ
とか議論の軸も整理されてない
223仕様書無しさん2018/07/11(水) 12:24:16.60
ファウラーのDIが、DIの正しい定義だって
言ってるのにそれを無視するからこうなるんだよ
ファウラーは依存関係を分離するために
依存関係を注入する側の仕組みをどうするかの話をしてるのに
依存関係が注入される側の仕組みの方を見て
注入する側の仕組みは何でも構わない、変数の型をインターフェースにしておいて、
内部でnewしなければなんでもDIだって言ってるから意味不明なことになる
議論の筋の整理のレベルじゃなくて、間違った理解をしてる
224仕様書無しさん2018/07/11(水) 13:32:11.18
>>223
ファウラーは依存関係を注入する側の仕組みについてなんて定義してるの？
って聞いてみたけど、また引用じゃなくて独自解釈を垂れるんだろうな...w 225仕様書無しさん2018/07/11(水) 14:42:49.06
>>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
依存関係を解決する側はなんでもいい
ファクトリーでもいいし
DIコンテナでもいい(というかこれはモロにファクトリー)
貧者のDIでもいいし
メインで初期化でもいい
あくまでオプション
227仕様書無しさん2018/07/11(水) 15:26:33.40
Dependency Injection の基本的な考え方は
って書いてるのに、オプションとか意味不明
基本的な考え方ぐらい理解しましょうや
228仕様書無しさん2018/07/11(水) 15:39:36.80
工場（ファクトリー）に鉄製品を作る機能をもたせたものを製鉄所というのであって、
工場だったら必ず製鉄所になるわけじゃない。
依存関係を解決する機能をもたせたものがDIなのであって
FactoryだったらかならずDIコンテナになるわけじゃない
229仕様書無しさん2018/07/11(水) 16:41:44.12
もうさ、用語として組み込み系で使いづらいんだよなぁ
230仕様書無しさん2018/07/11(水) 17:26:15.92
>>227
基本的な考え方は依存するクラスをインターフェースに置き換えて外部から与えましょうってだけ
ここまでがDIの本質
でもそうすると規模が大きくなった時に外部から与える処理自体が複雑になってくるよね
って副次的な課題に対しての解決策が幾つかあって
それがファクトリーやDIコンテナや貧者のDI
DIを語る上ではこれらは必須ではない
という意味でのオプション 231仕様書無しさん2018/07/11(水) 18:02:05.87
>>230
> 基本的な考え方は依存するクラスをインターフェースに置き換えて外部から与えましょうってだけ
いえ、
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
です 232仕様書無しさん2018/07/11(水) 18:34:13.08
なるほど
DIはMovieFinderだったのか
233仕様書無しさん2018/07/11(水) 18:44:24.82
Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、
234仕様書無しさん2018/07/11(水) 18:52:10.97
ということはつまりMovieFinderですね
235仕様書無しさん2018/07/11(水) 18:56:03.57
>>231
なんか、DI嫌いな人が、DI使ってる人を「マーチンファウラーを盲信する教条主義者」として貶めようとしてるようにしか見えない。 236仕様書無しさん2018/07/11(水) 19:15:13.17
もともとな、外部から依存関係を与えるなんてことをしなければ、
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
いやいや。依存性が切れてないバージョンを出してきて「長くなったでしょ？」って……
238仕様書無しさん2018/07/11(水) 19:27:06.90
DIContainerの生成メソッドを自分で呼び出すことはないよ
239仕様書無しさん2018/07/11(水) 19:29:46.80
> DIContainerの生成メソッドを自分で呼び出すことはないよ
そりゃフレームワークが呼び出してるからな
そのフレームワークが呼び出せるようにするためには
絶対に依存関係の定義が必要になるわけよ。
長ったらしいApplicationContext.xmlのようなやつな
240仕様書無しさん2018/07/11(水) 19:31:40.65
241仕様書無しさん2018/07/11(水) 19:32:11.19
242仕様書無しさん2018/07/11(水) 19:32:40.31
直接インスタンス化すると開発する時に何かと不便じゃん
インフラが正常稼動してないと開発できない
ちょっとした動作確認にも時間がかかる
ビルド時間が長すぎる
243仕様書無しさん2018/07/11(水) 19:33:08.29
>>240
反論しろよｗ
>>241
クラス自体に依存関係をアノテーションで埋め込むんですよね？ｗ
依存関係をクラス自体に書くわけですねーｗ 244仕様書無しさん2018/07/11(水) 19:33:37.95
245仕様書無しさん2018/07/11(水) 19:34:43.07
>>244
それ以外ないよ？
あるって言うなら言ってくれてもいいけど、
でもないからな～な。何を言うつもりだろー？ 246仕様書無しさん2018/07/11(水) 19:35:29.14
>>242
開発中なんだからソースコード修正して開発すれば良いんだよ 247仕様書無しさん2018/07/11(水) 19:47:04.74
248仕様書無しさん2018/07/11(水) 19:47:37.69
249仕様書無しさん2018/07/11(水) 19:51:21.35
アンチは妄想に囚われすぎ
250仕様書無しさん2018/07/11(水) 19:56:03.42
べつにxml書くスタイルでも、古くはなくない？
251仕様書無しさん2018/07/11(水) 19:57:43.60
今の王道DIComtainerは単純な登録タイプ
このインターフェースはこのタイプを生成しろ
あのインターフェースはこのファクトリーデリゲート使って生成しろ
みたいなやつね
KISSの原則に従って無意味な設定ファイルや制御しにくくわかりにくいアノテーションは駆逐された
シンプルなコードで普通にコンテナをビルドして実行するだけ
252仕様書無しさん2018/07/11(水) 22:30:44.35
253仕様書無しさん2018/07/11(水) 22:32:45.64
254仕様書無しさん2018/07/12(木) 05:09:02.12
>>251
> シンプルなコードで普通にコンテナをビルドして実行するだけ
ふーん？そのコンテナの名前は？
何で隠すの？ 255仕様書無しさん2018/07/12(木) 05:12:09.92
256仕様書無しさん2018/07/12(木) 05:21:33.17
257仕様書無しさん2018/07/12(木) 06:32:20.62
>>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
>>257
その理屈で、
> MutablePicoContainer pico = configureContainer();
> MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
これがService Locatorにならないことの説明はできるの？
picoの参照を持ってしまっているよね？
答えを言うと、各クラスの内部で参照を持ってしまうことがService Locator 259仕様書無しさん2018/07/12(木) 08:45:59.54
うん>>236は外部から依存関係を与えずに
各クラスの内部で参照を持つと言っているからService Locator 260仕様書無しさん2018/07/12(木) 08:52:46.71
> 各クラスの内部で参照を持つと言っているからService Locator
言ってないよね？
サンプルコードもMyObjectの外部でしか使ってないよね？
261仕様書無しさん2018/07/12(木) 08:54:37.27
こう書かないと理解できないのかな？
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
>>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
これぐらいDIコンテナを自分で作ったことがあれば
わかると思うんだけどな。
264仕様書無しさん2018/07/12(木) 09:36:10.66
> 内部で以下相当のことをやることが可能になる
内部っていうのは、DIContainer.create関数内部って話ね。
MyObjectやA、B、Cクラスのことではないぞ
265仕様書無しさん2018/07/12(木) 10:09:47.52
お前らコテハンつけろ、誰が誰に何言ってるのかわからん。
とくに皮肉っぽいこと言うやつと、
皮肉言われてるやつは、コテハン必須な。
266仕様書無しさん2018/07/12(木) 10:25:40.51
アンチは分かりやすくドカタってコテハンつけると良いぞ
267仕様書無しさん2018/07/12(木) 10:34:11.16
>>262
＞obj = new MyObject(); を
＞obj = DIContainer.create(MyObject); こう書けるようにするためには
だからそれService Locator
依存を注入される側でDIContainerの参照持ってるから 268仕様書無しさん2018/07/12(木) 12:16:33.28
DIContainerとServiceLocatorの区別もついてないやつがDI DIって騒いでたってこと？
269仕様書無しさん2018/07/12(木) 13:53:06.70
>>267
> 依存を注入される側でDIContainerの参照持ってるから
依存を注入される側ってどれのこと？
具体的にクラス名言って 270仕様書無しさん2018/07/12(木) 13:54:17.71
>>268
だろうね。
依存性を注入される側のコードなんて書いて無いのに
注入される側にDIContainerの参照があるとか
幻が見えてるようだしｗ 271仕様書無しさん2018/07/12(木) 14:22:31.54
>>268
> DIContainerとServiceLocatorの区別もついてないやつがDI DIって騒いでたってこと？
まさにそれがスレタイの狙い
DIとService Locatorの区別ができる、つまり違いを知ってる人は
Service Locatorはこう～だけど、DIはこう～とDIの本質を言うことができる
コンストラクタで依存しているオブジェクトを渡すという構造は
単に依存関係を分離した構造というだけで、依存関係を注入する方法を表していない
独立したオブジェクトをAssembler(組み立て係)として用意して注入する方法こそがDIなわけだよ
依存性の注入 = Dependency Injection なんだから 272仕様書無しさん2018/07/12(木) 14:36:24.22
それって、ファクトリー＋コンテナ？
273仕様書無しさん2018/07/12(木) 14:47:58.38
>>272
GoFのデザインパターンにあるのはFactory MethodとAbstract Factoryであって
ファクトリーもコンテナもないので、そう聞かれても正確な答えにはならない
ファクトリー = オブジェクトを生成するもの
コンテナ = 何かの入れ物
っていうアバウトな定義でいいのであれば、その通りだが。
更に言うなら「ファクトリー＋コンテナ」には、インターフェースの実装を
生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が
抜けてるので「ファクトリー＋コンテナ＋依存関係の解決」がDIコンテナと言える。
これに実際のDIコンテナはAOPの機能がついてたりするんだがこっちはおまけだな 274仕様書無しさん2018/07/12(木) 20:26:31.22
>>271
Service Locatorにも組み立て係いるんだけど？ 275仕様書無しさん2018/07/12(木) 20:49:03.06
その組立係を何処から参照しているかの違いですね
276仕様書無しさん2018/07/12(木) 20:57:48.71
何回言えば区別できるようになるんだ
277仕様書無しさん2018/07/12(木) 21:01:47.76
言っただけで世界が平和になったらいいね
278仕様書無しさん2018/07/12(木) 21:07:41.83
人間には感情があるからね
279仕様書無しさん2018/07/12(木) 21:08:13.57
人類を滅ぼしたいね
280仕様書無しさん2018/07/13(金) 00:17:32.78
281仕様書無しさん2018/07/13(金) 09:17:22.69
おまえがたひれば相対的に世界が滅亡したようなものだぞ。
282仕様書無しさん2018/07/13(金) 22:02:01.14
>>280
俺から反物質が生成されるまで生きてみる 283仕様書無しさん2018/07/14(土) 11:09:10.34
JavaScriptのDIコンテナはどれですか？
284仕様書無しさん2018/07/14(土) 12:30:26.98
285仕様書無しさん2018/07/17(火) 00:02:57.12
終わりですか？
286仕様書無しさん2018/07/17(火) 06:05:16.35
287仕様書無しさん2018/07/17(火) 06:11:34.16
最後の話題がこれ
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
289仕様書無しさん2018/07/17(火) 06:48:57.74
インターフェースで結合度を下げる->SLもDIも関係ない
実装インスタンスをクラスの外部で生成して渡す-> DI
注意: つまりSLはDIではない
DIのための生成手順を管理->ファクトリー
ファクトリーの実装パターンの1つ->DIContainer
290仕様書無しさん2018/07/17(火) 10:25:22.27
これも忘れずに
GoFのデザインパターンにあるのはFactory MethodとAbstract Factoryであって
ファクトリーもコンテナもないので、そう聞かれても正確な答えにはならない
ファクトリー = オブジェクトを生成するもの
コンテナ = 何かの入れ物
っていうアバウトな定義でいいのであれば、その通りだが。
更に言うなら「ファクトリー＋コンテナ」には、インターフェースの実装を
生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が
抜けてるので「ファクトリー＋コンテナ＋依存関係の解決」がDIコンテナと言える。
これに実際のDIコンテナはAOPの機能がついてたりするんだがこっちはおまけだな
291仕様書無しさん2018/07/17(火) 10:42:01.75
パターンをそんなに厳密に使ってる奴居るんだw
292仕様書無しさん2018/07/17(火) 14:22:13.35
デザインパターンは、プログラマの間で正確に意味を伝わるようにした
共通の用語なんだから当然。
それに対してファクトリーはデザインパターンではなく正確な用語じゃない
だから意味が正確に伝わらない。
それを言っておかないと、ファクトリーとDI が同一のものとか言い出しかねないからな。
ファクトリーにオブジェクトのコンテナと依存関係を解決したものがDI
通常ファクトリーといったらオブジェクトの生成ぐらいしか意味を持たない
（つまりコンテナ機能はないので毎回作成だし、依存関係の解決もしない）
293仕様書無しさん2018/07/17(火) 14:24:12.12
デザインパターンが実装まで定義してるなんて初耳だな。
294仕様書無しさん2018/07/17(火) 14:31:49.23
実装を定義してるなんて書いてないが？
さっきから言葉の定義の話しかしてないよね？
ファクトリーはこうで、DIはこうって
295仕様書無しさん2018/07/17(火) 20:23:57.65
だって、DIって、実装レベルの話だろ？
296仕様書無しさん2018/07/17(火) 20:47:34.95
設計手法かな
297仕様書無しさん2018/07/17(火) 21:33:00.27
298仕様書無しさん2018/07/17(火) 21:46:46.14
ドリルインポ
299仕様書無しさん2018/07/17(火) 21:59:55.68
設計だよなぁ。DIの実装なんて各フレームワークで全然違うし
300仕様書無しさん2018/07/17(火) 22:01:41.16
DI=ドリルインポ
301仕様書無しさん2018/07/17(火) 22:06:47.83
大好きインぽ
302仕様書無しさん2018/07/17(火) 22:11:16.15
でも明らかに粒度が違うよなぁ
デザインパターンが基本設計なら、DIは詳細設計だろ？
なんで同じステージで語るの？
303仕様書無しさん2018/07/18(水) 00:51:59.32
コンポーネントの切り分けと依存関係は基本設計やろ
304仕様書無しさん2018/07/18(水) 03:30:15.55
DI厨はこういう理屈であることがわかったなｗ
席は一つしかありません。
基本設計の椅子にデザインパターンが座りました
空きは詳細設計のみです。
だからDIは詳細設計になります。
詳細設計というのはプログラミングのことです。
プログラミングというのは実装です。
だからDIは実装になります
DIが何をやるかには興味がありません。
詳細設計しか椅子がないのだからDIは実装です
305仕様書無しさん2018/07/18(水) 08:36:06.34
UMLで言うところの、黒いひし形か白いひし形かの違いを
延々と言い合うスレって事でいい？
306仕様書無しさん2018/07/18(水) 08:48:55.14
キチガイはスルー
307仕様書無しさん2018/07/18(水) 10:19:28.61
>>305
違うな。ひし形の色だけじゃない。
すべての形、その数、依存関係、まあ要するに
設計なんだが、それを言い合うスレだ 308仕様書無しさん2018/07/18(水) 10:20:02.92
デザインパターンが基本設計なら、DIも基本設計だろ？
同じステージの話なんだから
309仕様書無しさん2018/07/18(水) 10:22:29.33
いやいや、どう見てもDIは実装の話だろ？
310仕様書無しさん2018/07/18(水) 10:35:41.07
どうみてって何を見たの？
見た実装とやらを言ってみて
311仕様書無しさん2018/07/18(水) 10:37:34.47
だって実装の話しかして無いじゃん。
312仕様書無しさん2018/07/18(水) 10:38:36.20
だから見た実装とやらを言ってみて
ま、答えずに逃げてる所みれば
どういうことか、わかりますけどねｗ
313仕様書無しさん2018/07/18(水) 10:39:15.30
お前が見た「実装」とやらを持って
上司に「実装」しました！って言ってこいよｗｗｗ
314仕様書無しさん2018/07/18(水) 10:40:41.89
>>312
は？
このスレのどこを見ても実装の話しかして無いだろw 315仕様書無しさん2018/07/18(水) 10:40:57.66
ほらまた逃げたｗ
316仕様書無しさん2018/07/18(水) 12:10:28.59
よこからスマンけどDIってなーに？
317仕様書無しさん2018/07/18(水) 12:23:53.14
>>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
319仕様書無しさん2018/07/18(水) 21:57:47.93
キチガイはスルー
320仕様書無しさん2018/07/21(土) 21:55:01.84
1つ言えるのはオブジェクト指向のなんかよりも
データ構造とアルゴリズムの方がよっぽど重要だということ。
昔はオブジェクト指向の勉強を頑張っていたけどそのときは
全然プログラミングがうまくならなかった。
現代の世の中はガチガチに設計されたライブラリを使って
コードを書くだけだから生半可なオブジェクト指向の知識なんて
ゴミ同然だよ。80年代90年代に考えられた思想とか、もうゴミに
なってしまった思想が多くて有害だよ。
結局現場でやることは「メソッドの使い方を求めてQiitaやStack OverFlowを
漁って成功するコードを見つけるまで疲れ果てる」ことに変わりはない。
せっかく勉強した内容が時代遅れで「裏切られる」ことのほうが多い。
321仕様書無しさん2018/07/21(土) 21:55:37.69
一方、データ構造とアルゴリズムをガッツリと勉強してから
様々なデータ構造の使い方、問題の解決がうまくなった。
ブロックチェーンのアルゴリズムの理解や
データ分析の数学的演算がコーディング
できるようになってプログラミングが格段に楽しくなった。
スマートにオブジェクト指向で設計する力なんかより
「ゴリゴリとアルゴリズムを書く力」の方がよっぽど重要。
「再利用性」？「変更の影響」だって？そんなものゴミだね。
それは自分以外の人間のメリットのための技術であって、
自分へ還元されるためのメリットではない。
再利用性は自分の書いたコードなら信頼できるしコピペして使えばいい。
自分の書いたコードのコピペは全然ありだと思う。
適したメソッドが見つからなかったらQiitaを漁ったりせずに
自分でゼロから実装したほうが速い。
その場で手っ取り早くコードを生成しているから、
どんな既存コードにも頼っていないから俺の実装したコードは
依存性は低い。
322仕様書無しさん2018/07/21(土) 22:01:01.01
天才が作ったライブラリないとお前何にもできないじゃん
323仕様書無しさん2018/07/21(土) 22:23:31.55
324仕様書無しさん2018/08/22(水) 21:32:26.82
そんなにアルゴリズム好きなら
量子アルゴリズムでも探せば喜ばれるぞ
325仕様書無しさん2018/09/18(火) 12:10:45.11
diは無知なんだが、これは品質確保のための手法ってことで良いの？
未熟な奴に任せて設計させるとカオスな構造を生み出すから
分かってる奴があらかじめ枠組み組んでここでやれって言う奴？
326仕様書無しさん2018/09/18(火) 12:18:07.62
前提条件として、どんな開発場面を想定してんだろ？
このスレ見てても分かる通り、前提条件の共有も分からんのが多いだろ？
そのこと自体が、何かしらの標準や型が必要であることを示唆してるよね
327仕様書無しさん2018/10/15(月) 21:19:07.09
私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
328仕様書無しさん2018/10/20(土) 20:45:19.62
329仕様書無しさん2018/11/04(日) 11:30:33.87
