Javaの道 Javaに関する
　ニュース｜Java基本｜Servlet・JSP｜オープンソース｜FAQ｜掲示板
Javaの道 >  掲示板 >  掲示板（DIのメリット）
閲覧数：1170
掲示板（DIのメリット）
名前
匿名
題名 DIのメリット
質問内容

質問を評価する
(0ポイント)
DIコンテナの利点として、インターフェースと業務ロジックを切り離すことができ、
実装クラスを動的に変更できることを謳っています。

ただ、実際にバインドされるクラスは設定ファイルに記載する必要があり(Autoバインドとかもありますが)、
たとえば、リクエストパラメータによってバインドするクラスを切り替えるといった例は見たことがありません。

そのようなことは可能なのでしょうか？
また、上記のことができない場合、DIのメリットは本当にあるのでしょうか？
たとえば、DBコネクタの実装クラスをDIで変更できるといわれても、DBを切り替えるような大規模改修なら当然アプリケーション全体をリプレイスするはずなのでメリットとは思えません。
質問日時 2012-12-27 16:26:53
名前
匿名
回答内容

回答を評価する
(0ポイント)
私はspringを4年ほど使用しているプログラマです。
まだまだ勉強中なので、間違えていることもあるかと思いますが、私の考えを記述します。

＞たとえば、リクエストパラメータによってバインドするクラスを切り替えるといった例は見たことがありません。

springしか使ったことはありませんが、自分で仕組みを作らないといけないかと思います。


＞DIコンテナの利点として、インターフェースと業務ロジックを切り離すことができ、
実装クラスを動的に変更できることを謳っています。

確かに本などにはそう記述されているかと思います。
しかもspringを使用する多くの人は「インターフェースと業務ロジックを切り離して・・・」という方が多いです。
ただ開発手法にもよるかと思いますが基本、インタフェース１に対して実装が１つのみです。業務ロジックはプログラムにそれ程詳しくない人も記述するのでインタフェースに対して実装が複数にすると混乱を生みます。
ライブラリやフレームワークの場合はインタフェース１に対して実装が複数となる場合が多いと思います。

クラス生成などのコードをプログラム内に記述しなくて済む
またアプリケーションコンテキストを確認すると、ある程度プログラムの全体像が分かる
といったことが利点ではないかと考えています。
回答日時 2012-12-27 22:09:27
名前
匿名
回答内容

回答を評価する
(0ポイント)
例えばテスト環境と本番環境で実装を変えたり。
例えばホストによって実装を変えたり。
…といったことをするのに、設定ファイルの差し替えだけで複数の箇所が切り替わってくれる。

そのときそのときの「ユーザの」要求に応えるためのもんじゃないでしょ。
回答日時 2012-12-27 22:14:57
名前
匿名
回答内容

回答を評価する
(0ポイント)
質問者です。

> クラス生成などのコードをプログラム内に記述しなくて済む
newするのって、そんなに面倒でしょうか？
逆に実装クラスがなんなのか、いちいちxml見ないといけない方が面倒だったりしませんか？

> またアプリケーションコンテキストを確認すると、ある程度プログラムの全体像が分かる
すみません、ちょっとよくわからないのですが
<bean>タグの羅列を見てプログラムの全体像がわかるとおっしゃってます？
だとしたらすごいです、自分は見ても頭が痛くなるだけなので・・・

> 例えばテスト環境と本番環境で実装を変えたり。
> 例えばホストによって実装を変えたり。
これは今までもpropertiesなどで十分できましたよね？
あえてDIにするメリットは何でしょう？
回答日時 2012-12-28 11:05:26
名前
匿名
回答内容

回答を評価する
(0ポイント)
私もDI懐疑派ではありますが、ユニットテストツールを
用いたテストファーストが義務付けられている案件の場合
はDIコンテナを選択するかもしれません。

DIコンテナの利点はユニットテストを実施する上で不都合な要素、例えば
　・J2EE API, JDBC
　・MVC系とORマッパ系の繋ぎ部分
等の依存性を排除し疎結合に実装出来る部分だと考えてます。

よく疎結合というと自前の実装クラス間を疎結合にする使い方を見たり
しますが、用途として間違ってる気がします。

ユニットテスト・本稼動を通して１インターフェース１実装に
なってしまう場合は、分断してはいけない依存性をDIをしてる可能性が高く
DIする必要が無いか意義が薄いのだと思います。

10人月くらいの小規模案件でMVCだけで済みそうなものには
簡単なファクトリがあれば同様のことはできるので、
無理に適用してませんね。。
(トランザクション制御は自前になりますが）
回答日時 2012-12-28 12:01:41
名前
匿名
回答内容

回答を評価する
(0ポイント)
単なるプロパティだと、それを読んでクラスをインスタンス
化し、該当するフィールドへ割り当てるコードも必要だし、
実際書いてるよね。
でも、それは業務とは何ら関係ないロジックだよね。

業務と関係ない作り込みはなるべく隠そうってのが、ツール
やフレームワークの目的の一つじゃないのかね。

と言いつつ、自分も案件で指定されてたときしか使ったこと
ないんだけど。
回答日時 2012-12-28 20:32:18
名前
匿名
回答内容

回答を評価する
(0ポイント)
１つ目に回答したものです。

＞<bean>タグの羅列を見てプログラムの全体像がわかるとおっしゃってます？
条件がありまして、社内のライブラリを使用し尚且つ、ある程度の命名規約などを守っている場合です。
まったく知らない人が自分で作成したルールで、私の知らないライブラリで作ったものに関しては、だめだと思います。

> 例えばテスト環境と本番環境で実装を変えたり。
> 例えばホストによって実装を変えたり。
私もその辺りは環境設定ファイルで対応しています。

＞newするのって、そんなに面倒でしょうか？
結局のところ、私がspringを使っている理由としては社内でspringを使用した社内ライブラリが存在した。
その社内ライブラリを私が更に拡張した。
というのが、一番の理由です。回答になっていませんが。。。

properties、csv、xmlなどのファイルを読み込んで値のチェックを行い
クラスをnewして必要な定義値をそれぞれのクラスに設定していく。
この辺りをspring+社内ライブラリでやってます。この辺の設定を簡単なxmlで記述できるのは魅力的かと。

逆にこの辺りの処理を行って貰えないのであれば、自分でnewしてクラスを生成しても大して作業効率に影響しないかもしれません。
回答日時 2012-12-28 20:34:25
名前
匿名
回答内容

回答を評価する
(0ポイント)
質問者です。

色々な意見ありがとうございます。
納得できる部分もあれば、いまいちピンとこない所もあ
りますが、
結局トレンドの問題なのかな？と思い始めています。
流行ってる技術なら人も集めやすいし、教育コストも必
要ない。
人が多ければナレッジもたまるし便利なツールも増える
と。

たとえるなら、WindowsXPに比べて7(8はちょっと違う
かな)のメリットはなんだ？
と同じで、絶対的なメリットもないが、あえて今更XP
にするか？みたいな。
回答日時 2012-12-29 00:45:18
名前
匿名
回答内容

回答を評価する
(10ポイント)
人によって重視する点が違うんだから、メリット、デメリッ
トも人による。
君がメリットだと思わなくても仕方がない。
仕事でなきゃ、使わないといけないってこともないし。

もっとも、クラスの外部指定にDIではなくプロパティを使っ
たところで手間の問題でしかないが、7/8の代わりにXPを使う
のは、堅牢性という別の問題があるけど。
回答日時 2012-12-29 01:11:54

質問から6ヶ月以上経過しているので、回答を書き込むことはできません。



このページのトップへ
　ニュース｜Java基本｜Servlet・JSP｜オープンソース｜FAQ｜掲示板
Javaの道_CopyrightJavaの道