Dependncy Injectionを語るスレ

結論としては、モック意外に使い道無し＞DI

＞結論としては、モック意外に使い道無し＞DI
たとえば、単純な構成ならよいのだろうけど
複数のクラス群がまとめてモックを構成しているとしたら
設定ファイル変えるのと、Factoryクラスの置換とどっちが楽なのだろうか

全然関係ない話になるけど
設定ファイルってやっぱアプリケーション再起動しないと反映されないのね？

「拡張性が高い」ってのは、改造や機能追加が、手間を掛けずに正しく行える、という事。

んで、DI信者の言う「拡張性が高い」は「改造が少数のクラスの変更で実現できる」の意味だが、
現実には、多数のクラスを少しずつ改造した方が、手間が掛からず設計もコードもシンプルに保てるケースが割と多い。

>>850
全部のオブジェクトをコンテナ管理するかどうかに拘ってるのは何故？
普通、DI導入するなら自作クラスは全てDIコンテナで管理する。
ほとんどがステートレスのシングルトンオブジェクトになるから、それをStragetyパターン等で組み合わせる

あと、別にオブジェクトのプール機能を目的としてはいないから、簡単にオブジェクトのプール数を取得できるようなコンテナは無いと思う
レスを読んでると、何か根本的にDIコンテナの存在理由を履き違えてる気がするが・・・

>>850
ちょっとこった帳票とか作った事がない人は幸せである。
NVLだのDECODEだのConvertだの使った事がないから。

本当に複数のデータベースで動作しなければならない場合は非常に少ない。

ほとんどの土方プログラマは、データベースが変わる可能性を気にする必要はない。

>>854
＞レスを読んでると、何か根本的にDIコンテナの存在理由を履き違えてる気がするが・・・
まぁ、実際ここに顔を出すには早すぎる感があると思っている
いまんとこ、DIについてこのスレの内容しか見てないし（しかも、偏ったり間違った意見もあるだろう）
「言う前に自分で理解して来い」と言うならそれまで消えるんですが

＞全部のオブジェクトをコンテナ管理するかどうかに拘ってるのは何故？
僕は、いまのところDIはTomcatの設定ファイルContect要素に書かれるDBソースの定義と同じようなものだと考えているんです
そべてのものをそこで管理するのは重たくない？（役割として重過ぎるの意）って思っています現状

＞ほとんどがステートレスのシングルトンオブジェクトになるから、それをStraｔeｇyパターン等で組み合わせる
う〜ん、なるほど　自分はどちらかと言うとコマンドパターンを多用するタイプで、そっちの考えは今までなかった

>>854
> 普通、DI導入するなら自作クラスは全てDIコンテナで管理する。

げ。そうなの？

> ほとんどがステートレスのシングルトンオブジェクトになるから

普通にオブジェクト指向で設計して、自作クラスのほとんどがそうなる
というのは普通に理解しがたい。

>＞ ほとんどがステートレスのシングルトンオブジェクトになるから
＞普通にオブジェクト指向で設計して、自作クラスのほとんどがそうなる
＞というのは普通に理解しがたい。

なんか、実装段階で突き詰めてクラスを作っていると、ステートレスになることは（自分は）よくある
シングルトンになるかどうかは知らんけど

>>859
別名、手続き型ｗ

>>860
わかる、いいたいことはわかる
おれもじぶんで「こりゃねーだろ」とはよく思う

>859
引数の数が増えすぎていない？
リファクタリングしてる？

>>857
そもそも「コンテナ」という言葉自体が、船やトラックを連想させて重たく感じるな。

>>857
全部と言うと、ちょっと語弊があったかもしれない
基本的にDIコンテナは、初期化で全てのコンポーネントの関連付けを決定する仕組みなので
状態によって動的にオブジェクトを変動させるような動き（ステートパターンやコマンドパターンなど）には向かない
だからDIコンテナを使って開発すると、状態と振る舞いを分離して作るような方向に向かいがち

普通にクラスを作ってると、フィールドに状態を持ち、継承を使ってメソッドをまとめたりテンプレートパターン使ったりすると思う
DIを使った場合、フィールドには部品化されたステートレスなクラス群を持ち、
メソッド引数で状態を貰って、処理を委譲しながら全体的な処理を行う・・・ような作り方がやり易くなる

＞引数の数が増えすぎていない？
ああ、それに陥ったコード見るとそうなってる
だもんだかから、その引数を一つのまとまったクラスにして汎用引数クラスとして・・・とか言う事をいつのまにか考えている
最終的に出来上がるものはバランスのいいものが出来上がるのでいいのだけど。
まぁ、そういうことゆっくり考えれるのも仕事以外の時だけなので結構面白いけど

＞リファクタリングしてる？
これは「引数の数」と関係あるの？解説ヨロ

来月から新規に立ち上げるプロジェクトで、リーダがDI使おうとか（そいつもよくわかってないくせに）言っている
メンバー内にJavaすら扱った奴自分以外一人もいないので、他の人のためにもあまりDIのように難しい事をやるべきではないと思っている
がしかし、それならそれできちんとした説明責任があるのでこのスレ見ているんだが・・・
ぱっと見る限り一番標準的なのはSpringだろうか？
実はJSFも使う事が決定しているのでそのコンポーネントもDIコンテナ管理にすべきなんだろ？ここの住人的には。
自分はJSFは経験あるのでよいのだが他のメンバはJava＋JSF+DIだろ・・・かなり辛いと思う

＞状態によって動的にオブジェクトを変動させるような動き（ステートパターンやコマンドパターンなど）には向かない
そうそう、Strategyって聞いた時それは思った

＞・・・
なるほど、よくわかります

>>859
> その引数を一つのまとまったクラスにして汎用引数クラスとして

Cだとよく見る。何でも突っ込んでる「環境」と呼ばれる
超巨大な構造体。
typedef struct vi { ..................... };
で、どんな関数も引数にstruct viのポインタを取る、という
とても素晴らしい世界。

>>864
話だけ聞くとDIを適用するためにオブジェクト指向的に自然な設計を
捻じ曲げているのでは？……という風にも聞こえる。

そもそも、Strategyを適用したくなるようなケースってそう多いとも思わない
んだけれども。

>865
多すぎる引数(78)
ttp://www.objectclub.jp/technicaldoc/refactoring/refact-smell#4

>>867
クラス設計に関してはすべてにおいて自分で説明できるぐらい自信あったが
最近何が正しいのか作っている途中にわからなくなっている場合がある・・・

>>868
自分も使う前に調べてる中でそう思ったｗ
Strategyはようするに、クラス毎に簡単に実装を切り替えられる為に用意してる印象
クラスは非常に分割・部品化しやすくなるし、その切り替えも設定ファイル一発で出来るようになる。
ただ、「状態」を扱うのがちと独特になりがちな面は否めない
実際に使ってみると、確かに便利で手放せないと思った。
気に入るかどうかは人次第、システム次第かもしれないが
定型的業務系システム構築には向いているんじゃないかと個人的には思う

>>852
>設定ファイル変えるのと、Factoryクラスの置換とどっちが楽なのだろうか

ソースはコンパイラが厳しくチェックするが、
設定ファイルはtypoですらスルー。下手をすれば実行するまでノーチェック。

そこでアノテーションですよ

>>870
なんとなくわかる気がする。
どこまで引数にするのかってことに悩んでしまうんだ。
引数を減らせば減らすほど同じ概念で扱える可能性が上がる。
これはこれで気持ち良いのだけど、状態を持たねば動けない
クラスが増える。引数を増やせば今度はどんどん具象に
近づいてく。ここのさじ加減に悩む。

ステートレスは結果的にめいっぱい具象に近づくし、
引数無しのコマンド型にまで落とし込むと思いっきり抽象。

Strategyパターンで作れるところや、サブシステムの構成とか疎結合にしたいところにはいいが
密結合のほうが都合のいい場面もあるわけで。
純粋にDIにしたほうがいい場面ってのはそこまで多くないんじゃないか？
とはいえ疎結合にしてるとやっぱいいね。
あと、SpringはAOPでのトランザクション管理とかあるしね。
ま、黄金のハンマーはないってことだな。

ついでに、設定ファイル監視して変更あったらSetter叩き直すとかできたら便利かも。
激しくchaosになりそうだが。

結論：手続き型で構造化プログラミング、これ最強。

DIはいいけどXMLｲﾗﾈ

そうそうやっぱINIファイルだよね

いやpropertiesファイルだよやっぱ。
native2asciiバチコーン

java.util.PropertiesもXMLファイルを読み込むようなこんな世の中じゃ

ステートレスというのがよくわからないんだが、純粋関数の集合をクラスにしたという理解で合ってる？

>>881
ここではメンバ変数がない、ぐらいの意味。

つまり、サブルーチン集の事ですね。

俺のサブルーチン集１００ゴールドでかわね？

↑いらね

基礎的な質問で、スマｿ。
DIの依存性注入の意味なんだが、
Ａ→Ｂ→Ｃ
と呼び出しているとき、ＢとＣ間の依存性の注入を意味しているのか、
ＡとＢの間の依存性の注入も意味しているのだろうか。
つまり、Ｂ→Ｃ間の依存性は初期化時に決定され、アプリケーションの
動作中は代わることはないのだが、Ａ→Ｂについては、
Ａに渡されたパラメータに応じて、呼び出すＢが変わる場合、
これはＤＩには当たらないのだろうか。

E・∇・ﾖﾉｼ　＜888ｹﾞｯﾄ♫

Java World の今月の特集がフレームワークの話で
「最近はDIコンテナベースが普通だよもん」とか書いてあったのだが
俺の周りは実装クラスでガチガチな設計ばかりで泣きそうになる。

EJB3が流行りだせば、自然にDIベースになる。
心配するな。

「普通だよもん」は言い過ぎの気がするなぁ。

PicoContainer 1.2がやっと出たぜ。
おれこのコンテナ、起動もコンポーネント取得も速いんで結構好き。
まあXML解析の時間がゼロだからだろな。

JBossのMicroContainerに手を伸ばしている人はいる?
ちょっとみてみたけど，SpringとかSeasar2のような意味でのDIコンテナとはちょっと違うみたいな気が…
あくまでKernelにBeanを埋め込むための設定ファイル処理エンジンみたいな感じがする。

DIって予め使うクラスをオブジェクト化してプールしておくことで
何度もクラスを使う時、いちいちオブジェクトを生成しなくていいという利点
もあったりするのでしょうか？

logic や DAO はスレッドセーフに作って
コンテナ内で唯一のオブジェクトを使いまわすのが普通。
結果的にそういう運用が多くなるだけであって
DIの利点であるとは思えません。

特別に Singleton を作ろうとせずに済むのは利点。
(スレッドセーフは意識しないといけないが)

>>895
ありがとうございます。
参考になりました。

> logic や DAO はスレッドセーフに作って
> コンテナ内で唯一のオブジェクトを使いまわすのが普通
これはなぜですか？

>897
・生成処理が比較的重いと想定される。
・リクエスト-レスポンスで完結させて、状態を持たせないようにした方が見通しがいい。
　（このレイヤは状態を持つべきでない、と言い切る人もいる。)
→「生成は一度にして唯一のインスタンスを使いまわせばいい。
　　スレッドセーフに作る必要はあるが、状態を持たないならそれは簡単。」

ってところかと。

おまいらそんなに生成が思いlogicやDAO作ってんのか？

もういっその事設定ファイルじゃなくてDBでいいんじゃね？