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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2008/08/20(水) 23:23:26
インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどｗ
2009/06/15(月) 02:15:29
まあそうだけどさ
362デフォルトの名無しさん
垢版 |
2009/07/17(金) 02:07:27
結局、結論として、使った方がいいんですか？
使わない方がいいんですか？

そこんとこ教えて下さい。
2009/07/17(金) 02:17:18
てめぇ、Springスレにも書き込んだ奴だな！
2009/07/17(金) 02:23:18
はい、そうなんです。

流行ってるのはなんとなく分かるんですが、色んなサイト見ても何が
いいんだかさっぱり分からないんですよ。

フレームワークを使う事が目的になってる気がしてなりません。

それ以上の価値は、一体どこにあるんでしょう？？
2009/07/17(金) 02:28:09
>>364
お前みたいな屑を兵隊として使えるようになると分かる
2009/07/17(金) 03:55:48
あはは(笑)

まあそれは俺を使ってみてから言ってください(笑)

で、何がよくなるんですか？
2009/07/17(金) 04:38:35
>>366
使えるかどうか判断してやるからスペック晒してみろ
2009/07/17(金) 05:52:51
>>367
24歳 ♀
165センチ
45キロ
胸はC
顔は うちの総務の高山さんの若い頃に似てるそうです。

つかえますか？
2009/07/17(金) 06:28:27
俺より背が高いから却下
2009/07/17(金) 12:18:41
165cm/45kgでCカップってありえないと思う…
2009/07/17(金) 12:42:09
>>367
まぁスペックなんて晒しても無駄ですよ。

そんなもん所詮こけ脅しにしかならないし。
実力とか応用力とか本当に使えるかどうかなんて実際に
仕事やらしてみるしかないんすよ。

人事なんてそんなもんだと思ってます。
2009/07/17(金) 12:48:58
必要ないなら使うな。お前みたいな屑がblogでspringって
何するもん? 使う必要あんの?　フレームワークを使うことが
目的になってない? とか訳分からんチラ裏ばっか書くから
google先生がゴミばっか拾って汚染されていく。
2009/07/17(金) 13:05:42
そんなもん書いてねーっすよ（笑）

必要ないなら使わないのは当然ですが、必要性をお教え頂きたいのです。

依存性の注入とか言いますが、結局は設定ファイルを簡単に読み込む
ためのものなんですか？
それを単純に文字列の値からオブジェクトにまでしたもの？？
2009/07/17(金) 14:07:17
>>371
> 実力とか応用力とか本当に使えるかどうかなんて実際に
> 仕事やらしてみるしかないんすよ。

もう十分わかったよ。お前は使えないから消えろ。
2009/07/17(金) 14:21:13
やだぴょーん（笑）

DI にこだわる意味を教えてもらうまではいるぴょーん
2009/07/17(金) 14:23:29
ああもう夏休みか
ヌルーの季節ですな
2009/07/17(金) 14:27:05
誰もこだわってないだろ。便利だから使ってるだけ。
何が便利かは人によって違う。
スパコンの計算能力が不要な人にスパコンの価値は理解できない。
DIも同じ。HelloWorldしか作ってないやつにDIの価値は理解できない。
2009/07/17(金) 14:45:19
>>377
いや…なんて言うんですかね、つまり、特定の状況では DI コンテナ
なしで開発するよりも DI コンテナありで開発した方が効率がいいと
皆さん考えている訳ですよね？

その状況を知りたいのです。

どういう時ですか？？　もうプロジェクト全部？文句なしで？
だったら、次のプロジェクトで試しに使ってみようと思ってます。
2009/07/17(金) 15:03:10
横から口を挟むが、DIそのものが便利かっていうと単体テストの時の
クラス入れ替えが便利になる程度。真正面からDIを勉強するとそういう説明ばっかで
あまりメリットが見えてこない。

みんなが便利に使ってるのはDIコンテナが持ってる機能で、例えばオブジェクトを
インジェクトするときにちょこっと書き換えてAOPでトランザクション管理やらせたり、
インスタンスの生成管理をコンテナにさせてソースの記述量が減ったり、そういうこと。
2009/07/17(金) 20:58:42
目的がない奴が使っても意味ない
マネジメントできずに下手なPGになんでもインジェクションされて終わり
381デフォルトの名無しさん
垢版 |
2009/07/17(金) 22:12:14
ＤＩコンテナのデスクトップ番のようなものってありますか？
2009/07/17(金) 22:50:45
springもseasarもデスクトップで使えるだろ。
guiceくらいが一番バランスいいかもしれんが。
2009/07/18(土) 00:01:22
>>379
ふむふむ…。
なんだか複雑な事情ですね。

まぁ一回使ってみりゃ分かるんですかねぇ。
でも納期が８月末のプロジェクトなんで、ちょっと冒険する気に
ならないな…………。
2009/07/18(土) 00:35:27
DIコンテナの利点が分からないってことは、利用しても使いこなせないって事。
だから、使わないほうがいいと思うよ。
2009/07/18(土) 00:56:15
>>384
でもそれって「フレームワーク」の思想に反するんじゃないんですかね？

フレームワークの上に乗っかって作業してりゃあバカでも恩恵に与れる
のがフレームワークってもんなのでは？？
2009/07/18(土) 01:22:32
馬鹿のまわりが恩恵に預かるのでは・・・
2009/07/18(土) 01:41:45
どんなFWであっても、馬鹿がFWの上に乗っかって作業すると、平気でFWを無視し続けてグダグダになる法則。
2009/07/18(土) 02:38:43
DIコンテナはフレームワークじゃない。その上でフレームワークを構築するんだよ。
2009/07/18(土) 04:04:54
struts1.3 + spring2.5でdelegatingactionproxyで連携
しようと思っています。
この場合、DIするためにActionクラスにインスタンス変数を
持たなければならないのですが、この変数はスレッドセーフで
動作するのでしょうか？
しないならば、どのような解決策が考えられるでしょうか？
どなたかお知恵のある方、ご解答よろしくお願いします。
2009/07/18(土) 13:50:17
>>389
Actionにステートフルなコンポーネントをインジェクトしたいと言うこと？
それは設計としてまずいような気がするが。
391390
垢版 |
2009/07/18(土) 13:52:44
あ、マルチポストだったのか...
392389
垢版 |
2009/07/19(日) 00:30:18
389です。マルチポストしてすみませんでした。
期日が迫っている作業なのであせっていました。
どうやら変数のスコープをプロトタイプにしたところ
hashCodeが異なる値で取得出来たので問題なさそうです。
ありがとうございました。
2009/08/17(月) 17:46:52
自動焼人 ★　＝　自動保守 ◆KAWORUKOFI　＝　自動保守#K9K?_D[L

名言集　その２
『お前が規制系キャップ取れるか審査してやるよ』

http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/　ID:PVAf+dux0　＝　自動焼人 ★

> 36 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:31:30.02 ID:PVAf+dux0
> >>33
> キャップとコテハンの違いは何？

> 46 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:38:05.34 ID:PVAf+dux0
> >>45
> その回答では落ちるなｗ
> 答えは教えないがｗ

> 50 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:41:29.96 ID:PVAf+dux0
> Q.キャップとコテハンの違いは何？
> A.２ちゃんねるのボランティアの登録制度

> それがお前の答えかｗ

> 52 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:43:10.06 ID:PVAf+dux0
> まぁ、どうせ正解が出るわけもないし、次の問題。
> 君が思う面白いスレはどんなの？
----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください
2009/11/29(日) 18:23:57
2009年に入ってからの過疎進行が半端ない
2010/01/03(日) 13:48:33
>>394
おそらく、2010年も過疎進行でいくと思う。
2010/01/06(水) 04:21:39
CDIの話題も出ないなんて
2010/01/06(水) 21:20:18
ＧＤＩなら…
2010/01/07(木) 10:17:34
三菱GDIエンジン
2010/01/07(木) 22:44:22
>>396
WebBeansの頃から空気だろ
2010/01/09(土) 05:03:49
CDIは、Tomcatとか各サーバーが標準装備するようになったら他のDIコンテナいらなくなりそう。
CDIのせいで一番最初に滅びるのはEJBだが。
2010/01/09(土) 08:54:16
@TransactionAttributeはjavax.ejbだから滅びないよ
2010/01/09(土) 13:53:11
>>400
CDIはTomcat6で今でも動いてるよ
JavaSEでも動いてSwingのコンポーネントに使えるサンプル付属してるくらい
2010/01/09(土) 14:42:50
>>402
Tomcatが「標準装備」するようになったら、だろ
自分でライブラリ突っ込めば動くってんじゃ誰も使わんよ
俺はTomcatが標準装備してもCDIが流行るとは思わんけどな
2010/01/09(土) 15:33:46
SpringもGuiceもSeasar2も標準装備はしてないよね？
2010/01/09(土) 15:47:34
後発が同じ条件で流行ると思ってるのか？
EJB3だって流行ってないだろ？3.1だって流行らないよ
理由なきJavaEEアレルギーはまだまだ根強い
2010/01/09(土) 16:01:54
EJBはサーブレットコンテナだけで動かないでしょ
2010/01/09(土) 16:11:06
OpenEJB突っ込めば動く
2010/01/17(日) 11:42:25
CDI手軽すぎ。でもトータルで見るとSeasarが勝る。
2010/01/18(月) 06:45:59
学習コストでまける
410デフォルトの名無しさん
垢版 |
2010/01/19(火) 17:07:41
FFY最強！
411デフォルトの名無しさん
垢版 |
2010/10/04(月) 04:35:34
EE6でJavaは完成された感がある。
気に入らない人はまだまだ居そうだけど。
412ななし。
垢版 |
2011/07/27(水) 19:32:41.18
カ　オ　ス　ラ　ウ　ン　ジ　ゆ　る　せ　な　ぁ　い　ー
2011/10/26(水) 20:17:30.57
仕様と実装を切り離す
2012/01/02(月) 07:03:20.58
DIコンテナって2種類に分類されると思うんだ。以下あってる？

1. 型（inteface）に対するIOC(Guice)
2. 保有クラスに対するIOC(Spring)

(1)はinterfaceの保有クラスを区別せず1種類の実装が提供される。
(2)はinterfaceの保有クラスによって実装クラスが違う可能性がある。
2012/01/02(月) 07:11:26.86
たとえば以下のような例の場合、
Guice系の場合にはインターフェースに対する実装の提供を１つだけ書いて
全てのIServiceに同じ実装が渡される。
Spring系の場合にはインターフェースに対する実装の提供を
コンテナからHogeを生成した場合、Mogeを、Kogeを生成した場合と3種書いて
保有クラス(Hoge,Moge,Koge)によってIServiceに違う実装が渡される。

class Hoge {
IService service;
}

class Moge {
IService service;
}

class Koge {
IService service;
}
2012/01/02(月) 10:23:11.80
意味がよくわからん
guiceはintefaceと実装が一対一の関係「専用」のDIであるということを言ってる？
そういう意味なら違う
その場合は実装をアノテーションで指示するようになってる
2012/01/02(月) 13:10:41.09
>>416
＞guiceはintefaceと実装が一対一の関係「専用」のDIであるということを言ってる？
うん、そういうこと。@Namedを使う抜け穴があるけど、それはguice系DIの思想的に
望ましくないと思うんだ。

intefaceと実装が一対一の関係だから実装を変更するときは
アプリケーション中でそのinterfaceに対する実装が一括で変更される。
そんなinterface単位の一括管理がguice系の方向性だと思うんだ。
2012/01/02(月) 13:15:58.26
>>417
抜け穴ってｗ
一対一じゃ使い物になんないだろ
それ実装だけで開発するのと同じ事じゃんｗ
2012/01/02(月) 13:23:52.18
続き

対してspringなどはinterfaceを使っているクラス単位で管理すると思うんだ。
例えば実装クラスを入れ替える場合、interfaceをフィールドに持っていたり
使っているクラス(bean)毎に設定を変更する。
抜け穴があるにしろ、基本的にDI箇所が増えるほど
設定が増える代わりに１つ１つ細かく指定できるのが利用クラス(bean)単位のDI
2012/01/02(月) 13:31:53.96
>>418
説明がよくなかったかな。。。
例えばモックから完成クラスへ入れ替える、
あるいはMySQLからOracleDBに入れ替えるような、
そのインターフェースに対してアプリケーション中が一気に入れ替える
リソースの変更的な入れ替えのためにはGuiceは向いてるけど、

Buttonインターフェースに対してGreenButton, RedButtton, BlueButton
どれかを生成するストラテジーパターンみたいなものには向いていなくて、
仮にそれをするならわざわざIGreenButton, IRedButton, IBlueButtonみたいに
別々のインターフェースを作るのがGuice系の正しい使い方なんじゃないかな？
2012/01/02(月) 13:37:47.57
>>420
いやーアノテーションでやるでしょそれは
IGreenButton等々はかなりまずいスタイルだよね・・・
インターフェイスに対してプログラミングするスタイルを完全にスポイルしちゃう
springはよく知らないけど、
あるinterfaceに対するデフォルトのバインディングを指定することもできないの？
2012/01/02(月) 13:48:16.33
すると単なるIoCのFactoryクラス、つまりinterfaceなんか別に必須ではなくて
注入される側のクラスから見えないだけのFactoryクラスとして側面をもつのが
spring系DIで、

interface必須でinterfaceによる固い設計、実装クラス一括管理が
guice系DIの特徴に見えると思います。
2012/01/02(月) 13:59:52.82
＞あるinterfaceに対するデフォルトのバインディングを指定すること
Guiceにとってはこちらが「基本」ですが、
Springにとっては「そういうのもできる」という立場ではないかと。

逆にGuiceで@Namedを使うようなパターンに対しては
Springにとってはこちらが「基本」ですが、
Guiceにとっては「そういうのもできる」という立場ではないでしょうか。
2012/01/03(火) 10:54:33.00
DIはユニットテストのモック差し替えぐらいにしか使えないという記事を読んで、
やはりそういう用途にDIの概念が特化するならば、Guiceの@Namedみたいなiocコンテナ
の使い方はDIとは別の概念として切り分けられるべきではないかなと思た。
2012/01/03(火) 13:32:47.27
DIよりもAOPがメインだよな
DIコンテナの用途って
2012/01/03(火) 16:35:15.29
DIの方がメインでは？
2012/01/03(火) 23:14:35.03
俺もあくまでDIの方がメインだと思う。
2012/01/04(水) 08:38:37.47
実装の切り離し以外の役割を背負いすぎてるのが
学習時の混乱をもたらしてると思う

DIコンテナっぽいものをJavassistの練習で作ろうとしたところ
DIってどうあるべきだ？と考え出したところで停滞してしまったｗ
2012/01/22(日) 19:01:48.77
やっぱDIコンテナ使う人って、とりあえずなんかクラス作るときは
例外なしにインタフェースかぶせとくもんなの？

今のプロジェクトはそうなってるけど、ユニットテストもないし
実装もすべて一個なんだから、もう密結合でもよくね？って気がすごくしてるんだけど
2012/01/22(日) 19:38:29.82
そりゃ、ただの思い込みor実装上(AOPの方式とか)の制約じゃねーの？

俺は本当にプロバイダーモデルが必要な所しかInterfaceの分離はしないし、
テストに関しては黒魔術で対応してる。
2012/01/23(月) 14:44:29.86
>>429
自分はいわゆるコントローラ(サービス)クラスとかDaoクラスであれば、
最初は実装クラスが1つしかなくても、例外なくインターフェースかぶせておくようにしている。

あとから、実装クラスを変えたくなった時や複数のバリエーションの実装クラスを作りたくなったとき、
context.xml で切り替えるだけで、プログラムを修正しないですむので、
プロジェクトの終盤で大きな変更を加えなければならなくなったときに、だいぶ助かったことがある。

例：
たとえば Dao で、インターフェース FooDao があったとして、
最初は iBatis で作っていたが(FooDaoIbatisImpl)、
一部独自に実装したくなった時は、FooDaoHogeImpl というように、FooDao を使った
別の実装クラスを作る。

context.xml で、bean id="fooDao" class=".." のところを FooDaoHogeImpl に変更すればいいので、
サービスオブジェクト側からは、変更を気にしなくて済む。

これでパフォーマンスチューニングをやったり、Dao の取得先を RDB から KVS とかに切り替えたりした。


2012/01/24(火) 19:58:47.06
>やっぱDIコンテナ使う人って、とりあえずなんかクラス作るときは
>例外なしにインタフェースかぶせとくもんなの？

そうしてもいいぐらい粒の大きいクラスにしかDIしないこと
2012/01/25(水) 19:44:03.96
何十とあるControllerやService、Daoに対して、例外無しに全てIFを用意するのか？、っとい疑問が生まれること自体は、まあ普通だと思う。
434デフォルトの名無しさん
垢版 |
2012/02/16(木) 17:08:25.22
必要なところをinterfaceに変えるのって手間掛かるか？
IDEのリファクタリング機能とか、無くても一旦コンパイルエラーにして
置換掛けていけばいいだけだし

必要になってからinterfaceにしても別によくね
435デフォルトの名無しさん
垢版 |
2012/02/17(金) 10:16:39.50
DIの利点ってやっぱテスト部分なのかね
2012/02/17(金) 20:52:25.87
インジェクション設定が増えすぎるアンチパターンを懸念すると
テストの設計とDIでセットにするのが良いかもしれん
2012/02/23(木) 01:44:38.83
interfaceを書きながら設計していく感じが多いかな
implするクラスも同時に書いていくと、設計が終わる頃にはスケルトン＋モックにもなるクラスができてる
438デフォルトの名無しさん
垢版 |
2012/02/23(木) 13:50:41.31
>何十とあるControllerやService、Daoに対して
なんで一対一でinterface用意する必要があるの…？
根本的にわかってないとしか言いようがない
2012/02/23(木) 21:53:45.88
一対一にしないならDIやる意味なくない？
2012/02/23(木) 22:21:45.78
インターフェイスをDIのタグとして使ってるってことかｗ
2012/02/24(金) 18:50:12.83
DIって言葉も、なんかMVCと同じでぼくの使ってる最強のDIみたいなのが十人十色で意思疎通難しいし
もうNGワードにしたほうがいいんじゃないか
442431
垢版 |
2012/02/26(日) 21:41:06.65
>>439
開発当初は1対1しかないかもしれないけど、
あとから増える場合もあるので、そういった時には、インターフェースと実装クラスを分けておいてよかったと思うよ。

まぁ、これから作ろうとしているシステムが、使い捨て(寿命が短い)であまり変更を考慮しなくていい場合と、
ある程度長くなりそうな場合とで、手間とのトレードオフもあると思うけど。
2012/02/26(日) 21:53:56.03
流れを誤読しとる？
2012/02/26(日) 22:05:10.19
>>442
使い捨てがどうのともっともらしいことを言っているけど、
単に実装をIFを分離すべきポイントをちゃんと設計出来る能力が無いから
とりあえずなんでも分離しておく、っと言っているようにしか聞こえない。

そんなんで良いのか？
2012/02/27(月) 08:57:55.64
DIのために一対一にするくらいならクラスを指定してDIすればいいだろってこと
446431
垢版 |
2012/02/27(月) 15:49:00.65
>>444
そう言われると反論できない。
突貫工事が多いから、とりあえず *Dao と *Service は
インターフェースと実装クラスに分けとけ、というルールを決めて、
開発に着手していたことは多かったな。

いちいち
・こういうケースは分離しましょう
・こういうケースは分離しなくていいです
というルールを考えている余裕がなかったので。
2012/02/27(月) 16:39:07.27
そういう機械的な設計でいいと思うけどね。
堅実というか無難というか。
2012/02/27(月) 19:59:53.91
実装クラスでメソッド追加した際に
インターフェイス側に宣言コピペするだけだしな

ファイル分けるもの面倒臭い
public interface A {
　　void f();
　　public static class Imp implements A {
　　　　public void f(){}
　　}
}
2012/02/27(月) 23:02:03.47
なんかよくわからんなー
DIとなんの関係がある話なのかすらよくわかんない
Cのプロトタイプ宣言の話聞いてるみたいだ
2012/02/27(月) 23:09:58.39
DIで注入される側
FooServiceImplならFooService型の定義になってて
BarServiceImplならBarService型の定義…みたいなことやってるってこと言ってるの？
2012/02/27(月) 23:15:39.88
いや例がよくないｗごめん
2012/02/27(月) 23:18:58.00
もうDaoでインターフェイスを分離する意味ないだろ
昔ならモックに差し替えるのに必要だったが
2012/02/28(火) 23:46:53.79
intra-martの人達ってまだS2押してんの？
2012/04/19(木) 00:58:00.99
>>140
>>351
>>444
話が合いそうだ

・直列化とビルダーパターン使うべきポイント
・マクロやジェネレータ使えばいいんじゃね？ってポイント
・なぜプログラムの修正をそんなに怖がる？ってポイント
・なぜファクトリの数行を面倒臭がる？（コード書けば言語解析による依存関係調査が可能だし、可読性も高まるのに）

って、結構どうでもいいところでDI使ってる人が沢山いる。

結局、普通のオブジェクト指向に対するシンタックスシュガーに過ぎないので、
経験のない人間が下手に使うと、どう再利用すればいいのか分からない、ゴミ山のような小さいクラス群と
環境によって内容が違う定義ファイルに道を迷わされる。。。

労働集約型産業やりたいのなら、COBOLとか実は良い言語だぜ？

2012/08/18(土) 05:07:00.19
DIコンテナ使ってるのに結局ダウンキャストしてるとか、
それを避けるために（？）インターフェースと実装を１：１にして、同時にメンテしていくとか
そんな使われ方をしている所にしか出会ったことがないんで、考察が足りないかもしれないけど

DIコンテナって、上手く使えば便利なのは分かるんだけど、
publicメソッドの一つも足すことができないし、拡張性が落ちる気がするんだよね。
上の例みたいに、インターフェースと実装を１：１にすればできるけど、
その状況って単に、DIコンテナ使いたいからインターフェースと実装を分離してる感じになっちゃってるし、きもい。

作って終わりならいいけど、拡張をしていく可能性を残すなら、
そう簡単に導入できるものじゃない気がするんだよなぁ。
2013/02/08(金) 12:54:44.22
DBfluteだのJBossだのJava界隈はまともに動かなかったりやる事増やしたりするゴミばっかだな
2013/02/08(金) 13:10:11.56
http://event.seasarfoundation.org/sc2009white/viewAttachment.do?_pageName_=Session&;_fileName_=sc2009white_s406_4_hot.pdf

これ読んでると色々馬鹿馬鹿しくなるね
2013/02/24(日) 16:07:14.97
DIってsetter使えば要らないよね？
AOP目的で使ってる人いるみたいだけど、ならsetter+AOPで良くてDI不要じゃん
2013/02/24(日) 16:40:11.43
DIすることとDIコンテナを使うことは区別するべきだと思う。

「setter使えば」が何を意味しているのかイマイチ判然としないけれども、setter使って
サービス等の実装オブジェクトをセットするという意味ならそれは他でもないDIだと思う。

DI自体はDIコンテナの使用の有無に関わらず有用な設計パターンの一つだと思うよ。

あとはブートストラップに実装のsetを列挙するかそれともDIコンテナ使うかの、注入作業
の実装方法の違いに過ぎないと思う。
注入するものとされるものが増えてきて、autowireなど規約による自動注入の類を使い
始めるとDIコンテナも便利だと思う。
460457
垢版 |
2013/02/24(日) 20:24:51.85
理解が深まりましたm(__)m
2013/02/24(日) 20:25:24.35
457 -> 458
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況