Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
[Scala]implicit parameterを使ったDI - Qiita
ScalaでDIを行う方法はいろいろありますが、最近お気に入りのDIのやりかたの紹介です。 implicit defと、implicit parameterを組み合わせて必要なコンポーネントの受け渡しをコンパイラーに任せてしまいます。 利点 Scalaの標準機能のみで簡単に実装できてライブラリ不要 全てコードで記述できるので、XML地獄や新しいDSLを覚える必要がない 使いたいコンポーネントをコンストラクタに追加するだけで使えて楽 欠点 コンストラクターDIしか出来ない 手順 インジェクションしたいコンポーネントをimplicit defで列挙したクラス(トレイト)を作る コンポーネントを使うクラスで、使いたいコンポーネントをimplicit parameterで定義 コンポーネントを使うクラスを生成する際にコンポーネントを列挙したクラスのフィールドをimportする のが、実装の大まかな
![[Scala]implicit parameterを使ったDI - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/099b28724ab66a267f31abbb0061924322d5f02d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCU2NhbGElNURpbXBsaWNpdCUyMHBhcmFtZXRlciVFMyU4MiU5MiVFNCVCRCVCRiVFMyU4MSVBMyVFMyU4MSU5RkRJJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03YzJhZGRhYjQ4YWMyNWVlZTQ4NDIxNjA2N2RjZmNmYw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwdGFrZXpvdXgyJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz01ZTBmNDJhODRiMjU5ZjA4MTk5MmU5ZTNjZGI0MzM1Mg%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Ddac12325607ae19bbd70d87ba845bb6c)
static問題とDIコンテナ - kanizaのブログ
しばらく前に、GoogleのDIコンテナであるGoogle Guiceを紹介するプレゼンテーションがGoogle Videoで公開された。 はじまって3分ほどのところに、「A Problem」として、Javaでstaticを使うことに対する次のような指摘がある。 Using static references comes with big problems! Tight coupling: depending on implementation, not interface Not polymorphic! Not OO! It's extremely global (no scoping) Leads to "all-or-nothing" testing And it's viral! It gives you "static cling!" そうなんだよねぇー。特に最後がデカい。st
心地良すぎるDependency Injectionライブラリ Guice - nodchipの日記
etc9さんの"心地良すぎるモックライブラリ Mockito"がとても勉強になったので、似たような形式でGuiceの紹介をしてみます。 Dependency Injection きちんと勉強したわけではないので間違っていたらごめんなさい。Dependency Injection (DI)はユニットテストを書きやすくするためのクラスの書き方の一つです。クラスAが内部でクラスBを使うとき、Aの中でBをnewする代わりに、AのコンストラクタやsetterでBのインスタンスを外部から渡せるしておきます。こうしておくとAのユニットテストを書くとき、Bの動作を真似るモックオブジェクトを渡すことで、Bの中身を考えずにAをのテストを書けるようになります。これはAとBの動作を同時に考えてテストを書くよりずっと楽だと思います。依存性注入とかレポジトリパターンとも呼ばれているっぽいです。 GuiceはDIの補助
Originate
Agile Innovation Built for Your Business For the past 15 years the world's most admired companies have looked to Originate to help them innovate with the latest technologies What We Do We’re a US-based agile innovation firm that works with clients to develop their digital product strategies and roadmaps, accelerate development with advanced technologies and best-in-class integrations; we deliver p
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
