「DI使うとインタフェース地獄に陥るらしいから使いたくない」と言っていたA氏がインタフェースを使わずにDIで幸せになるまで - Qiita

DIはインタフェース定義しなくても十分実用的だし、むしろそっちの方が本質だよ、という話をします。C#や.NETを使っていますが、それに限らず普遍的な内容です。 インタフェースと実装に分けるとか無理。DIなど不要！ 中堅社員のA氏は、**「DIっていちいち実装とインタフェース分けないとダメなんでしょ？。さすがにやってられんわ」**と言って頑なにDIを導入しようとしません。 DIはテスタビリティと併せて語られることが多かった為か、A氏は「注入するクラスは基本的にインタフェース定義しましょう」という記事ばかりを読んでいたのです。 インタフェースと実装を分けるとは、例えば次のような事です。 services.AddScoped<IMessageStore, MessageStore>(); public interface IMessageStore { string GetMessage(str

[kagehiens]

こういうの読むたびにソフトウェア設計の工夫の大半は、一度書いたプログラムの発展改修を如何に安全に行うかという目的のために存在することを再確認した気持ちになる。そこに余り価値を見出せなかった会社は残念。

[tpircs]

老人なので「インタフェース使っちゃったほうがわかりやすくていんじゃね？」って思っちゃったりする。コードのわかりやすさというより、全体の設計が開発メンバーに伝えやすいのがいいんだよね。

[n314]

PHPerならauto wiringねって話になるけど、C#だと生存期間の問題があるのか。JavaならSpringでAutowiredアノテーションがあるみたいね。

[otihateten3510]

それで、インターフェース地獄は解決したの？　／大抵の場合は環境依存なのに、なぜか守護を大きくしてしまうんだよね

[roshi]

コードジャンプで確実に実装に飛んでくれれば、、このケースだとScalaのimplicit parameterでもよさそう。

[saikyo_tongaricorn]

DIチョットツライ

[fa11enprince]

JavaのSpringだと@Beanで頑張る感じかな、そもそもRepositoryがそもそも分かれてるしServiceロジックに処理かいてて@autowiredしてればこんな悩みは発生しない。DIしてる状況で引数が必要になってる時点で…

[lorenz_sys]

"なんでControllerでDBのテーブルに直接アクセスするようなコードを書くんだ" こんな言い方したら最近の若手は辞めちゃうよ。「ごめん。ちゃんと説明してなかったね...」って言い方しないといけないんだよ。昨今の上司は。

[indication]

アセンブリスキャンしてどこからともなくインスタンス取ってくるのは好きだけど、周りから理解を得れない。特定のライブラリと依存関係にあるとき、本体から切り離せるんだけど、そんなユースケースはないのかな…。

[matarillo]

「（実装を）入れ替えてテストとかしないですよね？」にYesなら、アプリケーションレベルでinterfaceはあんまりいらないよね。メリットを享受しないのならクリーンアーキテクチャなんていらないのよ

[gabari]

デスクトップアプリばかりやってると、DIコンテナあんまり使わないなぁ。多くのケースで、まるっと切り替えるというよりオブジェクトごとに切り替えたりするから、コンストラクタでなんとかしちゃう。

[ghostbass]

Attribute付けたりInterface付けたりでまとめてコンテナに登録とか色々。/個人的にはinterfaceあまり使わないけど実装クラスをnewすることもほぼない

[mak_in]

interfaceへの拒否感からか、DIとDIコンテナの話が混じった状態で色々突っ切ってしまった話に読めた。昔からオブジェクト指向の説明で使われがちの動物-犬猫のようなケースも、継承よりもinterface使った方がいい場面は多い