【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
ファクトリとかわざわざつかわねーし。
余裕あるんだな
2008/08/25(月) 21:35:10
密結合を気にしない >>27 の一言でした



ファクトリ書かなくても良いってのが DI の利点の一つなわけだが、
そもそもなんでファクトリ書くべきなのか分からんようでは、その利点も分からん訳だ。
溝は深いね〜
2008/08/25(月) 22:17:32
>>28
ファクトリとかソースが見にくくなるだけ。
2008/08/25(月) 22:59:07
大抵のOSSのフレームワークやミドルウェア製品の
提供するAPIには必ずファクトリが含まれるわけだが
2008/08/26(火) 01:31:50
「DIのいいところ教えてください。」
って聞きたいのに、強がって
「DIコンテナって便利か？」
って聞いてるわけか。
2008/08/26(火) 03:55:28
DIコンテナが分からないんじゃなくて
それが登場した背景の考え方が分かってない。
だからいつまで経っても話がかみ合わない。

モジュールの凝集度高めて疎結合目指すなんてのは
それこそ20年以上前から言われてることなのに
理解して実践してるのはごく少数なのが現実。
2008/08/26(火) 21:52:13
だよもんとか（某板の外では）数年ぶりに聞いた
2008/08/26(火) 22:29:25
>>32
全くもってそうらしいね

今途中から突っ込まれて行ってるプロジェクトは結構グダグダで火を吹いてるんだが、
ソースを見てビックリ呆れること多数。
所謂大規模開発で、結構な数の業者が入っていて、開発人員も多いんだけどね。
規模なんてソースの品質には関係ないらしいよ。

勿論 DI なんて使ってないんだが、更に残念な事に自分等でファクトリを書いてない。
おまけにベンダ製のツールが吐いたファクトリクラスがあるんだが、
そのファクトリを使うとき、getFactory() ってなスタティックメソッドがあるにも関わらず

毎 回 そ の フ ァ ク ト リ を new し て る 。 orz

てめぇー、インスタンスの取得方法を知らなくてもいいようにファクトリがあんのに、
そのファクトリを毎回 new してどーすんのよ！？ってな感じ orz orz
そんなコードがゴロゴロ

こんなんが某超大手元受の金融機関向けシステム開発だってんだから
残念な業界ですねって言いたくなるよ。

その残念な質の一画を自分の会社が占めている事実が更に残念。
早く辞めてぇ

（ﾏな内容でｽﾏｿ）
3534
垢版 |
2008/08/26(火) 22:38:15
誤：インスタンスの取得方法を
正：インスタンスの生成方法を
36デフォルトの名無しさん
垢版 |
2008/08/26(火) 23:19:54
>>34
お前も残念な会社の社員なんだろ？ｗｗｗ
2008/08/26(火) 23:59:18
>>34
気持はわかるけど、ここマ板じゃないから。
2008/08/27(水) 00:18:53
>>34
そんなつまらん会社辞めろ。
お前も残念な質の会社の一角を占めてるんだ。
辞める気がないならつまんない愚痴言わず、
会社、業界を良くする努力しろ。
39デフォルトの名無しさん
垢版 |
2008/08/27(水) 00:24:48
Springスレが落ちたってのがDIはゴミってのを物語ってないか？
2008/08/27(水) 00:28:08
>>34
>ベンダ製のツール
そのベンダ製のツールの使用ガイドとかはちゃんとアナウンスされてるんだろうな？
「用意しました。後勝手に使ってね」ってのはマネジメントしてねぇ。

>規模なんてソースの品質には関係ないらしいよ
基本的には「ある」と思ってる
規模が大きくなればなるほど全体的なソースの品質は低下する

まあ上記のような問題を解決するための手段として
AOPやらDIみたいなのが出てきたのだけど
結局AOPやDIで何がやりたいかの理解が
実装者個人個人にまかされてしまってるのが問題な希ガス。
実装ガイドくらいではそこまでの統一はとりづらい。
で堂々巡りな状況に陥ってるような。
2008/08/27(水) 00:36:09
DIに興味ない人がたくさんてことを物語ってるとは思う。
興味ある人も取り立てて語る事なかったし。
気になって試して、気に入ったら使う。
ドキュメントが詳細だから疑問に持つこともない。

> 結局AOPやDIで何がやりたいかの理解が
テストとか便利にできるよ程度でいいんだけどね。
テスト極めようと思ってれば、気がつけば疎結合になってるだろうし、
適切なテストがきちんと通るなら品質には問題は出ない。
でも背景知らずにツールだけ知って、
使い方分からない、良さ分からないとか言ってる人が多数なわけで。
で、説明するのも面倒だから放置して
気が付くと自分しか使ってないとか、そんな感じ。
2008/08/27(水) 01:11:47
DIに限らないけど「技術に興味が無い人が使うツール」というところまで持っていかないと広まらないよ。
4334
垢版 |
2008/08/27(水) 02:04:26
>>36
笑いごっちゃーないですわ…

>>37
重々承知です。ご勘弁を

>>38
辞めるにしろ、対策するにしろ、具体策を考えてるところです。
ただ、このプロジェクトは今更どうこう出来る状態じゃないので、今ある部分は最後までそのままだと思われ。

>>40
そのベンダのツールは勿論マニュアル付きです。
つか、読まなきゃ使えないはず…
まあファクトリを理解せずに毎回 new しちゃってる、ってことなんだと思いますよ…

>>規模なんてソースの品質には関係ないらしいよ
>基本的には「ある」と思ってる
>規模が大きくなればなるほど全体的なソースの品質は低下する
…
次転職するときは面接で何を聞かなきゃいけないか良く分かった、ってことは最近痛感している。
2008/08/27(水) 02:27:13
>>42
その事を理解してないプロジェクトの多いこと多いこと
チーム内で最低のレベルにいるメンバーにも
問題なく使わせられるようにしないといけないのになぁ

>>43
>そのベンダのツールは勿論マニュアル付きです
そのマニュアルの内容にもよるけど
上で語っているようなレベルのもの？
マニュアルを自分が理解できたから
他人も理解するべきってのは違うぞ。

ちとマ的とゆうかPM的になっちゃたな・・・
2008/08/27(水) 21:26:50
>>39
ああ、落ちてる。せっかく立てたのに・・・。
46デフォルトの名無しさん
垢版 |
2008/08/27(水) 22:58:15
蜜結合でも機能ごとに分かれてた方が
結局後で分かりやすいんだよな
2008/08/28(木) 00:32:17
Springスレ立てないの？
SpringMVC語ってくれる人あそこくらいだったんでよく見に行ってたんだが
2008/08/28(木) 01:32:59
>>47
もはやS2の方が完全上位なんじゃね？
49デフォルトの名無しさん
垢版 |
2008/08/28(木) 06:20:19
学べば学ぶほど悲しくなる
無知こそ最強って感じだよorz
2008/08/28(木) 06:42:56
>>24
利用するDIコンテナに強く依存
2008/08/28(木) 08:15:02
>>49
相当流行ってからじゃないと勉強もイミないかも・・・
2008/08/28(木) 19:54:11
人は流れに乗ればいい
2008/08/28(木) 22:50:00
jspを書かなくていいとか、
せっかく覚えたのに。。。
2008/08/29(金) 01:48:31
>>47
俺もSpringMVCが好きなんだけど、
じゃぁ毎日語ることがあるのかと言われると、そんなものはない。
Spring スレは3年くらいスレが保守されてたが、
1.2.x が安定したころから、特に話題もなくなった。
2008/08/30(土) 01:50:09
>>54
SpringMVC悪くないんだけど、
あのControllerの深い継承具合はどうかと。
なんだよ、あのテンプレートメソッドの嵐。
せっかくDIコンテナなんだから、
ブリッジパターンとかもーちょっとすっきりできなかったのかよ。
2008/08/30(土) 19:32:22
引数戻り値に平気でコレクションの実装クラス使う連中にDIが理解できるはずがない
57デフォルトの名無しさん
垢版 |
2008/08/31(日) 14:28:16
Springはゴミですかそーですか
2008/08/31(日) 16:20:22
>>56
気持ちはわかる。なにも考えずにそういう事する奴は確かにいる。
メソッド全部publicとかと同レベル。

でもサービスクラスを書いてるときに、要素の入れ替えがあるから
LinkedListに使ってるよーとか、こいつは要素追加するとソートされるよ
とかを利用者に伝えるために戻り値の型を実装クラスで書いた方が
いいんじゃないかと思うこともある。
2008/08/31(日) 16:37:08
ファクトリを書かなくていいのにメリットがあるのは同意だけど、
起動時遅いとかメモリ喰うとかのデメリットもあるよね。

インジェクションするクラスを設定で簡単に切り替えられるのが
一番の目的だったと思うんだけど、本番環境にデプロイするのは
1パターンだけであまりメリットが感じられない。テスト用なら
こんな高機能いらなくて設定ファイルでObjectIdと実クラス名
の紐付けできるファクトリがあればいいだけだし。

似たようなシステムをちょこっとクラス入れ替えていくつも
リリースするような時には確かに有効。ソースツリーも
一つで管理できるし。でもそんなプロジェクト一回しか経験したこと無い。
Web側(jsp)は全然違うから別ソースだし。似たようなプロジェクトの時も
反省点を踏まえて作り直したりするし。

ファクトリのコード削減とAOPによるログ出力くらいなんでしょうか。
60デフォルトの名無しさん
垢版 |
2008/08/31(日) 17:09:36
>>50のレスが秀逸すぎるわ
2008/08/31(日) 20:56:39
>>59
起動遅いのはあまり問題にならんと言うか、
モジュールレベルで完璧に作れてれば
あとは組み合わせるだけなんで、別にどうでも・・
クライアントアプリなら問題にはなるけど
あまりそういう分野で使われてないだろうし。
逆に S2みたいな Hot-Deploy を売りにするセンスが俺には理解できない。
結局つながないと開発できないのかよ、それって DI かよって。

メモリってそんなに食う？これは実感したことないや。

日頃からテストがきちんとできる仕組み用意して
それを実践してるなら、別に DI コンテナ使う必要はないよ。
俺は自分で用意するの面倒だし、
自分のコードなんて全然信用してないから
十分にテストされたものを使うだけの話。
2008/08/31(日) 21:09:44
>>59
>ファクトリのコード削減とAOPによるログ出力くらいなんでしょうか。

それって大きいと思うけど。
それから宣言的トランザクションは使わないの？

今のプロジェクトで DI，AOP 使えれば良いのに、ってかなり思うよ。
ログ出力のコード分量もかなりなもんだし、
トランザクション制御の為に、サービスクラスに abstract execute() みたいなの強制してて超汚ねーし、
必要ない new をやたらと書きまくるやつはいるし（これは別問題か…）

慣れてきてから、DI 使わないプロジェクトで同じ事やろうとしてごらん。
汚いの面倒くさいの… 馬鹿らしくなるよ。
2008/08/31(日) 23:50:23
うちが使ってるフレームワークもどきみたいなのでは
ServiceとDaoは自動生成でSinleton生成コード吐くし、
bean idとクラス名結びつけるファクトリは枯れたxml読み込み
クラスを利用して1クラスで完結してるんですわ。

private AnyService anyService;
と宣言してアクセッサ用意するより
private AnyService anyService = AnyService.getInstance();
で設定したクラスをインスタンス化できた方が若干楽だし
publicなget/setAnyService()があるとそれを利用側プログラムで
呼び出していいと思われても嫌だし。springでセットしたserviceが
入ってるからgetしても問題は無いんだけど。

そうするとspringしらない技術者がヘルプで入ってきたときに
DIっていうのはねっていうところから説明するより全然
教育コストも低いんですよ。

起動が遅くなるのはEclipseでデバッグ時にちょっとした修正で
いちいち時間かかって精神衛生上よくないっていうだけで根本的な
問題ではないけど。

2008/08/31(日) 23:57:13
AOPによるログ出力はブレークポイントつけてステップ実行が当たり前に
なった今存在意義が薄いし、ソースの骨格が自動生成でこみいったとこだけ
手で実装なので、むしろうまく行っているところはトレースログとりたくないし。

トランザクションは昔から使ってるDBコネクションプールがThreadLocalで
好きなとこでstart()/commit()させてくれるのでこれをService内に
明示的に書いてある方が問題があったときにどこでcommit()/rollback()
されてるかわかりやすいと思うんだけど、もう俺の考えが古いのかなあ。
デバッグ担当する人間が全員springのxmlの仕様を知っていないと
「どこでコミットされているかすぐに把握できない」のはめんどくない？
ずっと少数精鋭主義のプロジェクトでやっていけるなら別だけど
2008/09/01(月) 00:04:32
自己レスだけど
>bean idとクラス名結びつけるファクトリは枯れたxml読み込み
>クラスを利用して1クラスで完結してるんですわ。

結局DIしてるわけだからこのスレとは違っちゃうか
2008/09/01(月) 00:29:30
>>63
それでうまくプロジェクトが回ってるならそれでいいと思う。

教育コストはDIがどうこうよりも、
テストファーストがどうこう、
ステートレスがなんやら、
疎結合だとあれこれ・・の説明に苦心しない？
「ふーん、面倒なんですね」の一言で片づけられた日には悲しくなったよ。
で、今日もまたテストケース書かないコードをコミットしやがる・・・
2008/09/01(月) 00:40:51
＞AOPによるログ出力
俺もこれは例示のための例示にしか過ぎないと思う。
通常、AOPはメソッド境界で作用するけど
このレベルで横断的にログ取りたいものなんて殆どないし。
メソッド内部の動作で不審な動きがないかチェックしたいとは思うけど、
取得したい情報なんて処理ごとに異なるし、そもそもAOPでは制御不能。
AOP使う話であれば、トランザクションと認証回りが適切な例だと思う。

＞少数精鋭主義のプロジェクトでやっていけるなら
別に精鋭じゃなくても設定くらい読めるから。
トランザクションが何か分かってるなら、書き方・読み方教えて終了。
いろんな場所でトランザクションの開始・終了が出来れば
きっと効率が良いのだろうけど、少数精鋭ならともかく
現実の開発でそれやるとロクなことにならんですよ。
好き勝手に開始して放置して、もうグダグダ。
多分、今まで少数精鋭でやってきて、そういう事態に陥らなかったんだと思う。
2008/09/01(月) 01:09:29
正直テストファーストはどうかなあと思ってる。
昔みたいにウォーターフォールで仕様変更したら別料金とりますよっていうなら
いいけど、仕様が変わる度にテストケースも保守していくのは
常に詳細設計ドキュメントを保守し続ける位面倒。んで最後にまとめて
作ろうと思って納期迫ってカバレッジ低いテストケース書いてるから
それも駄目なんだけどね。

AOPは結局ログくらいしか思いつかなかったんだよね。Webばっかりだから
認証はそれこそBaseActionかInterceptor(struts2)で入り口でやってあげれば
済むし。

springだけを教えてるなら設定くらいすぐ覚えるだろうけど、
プロジェクト参加当初は業務もプログラムも教えることいっぱいだし、
問題があったときにデバッガで追ってればすぐわかる方がいいと思うけどなあ。
トランザクションの開始・終了はServiceクラス内の同一メソッドでとルールで
縛ってるので、というかdaoも自動生成で複数テーブルに対するトランザクション
管理をしたいと思ったらこれしか書きようが無いんだ
try{
　DBManager.startTransaction();
　dao1.insert(obj1);
　dao2.insert(obj2);
　DBManager.commit();
}catch(...){
DBManager.rollback();
}
daoが自動生成なせいで、複雑なDBも処理もdaoに書いて
serviceから呼び出す、daoでトランザクション管理しない
っていうのが徹底されてるのが効いてるのかな。

2008/09/01(月) 09:45:29
横道にそれるけど、なんか同情したのでいきなりレス。

>>66
Unitテストが義務化されていないからだな。
これはかなり大変。「テストを楽にする」は
意外に動機として大きいから。

仕様書が明確に落ちて無いと末端の子に
テストファーストは難しいけど、デグレードを
未然に防ぐ為のテストセカンド（造語）くらいから
やるのはどうだろう。
自分のコードにバグが無いことの証明だから
ホントはやってて当たり前なんだけど。
7069
垢版 |
2008/09/01(月) 09:47:40
続き。

疎結合は再利用性。
「ほら、別のプロジェクトでも簡単に使いまわし
できただろ？」
って言える例を作ってやれればどうにか。

ようは教える側がメリットを示すのが良いと思う
（デグレードが減る。使いまわしが楽など）。

ただし、教えられる側が
・時間内手を動かしてさえいれば金が貰える
・バグで人に迷惑をかけてもかまわない
そんな思想だと哲学から変えないとダメ。
2008/09/01(月) 10:06:33
いろいろ経験して
「newを直に書きたくない」
という思想にいたる事が出来れば
DIコンテナのメリットが説明しやすい。

結局ある程度抽象化の概念に
同意していない人には無用の長物かも。
72デフォルトの名無しさん
垢版 |
2008/09/02(火) 00:22:13
>>70
疎結合でサービスクラスやアクションを使いまわしたりしないし
その説明では納得できん。ただ共通関数を増やしていくだけでいいだろうに
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況