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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2008/08/20(水) 23:23:26
インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどｗ
2008/08/20(水) 23:42:55
DIってなに使ってるんだよｗ
いまどきXML地獄なんてどのFWにも無いぞ
3デフォルトの名無しさん
垢版 |
2008/08/22(金) 00:40:41
使わずに組んだほうがラク
2008/08/22(金) 01:57:47
>>2
Spring2.5からはアノテーションインジェックションが
使えるようになったからXML地獄じゃなくなったよ。
5デフォルトの名無しさん
垢版 |
2008/08/22(金) 05:09:45
優柔不断すぎるプロジェクトが多い気がする。
インタフェース作っても、実装クラス一つしかなかったり。
結局、特定の組み合わせでしか動かなかったり。
2008/08/22(金) 10:44:21
実装クラスひとつはふつうと言えばふつう。
2008/08/23(土) 15:43:06
>>1
インターフェース書くのが嫌ってことなら、そっちの方が大問題だね
まあ、そもそも DI するのにインターフェース書かなきゃいけないってことは無い訳だが

脱線するが、
interface と abstract class は全く違うものなんだけど、分かってるつもりでいて、実は分かってないやつは非常に多い
>>1 もそんなとこだろう
abstract class は拘束、interface は主体的な宣言とか言ったらヒントになるか…
共通点は勿論あるんだが、設計においては、これは全く違う意味を持ってくる
それが分からんと、 interface の価値が見出せなくなったりするようだ
なんと言うか、interface を拘束の意味でしか理解していないとでも言うか…

それから、実装クラスが一つしかないと、端折って直接実装を呼びたくなったりするらしいが、
その点 DI は interface の旨味を再確認させてくれる。
2008/08/23(土) 23:57:34
>>7
お前が interface と abstract class の違いをよく理解していないことだけはわかった
2008/08/24(日) 02:25:07
↑
どうやら何かを判ったつもりになってひとりで納得しているの図
10デフォルトの名無しさん
垢版 |
2008/08/24(日) 10:08:27
インターフェースは不要っしょ
俺ぁ余計なクラス、設定が増えまくる事自体が問題だと思う
2008/08/24(日) 10:39:57
springスレも落ちたし、guiceスレも時間の問題だな。
2008/08/24(日) 12:41:17
具体的な個々の処理が存在するならインターフェースは書くべきだよ
実装しかないと、常に密結合状態じゃん
サービスの実装に
new InitialContext();
とか直接書いたりしないでしょ？それと同じ

後から何か処理を加えたいと思った場合、インターフェースがあれば最初の実装に手を加えなくても済むケースがあるでしょ？
実装しかないと、そいつにドンドン追加する羽目になりがち
下に何か加えることは出来るけど、上に被せられないし
それに、インターフェース守れば良いんだから、却って自由に書けると思うんだが

ただ DI に関して、設定が増えまくるのは確かに苦痛
そこでアノテーション
でもこれって、テストとリリースでどうやって分けんのかとか、ちょっと混乱しそうな気もする
ルール付け徹底すりゃいい話なんだろうけど
13デフォルトの名無しさん
垢版 |
2008/08/24(日) 12:58:04
ぐだぐだなところは、インタフェースを書き換えるから意味ないって。
2008/08/24(日) 13:05:54
XMLが地獄だと思わないんだが。
クラス図書くより全然楽だし。

アノテーションの方が地獄っぽくないか？
組み合わせ変更するのに、なんでコンパイル必要なんだよ。
何のために interface 書いたのか分からん。

もっとも DI 嫌ってる人は、そんな瑣末なことなんてどうでもいいんだよ。
本当は疎結合の良さが分かってないだけ。
自分がなんで DI 好きになれないのか、それすら分かってない。
DI なんてどうでもいいから、疎結合に慣れろ。
慣れた結果、密結合で十分かつ適当な場合と
そうではない場合が分けられるようになればそれでいい。
2008/08/24(日) 13:18:46
疎結合を保つためにDIは必要ないし、
DI使ってても密結合になってる例はたくさんあるし。
2008/08/24(日) 13:36:21
>>15
確かに

結局は分かってるか分かってないかに落ち着いてしまうのかな
シングルトン強制ギプスとか思っても、分かってりゃ必要に合わせてシングルトンで書くわけだし

ただAOPは捨てがたいな
AOPを捨てれないとDIも捨てられないw
2008/08/24(日) 13:48:19
>>12
>>10を見て目を疑ったんだが、結合度とか凝集度って未だに普及してない概念なのかねぇ。
まぁ、インターフェース大増殖とか設定ファイル大増殖とかアノテーションだらけってのは見てて気分のいいもんではない、というのは確かなんだが。

そこらへん、Scalaだとだいぶ緩和されそうだけど、普及するかなぁ。

interface Hige { String execute(); }
void hoge(Hige hige) { println(hige.execute()); }
が、
def hoge(hige: {def execute: String}) = println(hige.execute)
(higeがStringを返すexecuteメソッドを持っていれば何でもいい)
となるので、リスナーみたいなインターフェースはまとめて削減できそう。
1816
垢版 |
2008/08/24(日) 13:49:56
いや、やっぱ必要ないファクトリ書くのも プロパティセットするコード書くのも面倒くさいからDI捨てらんないわ
2008/08/24(日) 15:00:05
>>15
確かに。でもそれを言い始めたらキリがないのでは。
2008/08/24(日) 16:40:09
>>11
Seasarのことも思い出してください＞＜
2008/08/24(日) 18:38:55
疎結合？ソースが見にくいんですけど
2008/08/24(日) 19:30:53
ネタなのかマジなのか微妙なところ突いてくるな
2008/08/24(日) 19:42:31
成果物としてのコードが特定のフレームワークに強く依存するのが怖い。
「それがどうした、知らないお前が勉強不足」と開き直れるほど枯れた技術ではないし。

開発現場が全速力で短距離を走り抜けるための技術というか…
と感じながらも全速力で走らメシが食えないから使うんだけどな。
2008/08/24(日) 20:46:26
特定のフレームワークに ”強く依存” ってのが気になるね。
いったいどんなコード書いてんだ？
ぶっちゃけ特定の「なんちゃら」への依存が弱まることはあっても、強くなるケースっていまいち想定できないな。

モジュール間の結合度を弱めてテストをし易くするのが利点と思いきや、”強く依存” とはこれ如何に？
もしそれでモデルにフレームワークへの依存が入り込んでるんなら、実装に問題があると思ったほうが良いのでは？

内製だったらモデルとフレームワークの強い依存関係が許される、なんてオチじゃないよね？

あと枯れてる枯れてないって、じゃ generics や annotation は枯れてないから使わねーと？
2008/08/24(日) 21:17:10
＞ 開発現場が全速力で短距離を走り抜けるための技術というか…
それは RoR とかポトペタで画面作れますとか、
O/R mapper でウハウハだよもんとか、
そう言うレベルの話では。

DIコンテナが提供してくれるのは糊だけ。
既存のポトペタとくっつけたきゃそうするし、
フルスクラッチの俺様フレームワークとくっつけても良いし。

疎結合の利点を最大で活かすために糊に徹してるのが DI コンテナ。
2008/08/25(月) 01:06:47
下手のコードを閉じ込める
自分でファクトリ書かなくていい
テストコードが嫌でも書きやすくなる

下２つが特に有難い
短期開発でメンバのスキルが低いときは逆にDI使わないと品質は保てない
ファクトリ書いてる時間を他の作業に回せるし
27デフォルトの名無しさん
垢版 |
2008/08/25(月) 08:03:17
ファクトリとかわざわざつかわねーし。
余裕あるんだな
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況