インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどw
探検
【Java】DIコンテナって本当に便利か?
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2008/08/20(水) 23:23:262008/08/20(水) 23:42:55
DIってなに使ってるんだよw
いまどきXML地獄なんてどのFWにも無いぞ
いまどきXML地獄なんてどのFWにも無いぞ
3デフォルトの名無しさん
2008/08/22(金) 00:40:41 使わずに組んだほうがラク
2008/08/22(金) 01:57:47
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 の旨味を再確認させてくれる。
インターフェース書くのが嫌ってことなら、そっちの方が大問題だね
まあ、そもそも DI するのにインターフェース書かなきゃいけないってことは無い訳だが
脱線するが、
interface と abstract class は全く違うものなんだけど、分かってるつもりでいて、実は分かってないやつは非常に多い
>>1 もそんなとこだろう
abstract class は拘束、interface は主体的な宣言とか言ったらヒントになるか…
共通点は勿論あるんだが、設計においては、これは全く違う意味を持ってくる
それが分からんと、 interface の価値が見出せなくなったりするようだ
なんと言うか、interface を拘束の意味でしか理解していないとでも言うか…
それから、実装クラスが一つしかないと、端折って直接実装を呼びたくなったりするらしいが、
その点 DI は interface の旨味を再確認させてくれる。
2008/08/23(土) 23:57:34
>>7
お前が interface と abstract class の違いをよく理解していないことだけはわかった
お前が 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 に関して、設定が増えまくるのは確かに苦痛
そこでアノテーション
でもこれって、テストとリリースでどうやって分けんのかとか、ちょっと混乱しそうな気もする
ルール付け徹底すりゃいい話なんだろうけど
実装しかないと、常に密結合状態じゃん
サービスの実装に
new InitialContext();
とか直接書いたりしないでしょ?それと同じ
後から何か処理を加えたいと思った場合、インターフェースがあれば最初の実装に手を加えなくても済むケースがあるでしょ?
実装しかないと、そいつにドンドン追加する羽目になりがち
下に何か加えることは出来るけど、上に被せられないし
それに、インターフェース守れば良いんだから、却って自由に書けると思うんだが
ただ DI に関して、設定が増えまくるのは確かに苦痛
そこでアノテーション
でもこれって、テストとリリースでどうやって分けんのかとか、ちょっと混乱しそうな気もする
ルール付け徹底すりゃいい話なんだろうけど
13デフォルトの名無しさん
2008/08/24(日) 12:58:04 ぐだぐだなところは、インタフェースを書き換えるから意味ないって。
2008/08/24(日) 13:05:54
XMLが地獄だと思わないんだが。
クラス図書くより全然楽だし。
アノテーションの方が地獄っぽくないか?
組み合わせ変更するのに、なんでコンパイル必要なんだよ。
何のために interface 書いたのか分からん。
もっとも DI 嫌ってる人は、そんな瑣末なことなんてどうでもいいんだよ。
本当は疎結合の良さが分かってないだけ。
自分がなんで DI 好きになれないのか、それすら分かってない。
DI なんてどうでもいいから、疎結合に慣れろ。
慣れた結果、密結合で十分かつ適当な場合と
そうではない場合が分けられるようになればそれでいい。
クラス図書くより全然楽だし。
アノテーションの方が地獄っぽくないか?
組み合わせ変更するのに、なんでコンパイル必要なんだよ。
何のために interface 書いたのか分からん。
もっとも DI 嫌ってる人は、そんな瑣末なことなんてどうでもいいんだよ。
本当は疎結合の良さが分かってないだけ。
自分がなんで DI 好きになれないのか、それすら分かってない。
DI なんてどうでもいいから、疎結合に慣れろ。
慣れた結果、密結合で十分かつ適当な場合と
そうではない場合が分けられるようになればそれでいい。
2008/08/24(日) 13:18:46
疎結合を保つためにDIは必要ないし、
DI使ってても密結合になってる例はたくさんあるし。
DI使ってても密結合になってる例はたくさんあるし。
2008/08/24(日) 13:36:21
>>15
確かに
結局は分かってるか分かってないかに落ち着いてしまうのかな
シングルトン強制ギプスとか思っても、分かってりゃ必要に合わせてシングルトンで書くわけだし
ただAOPは捨てがたいな
AOPを捨てれないとDIも捨てられないw
確かに
結局は分かってるか分かってないかに落ち着いてしまうのかな
シングルトン強制ギプスとか思っても、分かってりゃ必要に合わせてシングルトンで書くわけだし
ただ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メソッドを持っていれば何でもいい)
となるので、リスナーみたいなインターフェースはまとめて削減できそう。
>>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のことも思い出してください><
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 は枯れてないから使わねーと?
いったいどんなコード書いてんだ?
ぶっちゃけ特定の「なんちゃら」への依存が弱まることはあっても、強くなるケースっていまいち想定できないな。
モジュール間の結合度を弱めてテストをし易くするのが利点と思いきや、”強く依存” とはこれ如何に?
もしそれでモデルにフレームワークへの依存が入り込んでるんなら、実装に問題があると思ったほうが良いのでは?
内製だったらモデルとフレームワークの強い依存関係が許される、なんてオチじゃないよね?
あと枯れてる枯れてないって、じゃ generics や annotation は枯れてないから使わねーと?
2008/08/24(日) 21:17:10
> 開発現場が全速力で短距離を走り抜けるための技術というか…
それは RoR とかポトペタで画面作れますとか、
O/R mapper でウハウハだよもんとか、
そう言うレベルの話では。
DIコンテナが提供してくれるのは糊だけ。
既存のポトペタとくっつけたきゃそうするし、
フルスクラッチの俺様フレームワークとくっつけても良いし。
疎結合の利点を最大で活かすために糊に徹してるのが DI コンテナ。
それは RoR とかポトペタで画面作れますとか、
O/R mapper でウハウハだよもんとか、
そう言うレベルの話では。
DIコンテナが提供してくれるのは糊だけ。
既存のポトペタとくっつけたきゃそうするし、
フルスクラッチの俺様フレームワークとくっつけても良いし。
疎結合の利点を最大で活かすために糊に徹してるのが DI コンテナ。
2008/08/25(月) 01:06:47
下手のコードを閉じ込める
自分でファクトリ書かなくていい
テストコードが嫌でも書きやすくなる
下2つが特に有難い
短期開発でメンバのスキルが低いときは逆にDI使わないと品質は保てない
ファクトリ書いてる時間を他の作業に回せるし
自分でファクトリ書かなくていい
テストコードが嫌でも書きやすくなる
下2つが特に有難い
短期開発でメンバのスキルが低いときは逆にDI使わないと品質は保てない
ファクトリ書いてる時間を他の作業に回せるし
27デフォルトの名無しさん
2008/08/25(月) 08:03:17 ファクトリとかわざわざつかわねーし。
余裕あるんだな
余裕あるんだな
2008/08/25(月) 21:35:10
密結合を気にしない >>27 の一言でした
ファクトリ書かなくても良いってのが DI の利点の一つなわけだが、
そもそもなんでファクトリ書くべきなのか分からんようでは、その利点も分からん訳だ。
溝は深いね〜
ファクトリ書かなくても良いってのが DI の利点の一つなわけだが、
そもそもなんでファクトリ書くべきなのか分からんようでは、その利点も分からん訳だ。
溝は深いね〜
2008/08/25(月) 22:17:32
>>28
ファクトリとかソースが見にくくなるだけ。
ファクトリとかソースが見にくくなるだけ。
2008/08/25(月) 22:59:07
大抵のOSSのフレームワークやミドルウェア製品の
提供するAPIには必ずファクトリが含まれるわけだが
提供するAPIには必ずファクトリが含まれるわけだが
2008/08/26(火) 01:31:50
「DIのいいところ教えてください。」
って聞きたいのに、強がって
「DIコンテナって便利か?」
って聞いてるわけか。
って聞きたいのに、強がって
「DIコンテナって便利か?」
って聞いてるわけか。
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 上野動物園の双子パンダ、1月末に中国に返還へ 国内でパンダ不在に [蚤の市★]
- 中国軍機のレーダー照射1週間 駆け引き続く 中国、米のレッドライン模索 日本、米以外の同志国とも連携探る 米は対立から距離置く★3 [ぐれ★]
- ゼレンスキー氏、NATO加盟断念に言及 ドイツで米代表団と [蚤の市★]
- 中国軍機のレーダー照射1週間 駆け引き続く 中国、米のレッドライン模索 日本、米以外の同志国とも連携探る 米は対立から距離置く★2 [ぐれ★]
- 【音楽】カイリー・ミノーグ 最新シングル「XMAS」のミュージックビデオ公開 [湛然★]
- 「婚活中の男女の8割以上が婚活疲れ」続ければ続けるほど蟻地獄にハマる必然とは? ★2 [ぐれ★]
- パナソニック、ほぼ全て20%値上げ… ありがとう高市早苗 働いて働いて働いてまいります [667744927]
- 高市早苗、病気か?ろれつ回らず上手く喋れずwwwwww [153490809]
- 名古屋にビュッフェが無くてつらい
- 土曜か日曜の朝にやってる番組「ローカル番組に中山秀征が飛び入りで参加します!」←これ
- (´;ω;`)まぜのっけごはんが食べたいのにすき家がない!!!
- (財務)片山さつき『サナエノミクス💕』開始。「所得、経済、税収全てが上がる夢のような政策」 [153490809]
