【Java】DIコンテナって本当に便利か？

**デフォルトの名無しさん** · 2008/08/20(水) 23:23:26

インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどｗ

**デフォルトの名無しさん** · 2008/11/05(水) 00:52:35

253だけど継承にしたって結局フレームワーク側がどうやって
継承元のメソッドを呼び出してるかは継承関係追っかけるだけじゃ
わからないから、DIも継承も関係ないや、と思った。まる。

**デフォルトの名無しさん** · 2008/11/05(水) 23:23:27

>>253
そりゃあんましイミないけど
気持ちは分かる

**デフォルトの名無しさん** · 2008/11/06(木) 02:10:35

>>253
>実行時になにが起こるかわかりにくいよねえ。

そもそもDependency Injectionというのは
「分からないでもいい」という粗結合を実現するためのもの。
呼び出し側はインターフェースだけを知っていればよい。
理想論ではあるけれども。

おそらく実装に過度に依存したコードを書いているんだろうなと思う。

**デフォルトの名無しさん** · 2008/11/06(木) 05:30:53

いやあ、デバッグの時に処理が追いにくいのがなんかなあって。
フレームワークのドキュメント調べてる時間で自分で書いた方が
早かったじゃんって思ったり。フレームワークの全機能使う訳じゃ
ないからさ。

**デフォルトの名無しさん** · 2008/11/07(金) 00:43:44

>>265
DIコンテナに限らない話だな

**デフォルトの名無しさん** · 2008/11/08(土) 16:22:02

技術的な話として便利かどうかと言えば明らかに便利
ただし、便利なら採用できるかといえば、それは次元の違う話
それだけ

**デフォルトの名無しさん** · 2008/11/08(土) 18:56:25

まぁでもSpringやSeasar2採用してるプロジェクト多いでしょ
と思ったら1割くらいか…

**デフォルトの名無しさん** · 2008/11/08(土) 19:07:59

DI支持派の主張で疑問なのは、

インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
そこでDI登場、と素っ飛ぶところ。

DIという考えが生まれるよりも遥か昔から、プログラマはインタフェースと実装を分離していたわけだが。

**デフォルトの名無しさん** · 2008/11/08(土) 19:43:28

それやってる奴って多分DI使ってる奴の100分の1以下だろ
だったら俺は昔からMVCに分けてたとかORマッピングやってたとかなっちゃうぜ

**デフォルトの名無しさん** · 2008/11/08(土) 19:49:21

昔からインタフェースと実装の分離をしているような奴なら、
自前のサービスロケータやDIコンテナモドキも作っているわけで。

だったら、そこでDI登場、と素っ飛んでしまっても何も
問題は無いと思う。

**デフォルトの名無しさん** · 2008/11/08(土) 19:53:27

俺はJavaなんて登場する前から仮想マシンを作って型に厳格な言語を構想していたが

**デフォルトの名無しさん** · 2008/11/08(土) 21:43:11

>>269
>インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
この｢インタフェースと実装の分離｣を聞きながら、
｢はあ？その理想論をどーやって現場で使えっつうんだよ！！｣
って思ってたところに
>そこでDI登場、と素っ飛ぶところ
DIが出てきて、
｢あーなるほどね、そーやるのね｣
って感じでナットクされたってこと。

インターフェイスとインプリメンテーション
みたいに
理論と実践をやってみせたのがDI。

**デフォルトの名無しさん** · 2008/11/09(日) 06:08:42

>>インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
>この｢インタフェースと実装の分離｣を聞きながら、
>｢はあ？その理想論をどーやって現場で使えっつうんだよ！！｣
>って思ってたところに

そういう人のための道具ということでよろしいですか？

**デフォルトの名無しさん** · 2008/11/09(日) 12:29:57

>>269
それまではService Locatorをつかってた。
昔のEJBとかね。
だから、最初はDIじゃなくてInversion of Control（制御の反転）コンテナとか軽量コンテナとか呼ばれてたんだよ。

**デフォルトの名無しさん** · 2008/11/09(日) 12:42:13

DIって自動テストツールを使った、単体テストの時めちゃくちゃ便利
むしろDIが無いと出来ないといってもいいな

**デフォルトの名無しさん** · 2008/11/09(日) 15:36:38

>>274
お前は独自フレームワーク(笑)でも作って一人で頑張って

**269** · 2008/11/09(日) 20:25:58

>>275
流石にファウラーの記事くらいは読んで言ってるよ。日本語訳もあるんだし

そもそもファウラー自身がメリットデメリットの話を書いているのに
素人が何の検討もなしに流行に乗っているだけという感じが。

巷が騒がしいから俺も遊んでみる→なんかコード書かなくて楽じゃね？→DIﾜｼｮｰｲ
という狂宴

**デフォルトの名無しさん** · 2008/11/09(日) 21:11:19

>>275
なんだ「自分は分かってる」君か。
臭いよ。

**デフォルトの名無しさん** · 2008/11/10(月) 00:36:54

ループの御燗

**デフォルトの名無しさん** · 2008/11/10(月) 19:44:31

めんどくせー。
AOPが簡単にできるだけで良いじゃねーか。

**デフォルトの名無しさん** · 2008/11/11(火) 20:30:12

半端に知ってる人が詰まっても知識の押し付けあいになっちゃうのですね。
あんたらばかぁ？

**デフォルトの名無しさん** · 2008/11/11(火) 23:53:04

人が詰まるw

**デフォルトの名無しさん** · 2008/11/11(火) 23:57:24

詰まらないスレだな。

**デフォルトの名無しさん** · 2008/11/12(水) 00:27:39

> DIコンテナって本当に便利か？

ひがちゃんに聞いてみれば？
たぶん「ホットデプロイが！！！」しか言わないと思うが。

**デフォルトの名無しさん** · 2008/11/12(水) 00:29:46

DIコンテナ要らないからホットデプロイだけくれよ。

**デフォルトの名無しさん** · 2008/11/12(水) 00:32:52

>>286
javarebel

**デフォルトの名無しさん** · 2008/11/13(木) 17:00:25

あると便利だけどねー

**デフォルトの名無しさん** · 2008/11/22(土) 23:40:00

俺みたいな古いＰＣしか持ってないと「軽量」ってことが、すごーく高価値なんだよね。
GlassFishやJBossやら動いちゃくれても、現実問題耐えられんのよｗ画面真っ白けにしてお休みしちょうし。
かと言ってxmlヘルへの逆行もごめんだしで、もうS2アディクティブですよ。

**デフォルトの名無しさん** · 2008/11/24(月) 22:44:02

>>289
J2EEコンテナ(GlassFish , JBoss vs Tomcat , jetty) と
フレームワークの違いを混ぜてないか?

DI コンテナは、フレームワーク(ライブラリ)であって、J2EE コンテナではないだろう。

**デフォルトの名無しさん** · 2008/11/24(月) 22:50:43

依存性注入(DI)は成功したか？
http://www.infoq.com/jp/news/2007/12/does-di-pay-off

この記事でも、DIはテストする際の有利さ(便利さ)が語られている。
(逆に言えば、それしかない、という意見も紹介されている)

**デフォルトの名無しさん** · 2008/11/25(火) 01:12:27

比較的導入が進んでる海外でも
この手のしょうもない議論がまだ繰り返されてるんだな。
OOPも初期は無駄な議論多かったよな。
今は自明だから議論が発生しないか、
あるいは分かってふりして黙ってるかの二択だが。

**デフォルトの名無しさん** · 2008/11/27(木) 00:25:49

だが実際問題、XMLは自動記述してくれないと嫌にならないか？結局というかRubyonRailのようなのが人気なのもJavaにはこんな問題もあるからだと思う。

**デフォルトの名無しさん** · 2008/11/27(木) 01:30:13

XML書くのが嫌ならguice使えばいいじゃん

**デフォルトの名無しさん** · 2008/11/27(木) 02:19:09

クラス図書くコストの1/3でクラス間の相関が記述出来る。
XML書くことの何が面倒なのか理解不能。

**デフォルトの名無しさん** · 2008/11/27(木) 02:30:09

実際XML地獄が深刻なので回避しようというのがトレンド

**デフォルトの名無しさん** · 2008/11/27(木) 08:42:29

今時のSeasar2プロダクトは規約で縛ってよっぽどのことがないとXML書かないけどな
SAStrutsとか

**デフォルトの名無しさん** · 2008/11/27(木) 21:00:58

Seasar２はいいな。確かに楽をさせてくれる。

**デフォルトの名無しさん** · 2008/11/27(木) 21:18:39

XMLヘルはHibernateやSpringやantのせいだろ。
あいつらは設定ファイルやデータファイルの域を逸脱してる。
web.xmlとstruts-config or faces-configだけなら大して難しくない。

**デフォルトの名無しさん** · 2008/11/27(木) 23:07:03

antを責めるのは筋違い

**デフォルトの名無しさん** · 2008/11/28(金) 02:24:15

>>299
つか、いまどきHibernateやらSpringやらもアノテーションだろ。

**デフォルトの名無しさん** · 2008/11/28(金) 02:24:51

>>300
antの、XMLで条件分岐や繰り返しや変数代入ってプログラム書かされるのはイヤになんない？

**デフォルトの名無しさん** · 2008/11/28(金) 07:34:04

XML地獄とか、いつの時代の話をしているんだよ、っという感はある。

**デフォルトの名無しさん** · 2008/11/29(土) 09:15:28

例え自動生成してたとしても、XML地獄がそこに存在してるんだよ。

**デフォルトの名無しさん** · 2008/11/29(土) 09:26:57

今はXML地獄ではなくて、アノテーション地獄だろ。

**デフォルトの名無しさん** · 2008/11/29(土) 10:14:29

ＸＭＬよりはマシっしょ、とつられてみる。

**デフォルトの名無しさん** · 2008/11/29(土) 10:49:33

アノテーションはその場に書いてある
XMLは違うファイルをいちいち開いてみなければならない

**デフォルトの名無しさん** · 2008/11/29(土) 12:18:43

Javaは複雑化し過ぎ。

**デフォルトの名無しさん** · 2008/11/29(土) 16:30:43

>>307
俺は逆だと思う。
XML地獄は、設定をすべて一箇所にまとめておける。
アノテーションは、ソース開いてみないとわからない。

トランザクションなどの挙動を変えるときに、アノテーションはソースコードを編集しないといけないが、
XMLの場合は、設定ファイルをいじるだけ。

DIコンテナが登場した初期の思想、「設定をソースから追い出す」を、アノテーションは壊してしまっていると思う。

※アノテーションがすべて悪いといっているわけではない

**デフォルトの名無しさん** · 2008/11/29(土) 21:06:32

>>309
言いたい事を俺はどこまで理解できるか覚束ないレベルなんだが、
たとえばO/Rマッピングが一切のSQL文の排除を理想とするなら、SQL文定義ファイルは邪道になっちゃうよね。
設計思想に理想はあるべきでも、ほどよく妥協させてくれる仕組みがあるのが一番と思うんだが。
設定を一切合切ソースから追い出すのに、時間をかけすぎるくらいなら少しあってもいいんじゃ。コードの形式美を追求するためだけに書く人間が人生を浪費させられるんじゃねｗ
最後のひと言※があるからわかっちゃもらえると思う。俺はもうXMLオンリーの世界に帰りたくないｗ
なーんて。

**デフォルトの名無しさん** · 2008/11/30(日) 05:31:11

eclipseみたいなIDEで編集してwarに固めてデプロイするのに
ソースいじったらコンパイルが必要とかはもうデメリットじゃないと思う。
ロジックの階層に応じてxmlなりアノテーションなりにまとめておければ
いいんじゃないの？設定ファイルにif文や変数いれたりアノテーションに
ビジネスロジック入れるようになるとやりすぎだと思う。
アノテーションでvalidateするのもvalidate処理が分散してちょっと嫌。

ORMはSQLを排除するんじゃなくて、速度を気にしないでいいところは
自動生成しちゃおうよって事だと思う。チューニングが必要なSQLだけ
外部ファイル書き出しでいいでしょ。つかみんなそうやってない？

**デフォルトの名無しさん** · 2008/11/30(日) 13:46:22

>>309
トランザクションの挙動みたいにアプリケーション横断なものは、それはそれでまとめておけばいいだろ。

**デフォルトの名無しさん** · 2008/11/30(日) 15:05:23

開発中の一覧性というなら、アノテーションの使用状況みればいい。
Seamみたいにカスタムアノテーションで共通設定をまとめれれば、設定を一箇所にまとめておける。
>>309 はアノテーションの使い方や、設定とアプリケーション構成記述の違いをわかってないだけではないか？

**デフォルトの名無しさん** · 2008/11/30(日) 23:34:11

派生開発や保守対応での既存ソースコード変更には厳格な手続きが必要で神経質になる客先が多いし、
アノテーションが散らばったソースコードを元にライブラリマイグレーションする事を考えると鬱になる。
5年前に良いと言われていたものを今見てみるとひどいだろ？ 5年後はどう？って感じるのも事実。

**デフォルトの名無しさん** · 2008/12/01(月) 01:15:16

で、それがXMLで設定なら解決できるというのは、能天気すぎやしないか？

**デフォルトの名無しさん** · 2008/12/01(月) 07:21:26

XMLで設定すれば解決できるなんて一言も言ってないが？

**デフォルトの名無しさん** · 2008/12/04(木) 14:45:42

>>291
>これは実際Strategyパターンなのです。依存性注入は（私の見るところ）基本的にひとまとめに使われるStrategyパターンです。

同意。

**デフォルトの名無しさん** · 2008/12/07(日) 17:52:43

自動テストツール使わないなら、
DI使ってる意味が無いという事が分からない低能が多くて困る
流行ってるらしいからとかって理由だけでDI導入すんな！

**デフォルトの名無しさん** · 2008/12/07(日) 18:25:47

（　ﾟдﾟ）ﾎﾟｶｰﾝ

**デフォルトの名無しさん** · 2008/12/07(日) 19:21:05

まぁこんなもんだろ・・
一般のプログラマの能力なんて。

**デフォルトの名無しさん** · 2008/12/07(日) 21:38:30

318はどう見ても釣り

**デフォルトの名無しさん** · 2008/12/07(日) 23:24:37

全部のクラスに頑張ってログ出力書いたりログインチェック書いたりしたいんだろう

**デフォルトの名無しさん** · 2008/12/07(日) 23:36:21

>>322
それは、AOPの機能じゃん。
まぁ、AOPのためにDIがあるといってもいいのかもしれないけど。

**デフォルトの名無しさん** · 2008/12/07(日) 23:47:49

まぁ純粋にDIだけ使ってるのって無いよね
SeasaもSpringも
EJBは知らんけど

**デフォルトの名無しさん** · 2008/12/08(月) 00:41:32

今どきトレースログとか書くの？
サービスクラスだけじゃなくて？

**デフォルトの名無しさん** · 2008/12/08(月) 01:51:40

まあ、書くこともあるんじゃない？
俺は書かんけど。

**デフォルトの名無しさん** · 2008/12/10(水) 12:40:10

Ｎ１マッピングがめんどい。

めんどい。

**デフォルトの名無しさん** · 2008/12/10(水) 15:43:35

ログインチェックだってDI使わなくても
filter挟んだりベースクラスでやるよね。
全部のクラスにコピペする人なんてさすがに見たこと無い

**デフォルトの名無しさん** · 2008/12/10(水) 17:26:32

いやそれAOPでやることだし。DIじゃないよ

**デフォルトの名無しさん** · 2008/12/10(水) 17:29:43

>>328
filter は HttpServlet に依存するが、
DI にすることで、HttpServlet に依存しない環境でもログインチェックをすることができる。

たとえば、業務機能は、web 画面でもバッチでも Service クラスの execute() を実装する、
みたいな方針になっているとき。

バッチにも実行ユーザという概念があったときは、filter にせず DI でのやり方にすることで、
web画面でもバッチでも処理方式を統一することができる。

こうしておくと、web 画面の Service クラスのテストを、
Servlet コンテナを立ち上げずに JUnit 等から単体駆動することもできる。

**デフォルトの名無しさん** · 2008/12/10(水) 18:18:38

いやだから
DI以前だってベースクラスの一カ所に実装しておくから、
全クラスにコピペするような馬鹿は見たこと無いんだけど、
という事が言いたいんだけど理解してくり

**デフォルトの名無しさん** · 2008/12/11(木) 01:58:01

各メソッドを同じ前後処理でつつむときどうするんの？
AOPでできるとか言うが、AOPの実現手段としてDIがいいってことじゃねぇの？

**デフォルトの名無しさん** · 2008/12/11(木) 02:02:12

ぶっちゃけDIの中にあるPOJO信仰は異常だと思う。
EJB3.0はバランスがよくて好感が持てる。
DAOパターン信者の俺にJPAは少しきついが。

**デフォルトの名無しさん** · 2008/12/11(木) 13:08:10

>>331
処理対象クラスを柔軟に変えたり、
複数の横断的処理をそれぞれ別の対象クラス群に対して実装したいとき
多重継承が出来ないJavaでは限界がある
それを一気に解決出来るのがAOP
AOPがある今では、ベースクラスでそういう処理を実装するのはメンテナンス性が激しく下がるので
なるべく避けるようにしている

**デフォルトの名無しさん** · 2008/12/11(木) 14:53:32

AOPの便利さはわかったけどさ
AOP/DI以前でも>>322が言うように
>全部のクラスに頑張ってログ出力書いたりログインチェック書いたり
するやつがいたのか？って聞いてるんだけど

まあログ出力はステップ実行の無い昔は全部書いたけどさ

**デフォルトの名無しさん** · 2008/12/11(木) 15:45:46

>>335
ログインチェックしないのか？
サーブレットフィルタはAOPじゃないという話か？
運用のためのログ出力は不要か

**デフォルトの名無しさん** · 2008/12/11(木) 17:34:54

自分はやらないって奴に他の奴は殆どやってると説いても無駄なんじゃね？

**デフォルトの名無しさん** · 2008/12/11(木) 17:37:25

>>335
だからAOPが無い時代にベースクラスでそれをやろうとして
StrutsのActionクラスの継承づくしみたいなボロボロな形になったんだよw
それを今でも続けたいのならずっとそうしてれば？
一緒に仕事をする人は迷惑なだけだろうけど

**デフォルトの名無しさん** · 2008/12/11(木) 17:51:31

だからログインチェックはするし
ベースのexecute()でチェックしてからdoExecute()するだけだから
「Actionクラスの継承づくし」みたいなことにはならなかったし
（なったとしても別の問題だし）、Struts/2以降ならfilter/interceptorだし。

それをやらないなんて一度も言ってないだろ。
AOP/DI以前には全クラスにコピペなんてしてたのか？そんなやついないだろって
言ってるだけじゃないか。ま、どうでもいい話題だしどうでもよかとにあん

**デフォルトの名無しさん** · 2008/12/11(木) 18:04:48

ごめんfilterはログインチェックには使ってないわ
visitor系Actionがあるから
interceptorはAction毎にどれを使用するか指定できるけど

**デフォルトの名無しさん** · 2008/12/11(木) 22:50:41

てかfilterは典型的なAOPじゃん

**デフォルトの名無しさん** · 2008/12/12(金) 00:40:43

interceptorって、名前からしてAOPっぽいんだが

**デフォルトの名無しさん** · 2008/12/12(金) 00:44:08

interceptorインタフェイスはアスペクト指向だよねー

**デフォルトの名無しさん** · 2008/12/17(水) 22:43:49

AOP以前からAOPちっくな設計は普通のオブジェクト指向設計の一環としてやってたよ。
AOPを喧伝する人を見かけたら、マトモなOO設計出来ない人なんじゃないかと警戒する。

**デフォルトの名無しさん** · 2008/12/18(木) 02:00:12

なんだ、単なるOO自慢か。

**デフォルトの名無しさん** · 2008/12/18(木) 08:24:22

おや・・・酔った勢いで変な事書いた。ごめん。

**デフォルトの名無しさん** · 2008/12/18(木) 08:35:56

誰でも簡単に使える仕組みを作ってそれを宣伝したらアホってどんな感覚だよｗ
>>344は自分しか理解できない仕組みしか作れなかったと言ってるようなもんじゃん

**デフォルトの名無しさん** · 2008/12/18(木) 08:51:04

宣伝(せんでん)ではなくて喧伝(けんでん)ね。
「盛んに言いふらすこと。世間でやかましく言いたてること。」
酔った勢いとはいえ、申し訳ない。では！

**デフォルトの名無しさん** · 2008/12/18(木) 10:22:59

>>344
そういうオレオレシステムをフレームワークとして汎用的に提供したと思えばいいんじゃないか？
それすらも嫌なのなら、ご自慢のシステムwもフレームワーク化して世に出してみれば？

**344** · 2008/12/18(木) 20:34:35

>>346と>>348は俺。
AOP自体は別に否定してないよ。他の言語なら言語の仕組みとして提供されていたりもするし。

**デフォルトの名無しさん** · 2008/12/19(金) 00:10:37

>>291
以前から分散アプリサーバ系の構築をやってきた者からすると、
DIではじめて何かできるようになったというより、以前からできてたことを、
コンテナなしでテストできるようになって便利になったという感想になるのだと思う。

**デフォルトの名無しさん** · 2009/03/10(火) 08:40:15

>>352
(´･ω･｀)ｼｮﾎﾞｰﾝ
http://imepita.jp/20090124/089930

**デフォルトの名無しさん** · 2009/04/19(日) 18:20:24

こやつめｗ

**デフォルトの名無しさん** · 2009/05/17(日) 14:07:47

>>352
ｵﾔｽﾐ…
　＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣

**デフォルトの名無しさん** · 2009/05/17(日) 20:35:36

開発が減ったのか
ものすごい過疎っぷりだな

**デフォルトの名無しさん** · 2009/05/19(火) 18:08:08

>>354
　Z
　 z
　　z
　＜⌒／ヽ-､_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣

**デフォルトの名無しさん** · 2009/06/10(水) 18:10:00

話すことがないんだなぁ
やっぱり製品作ってなんぼだな

**デフォルトの名無しさん** · 2009/06/11(木) 08:51:30

もうDIコンテナは当たり前になって、便利かどうかという話ではなくなってるからな。

**デフォルトの名無しさん** · 2009/06/13(土) 04:22:18

前にDIコンテナ使ってないプロジェクトで、開発用DBのトリガの引数が変更されて
本番DBとズレが生じて、仕方なく設定ファイルで読み込むクラスが変わるような
仕組みを作ったけど、常に必要ってわけじゃないな。

DIコンテナが喜ばれてるのはDI以外の部分だよね？
インスタンス管理とかトランザクション管理とか。

**デフォルトの名無しさん** · 2009/06/13(土) 04:26:54

DI以外の部分がDIに立脚してる件

**デフォルトの名無しさん** · 2009/06/15(月) 02:15:29

まあそうだけどさ