5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Dependncy Injectionを語るスレ

1 :デフォルトの名無しさん:04/11/07 20:32:05
依存性注入ということらしい。IoCともいわれる。
最近注目を集めているがその是非を論じてみよう。

参考
ttp://cvs.picocontainer.codehaus.org/viewrep/~raw,r=1.1/picocontainer/site/presentations/JavaPolis2003_ja.ppt
ttp://www.kakutani.com/trans/fowler/injection.html

851 :デフォルトの名無しさん:2005/10/19(水) 22:59:02
結論としては、モック意外に使い道無し>DI

852 :769:2005/10/19(水) 23:03:07
>結論としては、モック意外に使い道無し>DI
たとえば、単純な構成ならよいのだろうけど
複数のクラス群がまとめてモックを構成しているとしたら
設定ファイル変えるのと、Factoryクラスの置換とどっちが楽なのだろうか

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

853 :デフォルトの名無しさん:2005/10/19(水) 23:03:58
「拡張性が高い」ってのは、改造や機能追加が、手間を掛けずに正しく行える、という事。

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

854 :デフォルトの名無しさん:2005/10/19(水) 23:05:25
>>850
全部のオブジェクトをコンテナ管理するかどうかに拘ってるのは何故?
普通、DI導入するなら自作クラスは全てDIコンテナで管理する。
ほとんどがステートレスのシングルトンオブジェクトになるから、それをStragetyパターン等で組み合わせる

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

855 :デフォルトの名無しさん:2005/10/19(水) 23:07:56
>>850
ちょっとこった帳票とか作った事がない人は幸せである。
NVLだのDECODEだのConvertだの使った事がないから。

856 :デフォルトの名無しさん:2005/10/19(水) 23:08:02
本当に複数のデータベースで動作しなければならない場合は非常に少ない。

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


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

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

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

858 :デフォルトの名無しさん:2005/10/19(水) 23:45:13
>>854
> 普通、DI導入するなら自作クラスは全てDIコンテナで管理する。

げ。そうなの?

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

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


859 :769:2005/10/19(水) 23:49:52
>> ほとんどがステートレスのシングルトンオブジェクトになるから
>普通にオブジェクト指向で設計して、自作クラスのほとんどがそうなる
>というのは普通に理解しがたい。

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

860 :デフォルトの名無しさん:2005/10/19(水) 23:50:51
>>859
別名、手続き型w

861 :769:2005/10/19(水) 23:52:04
>>860
わかる、いいたいことはわかる
おれもじぶんで「こりゃねーだろ」とはよく思う

862 :デフォルトの名無しさん:2005/10/19(水) 23:56:54
>859
引数の数が増えすぎていない?
リファクタリングしてる?


863 :デフォルトの名無しさん:2005/10/20(木) 00:00:31
>>857
そもそも「コンテナ」という言葉自体が、船やトラックを連想させて重たく感じるな。

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

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

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

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

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


866 :769:2005/10/20(木) 00:23:16
>状態によって動的にオブジェクトを変動させるような動き(ステートパターンやコマンドパターンなど)には向かない
そうそう、Strategyって聞いた時それは思った

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

867 :デフォルトの名無しさん:2005/10/20(木) 00:24:06
>>859
> その引数を一つのまとまったクラスにして汎用引数クラスとして

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

868 :デフォルトの名無しさん:2005/10/20(木) 00:27:46
>>864
話だけ聞くとDIを適用するためにオブジェクト指向的に自然な設計を
捻じ曲げているのでは?……という風にも聞こえる。

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

869 :デフォルトの名無しさん:2005/10/20(木) 00:28:56
>865
多すぎる引数(78)
ttp://www.objectclub.jp/technicaldoc/refactoring/refact-smell#4


870 :769:2005/10/20(木) 00:30:18
>>867
クラス設計に関してはすべてにおいて自分で説明できるぐらい自信あったが
最近何が正しいのか作っている途中にわからなくなっている場合がある・・・

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

872 :デフォルトの名無しさん:2005/10/20(木) 00:50:05
>>852
>設定ファイル変えるのと、Factoryクラスの置換とどっちが楽なのだろうか

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

873 :デフォルトの名無しさん:2005/10/20(木) 00:54:46
そこでアノテーションですよ

874 :デフォルトの名無しさん:2005/10/20(木) 02:45:21
>>870
なんとなくわかる気がする。
どこまで引数にするのかってことに悩んでしまうんだ。
引数を減らせば減らすほど同じ概念で扱える可能性が上がる。
これはこれで気持ち良いのだけど、状態を持たねば動けない
クラスが増える。引数を増やせば今度はどんどん具象に
近づいてく。ここのさじ加減に悩む。

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


875 :デフォルトの名無しさん:2005/10/20(木) 13:27:58
Strategyパターンで作れるところや、サブシステムの構成とか疎結合にしたいところにはいいが
密結合のほうが都合のいい場面もあるわけで。
純粋にDIにしたほうがいい場面ってのはそこまで多くないんじゃないか?
とはいえ疎結合にしてるとやっぱいいね。
あと、SpringはAOPでのトランザクション管理とかあるしね。
ま、黄金のハンマーはないってことだな。

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


876 :デフォルトの名無しさん:2005/10/20(木) 23:00:57
結論:手続き型で構造化プログラミング、これ最強。

877 :デフォルトの名無しさん:2005/10/20(木) 23:21:40
DIはいいけどXMLイラネ

878 :デフォルトの名無しさん:2005/10/20(木) 23:32:14
そうそうやっぱINIファイルだよね

879 :デフォルトの名無しさん:2005/10/20(木) 23:47:55
いやpropertiesファイルだよやっぱ。
native2asciiバチコーン

880 :デフォルトの名無しさん:2005/10/21(金) 01:06:41
java.util.PropertiesもXMLファイルを読み込むようなこんな世の中じゃ

881 :デフォルトの名無しさん:2005/10/21(金) 12:12:23
ステートレスというのがよくわからないんだが、純粋関数の集合をクラスにしたという理解で合ってる?

882 :デフォルトの名無しさん:2005/10/21(金) 19:29:07
>>881
ここではメンバ変数がない、ぐらいの意味。

883 :デフォルトの名無しさん:2005/10/21(金) 23:02:32
つまり、サブルーチン集の事ですね。

884 :デフォルトの名無しさん:2005/10/21(金) 23:18:26
俺のサブルーチン集100ゴールドでかわね?

885 :デフォルトの名無しさん:2005/10/22(土) 01:01:12
↑いらね

886 :デフォルトの名無しさん:2005/10/22(土) 15:29:19
基礎的な質問で、スマソ。
DIの依存性注入の意味なんだが、
A→B→C
と呼び出しているとき、BとC間の依存性の注入を意味しているのか、
AとBの間の依存性の注入も意味しているのだろうか。
つまり、B→C間の依存性は初期化時に決定され、アプリケーションの
動作中は代わることはないのだが、A→Bについては、
Aに渡されたパラメータに応じて、呼び出すBが変わる場合、
これはDIには当たらないのだろうか。


887 :デフォルトの名無しさん:2005/10/23(日) 07:33:13


888 :ハーピィ:2005/10/23(日) 23:13:11
E・∇・ヨノシ <888ゲット♫

889 :デフォルトの名無しさん:2005/12/29(木) 12:07:42
Java World の今月の特集がフレームワークの話で
「最近はDIコンテナベースが普通だよもん」とか書いてあったのだが
俺の周りは実装クラスでガチガチな設計ばかりで泣きそうになる。

890 :デフォルトの名無しさん:2005/12/29(木) 13:16:07
EJB3が流行りだせば、自然にDIベースになる。
心配するな。

891 :デフォルトの名無しさん:2006/01/05(木) 08:51:55
「普通だよもん」は言い過ぎの気がするなぁ。

892 :デフォルトの名無しさん:2006/01/21(土) 01:03:39
PicoContainer 1.2がやっと出たぜ。
おれこのコンテナ、起動もコンポーネント取得も速いんで結構好き。
まあXML解析の時間がゼロだからだろな。

893 :デフォルトの名無しさん:2006/02/07(火) 01:05:51
JBossのMicroContainerに手を伸ばしている人はいる?
ちょっとみてみたけど,SpringとかSeasar2のような意味でのDIコンテナとはちょっと違うみたいな気が…
あくまでKernelにBeanを埋め込むための設定ファイル処理エンジンみたいな感じがする。

894 :デフォルトの名無しさん:2006/02/08(水) 20:11:39
DIって予め使うクラスをオブジェクト化してプールしておくことで
何度もクラスを使う時、いちいちオブジェクトを生成しなくていいという利点
もあったりするのでしょうか?

895 :デフォルトの名無しさん:2006/02/08(水) 22:01:55
logic や DAO はスレッドセーフに作って
コンテナ内で唯一のオブジェクトを使いまわすのが普通。
結果的にそういう運用が多くなるだけであって
DIの利点であるとは思えません。

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

896 :デフォルトの名無しさん:2006/02/09(木) 00:34:49
>>895
ありがとうございます。
参考になりました。

897 :デフォルトの名無しさん:2006/06/14(水) 00:45:04
> logic や DAO はスレッドセーフに作って
> コンテナ内で唯一のオブジェクトを使いまわすのが普通
これはなぜですか?

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

ってところかと。

899 :デフォルトの名無しさん:2006/06/15(木) 00:52:14
おまいらそんなに生成が思いlogicやDAO作ってんのか?

900 :デフォルトの名無しさん:2006/06/15(木) 01:58:11
もういっその事設定ファイルじゃなくてDBでいいんじゃね?

244 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)