DI・DIコンテナ、ちゃんと理解出来てる・・？ - Qiita
意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか？ DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の１つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか？ 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの１つです。 たまに
Minimal Cake Pattern のお作法 - Qiita
追記 (2020-12-27) より基礎的な説明を Minimal Cake Pattern 再考 にまとめました。Minimal Cake Pattern という言葉を初めて聞く人は、こちらの記事を先に読むことをおすすめします。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 で紹介されている Minimal Cake Pattern をもう少し詳しく解説します。 Minimal Cake Pattern それ自体は自明なものですが、いくつかの規約に従わないと混乱を招きます。以下の事柄を覚えておくと良いでしょう。 MixIn に extends はいらない trait UsesSomething { def something: Something } trait MixInSomething ext
Play 2.4 と Dependency Injection - tototoshi の日記
Play 2.3 が出たばっかで 2.4 の話をします。 前置き: Scala での DI Scala では DI についてのベストプラクティスと言える方法はなく、まだ意見が分かれている状態です。大きく割ると DI コンテナなどを使った動的な DI と、cake pattern, implicit parameter, macro, reader monad などを利用した静的な DI の 2 パターンです。 動的な DI と静的な DI にはそれぞれメリットとデメリットがあります。動的な DI のメリットは Java のわりと優秀な DI コンテナ (Guice とか) が使えて比較的取っ付きやすいこと、デメリットは型安全ではないところ。静的な DI のメリットは型安全、デメリットは trait だの macro だの implicit parameter だの、コンパイル時間が伸びる要
Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
DIについてあれこれ - tototoshi の日記
Dependency Injectionとはコンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである ってwikipedia先生が言ってました。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita を読んでいろいろ考えたので、なんで今さらって感じのことを書きます。 ScalaでDIというとDIコンテナとかCake PatternとかReader Monadとかって話になっちゃうんですが、これらはいかにかっこよくDIするかの話であって、別にこういった道具やパターンを使わなくてもDIは可能という話です。 Constructor Injection 簡単な例で考えます。今ここにUserRepositoryにべったり依存し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita