「DI使うとインタフェース地獄に陥るらしいから使いたくない」と言っていたA氏がインタフェースを使わずにDIで幸せになるまで - Qiita
「DI使うとインタフェース地獄に陥るらしいから使いたくない」と言っていたA氏がインタフェースを使わずにDIで幸せになるまでC#DIDependencyInjection依存性の注入 DIはインタフェース定義しなくても十分実用的だし、むしろそっちの方が本質だよ、という話をします。C#や.NETを使っていますが、それに限らず普遍的な内容です。 インタフェースと実装に分けるとか無理。DIなど不要！ 中堅社員のA氏は、「DIっていちいち実装とインタフェース分けないとダメなんでしょ？。さすがにやってられんわ」と言って頑なにDIを導入しようとしません。 DIはテスタビリティと併せて語られることが多かった為か、A氏は「注入するクラスは基本的にインタフェース定義しましょう」という記事ばかりを読んでいたのです。 インタフェースと実装を分けるとは、例えば次のような事です。 services.AddScoped
DI・DIコンテナ、ちゃんと理解出来てる・・？ - Qiita
意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか？ DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の１つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか？ 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの１つです。 たまに
実践Dependency Injection
PHPカンファレンス2012 実践Dependency Injectionスライド
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
