【Java】DIコンテナって本当に便利か?
■ このスレッドは過去ログ倉庫に格納されています
インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどw インジェクション設定が増えすぎるアンチパターンを懸念すると
テストの設計とDIでセットにするのが良いかもしれん interfaceを書きながら設計していく感じが多いかな
implするクラスも同時に書いていくと、設計が終わる頃にはスケルトン+モックにもなるクラスができてる >何十とあるControllerやService、Daoに対して
なんで一対一でinterface用意する必要があるの…?
根本的にわかってないとしか言いようがない インターフェイスをDIのタグとして使ってるってことかw DIって言葉も、なんかMVCと同じでぼくの使ってる最強のDIみたいなのが十人十色で意思疎通難しいし
もうNGワードにしたほうがいいんじゃないか >>439
開発当初は1対1しかないかもしれないけど、
あとから増える場合もあるので、そういった時には、インターフェースと実装クラスを分けておいてよかったと思うよ。
まぁ、これから作ろうとしているシステムが、使い捨て(寿命が短い)であまり変更を考慮しなくていい場合と、
ある程度長くなりそうな場合とで、手間とのトレードオフもあると思うけど。 >>442
使い捨てがどうのともっともらしいことを言っているけど、
単に実装をIFを分離すべきポイントをちゃんと設計出来る能力が無いから
とりあえずなんでも分離しておく、っと言っているようにしか聞こえない。
そんなんで良いのか? DIのために一対一にするくらいならクラスを指定してDIすればいいだろってこと >>444
そう言われると反論できない。
突貫工事が多いから、とりあえず *Dao と *Service は
インターフェースと実装クラスに分けとけ、というルールを決めて、
開発に着手していたことは多かったな。
いちいち
・こういうケースは分離しましょう
・こういうケースは分離しなくていいです
というルールを考えている余裕がなかったので。 そういう機械的な設計でいいと思うけどね。
堅実というか無難というか。 実装クラスでメソッド追加した際に
インターフェイス側に宣言コピペするだけだしな
ファイル分けるもの面倒臭い
public interface A {
void f();
public static class Imp implements A {
public void f(){}
}
} なんかよくわからんなー
DIとなんの関係がある話なのかすらよくわかんない
Cのプロトタイプ宣言の話聞いてるみたいだ DIで注入される側
FooServiceImplならFooService型の定義になってて
BarServiceImplならBarService型の定義…みたいなことやってるってこと言ってるの? もうDaoでインターフェイスを分離する意味ないだろ
昔ならモックに差し替えるのに必要だったが intra-martの人達ってまだS2押してんの? >>140
>>351
>>444
話が合いそうだ
・直列化とビルダーパターン使うべきポイント
・マクロやジェネレータ使えばいいんじゃね?ってポイント
・なぜプログラムの修正をそんなに怖がる?ってポイント
・なぜファクトリの数行を面倒臭がる?(コード書けば言語解析による依存関係調査が可能だし、可読性も高まるのに)
って、結構どうでもいいところでDI使ってる人が沢山いる。
結局、普通のオブジェクト指向に対するシンタックスシュガーに過ぎないので、
経験のない人間が下手に使うと、どう再利用すればいいのか分からない、ゴミ山のような小さいクラス群と
環境によって内容が違う定義ファイルに道を迷わされる。。。
労働集約型産業やりたいのなら、COBOLとか実は良い言語だぜ?
DIコンテナ使ってるのに結局ダウンキャストしてるとか、
それを避けるために(?)インターフェースと実装を1:1にして、同時にメンテしていくとか
そんな使われ方をしている所にしか出会ったことがないんで、考察が足りないかもしれないけど
DIコンテナって、上手く使えば便利なのは分かるんだけど、
publicメソッドの一つも足すことができないし、拡張性が落ちる気がするんだよね。
上の例みたいに、インターフェースと実装を1:1にすればできるけど、
その状況って単に、DIコンテナ使いたいからインターフェースと実装を分離してる感じになっちゃってるし、きもい。
作って終わりならいいけど、拡張をしていく可能性を残すなら、
そう簡単に導入できるものじゃない気がするんだよなぁ。
DBfluteだのJBossだのJava界隈はまともに動かなかったりやる事増やしたりするゴミばっかだな DIってsetter使えば要らないよね?
AOP目的で使ってる人いるみたいだけど、ならsetter+AOPで良くてDI不要じゃん DIすることとDIコンテナを使うことは区別するべきだと思う。
「setter使えば」が何を意味しているのかイマイチ判然としないけれども、setter使って
サービス等の実装オブジェクトをセットするという意味ならそれは他でもないDIだと思う。
DI自体はDIコンテナの使用の有無に関わらず有用な設計パターンの一つだと思うよ。
あとはブートストラップに実装のsetを列挙するかそれともDIコンテナ使うかの、注入作業
の実装方法の違いに過ぎないと思う。
注入するものとされるものが増えてきて、autowireなど規約による自動注入の類を使い
始めるとDIコンテナも便利だと思う。 DIでインジェクションするクラスってさ
基本的にシングルトンになると思ってるんだけど
あってる? >>463
何で?親インスタンス1に対して子インスタンス一つ出来るよね? たいていのDIの実装が、シングルトンをデフォルトにしているっていうだけの話ではなくて?
インスタンス管理がHTTPコンテキストのものだと、シングルトンに見えて実際はDynamic Proxyが
インジェクションされていて、本当の処理はHTTPコンテキストに格納された個々のインスタンスへ
デリゲートされている、なんてものもあるし。 jmockit使えるようになってからは、主だったビジネスロジック部分でのDIはなくてもいいんじゃないかという結論に辿り着いた。
もちろん全部不要って意味じゃないけど、自前でnewすることは怖いことじゃない。
なんていうか、今後を考えてもまず必要のないことが明確にわかるような、
意味のないDIの使い方をしているプロジェクト、多すぎると思う。 普通はデータベース・ファイルIO・外部システム連携部やAPI等をインターフェースにして
単体テスト時はモック、動作時にはDIで実装クラス注入というパターンだな
勘違いした人が全てのクラスに対してインターフェースを用意してDIとかやり始めると、
複雑度が跳ね上がって困ったことになる やっぱり使える場所ってかなり少ないはずなんだよな
その辺はマルチスレッドを使うときのパターンに近似していると思う
DIコンテナの開発元や布教者がむやみにあちこち使わせるような
悪質なチュートリアルや宣伝をしているのが原因ではないだろうか 使える場所は限られるが、ありがちなWebアプリだと、
手続き的に何度も書かなきゃいけないとこはだいたいカバーできるから、
普及してるんだと思われる。
勿論、何でもかんでもDIでというのはおかしいが。 >>463
インジェクションするインスタンスのライフサイクルを外部から設定できるのもDIの特徴の一つだよ。
考えられるライフサイクルは、以下とかかな
シングルトン
DIするごとにインスタンス生成
同スレッド中で同インスタンス
Webアプリケーションの場合、セッションやリクエストもあるね。 >>469
難易度って意味だと、
自動テストって何ですか、単体テストは画面から動かしました!
ってなのが蔓延ってて、
○○機能サービスってクラスに
viewの状態から、SQLIDを含んだ発行メソッドや、ユーティリティ以外の全メソッドが乗ってる
そんな現場だと、例外なく全てである
って言い切っちゃった方がすんなり行きそう
それが新しいルールだってことにして どこの部分をポリモる必要があるかちゃんと線引きしておかないと、DI導入してもただうっとうしいだけになるんだよな。 仕様がふわふわしてる時には自衛の為にDIしたほうがいい サッカーブッシュ日本代表日程ぷあたん(しゅっちょうまいくろ教育長交代)春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ24チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン(販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート Unityでdecoratorパターンしたい場合はどういう風に設定を書けばいいんでしょうか
例えばコードで書くとこんな感じです
var co = new UnityContainer();
co.RegisterType<ILogger, Logger>();
co.RegisterType<IFoo>(new InjectionFactory(
c => new LoggingFoo(new Foo(), c.Resolve<ILogger>()
));
これをコードではなく設定ファイルで定義したいです 39 仕様書無しさん 2016/07/08(金) 23:11:07.46
Oracle、Java EEから手を引く可能性も
http://s.news.mynavi.jp/news/2016/07/04/261/ そもそもClass定義自体がファクトリのはず
なのに何故、いちいちフレームワークの助けが必要なのか。
DIは今後の言語で言語仕様自体に組み込まれ
消えていくだろう 汎化が過剰だからフレームワークの助けが必要になるんじゃないかと
コードを自動生成したほうがマシな気がする 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
6IEJF ■ このスレッドは過去ログ倉庫に格納されています