TypeScriptの関数でDIパターン - id:anatooのブログ
Node.js+TypeScriptでバックエンドを書いてると、DIパターンを使いたい場面が結構ある。 いわゆるDIと言うとコンストラクタインジェクションなどクラスありきの方法が思い浮かぶけれども、実際には関数でもDIパターンを書くことができる。単純に関数のパラメータに依存を受け取ればよい。 // 依存を表現する型 interface Deps { appService: AppServiceInterface; } // DIパターンを記述する関数 function DoSomething({appService}: Deps, params: any) { ... } 依存を注入する場合には、引数を部分適用するbind()メソッドを使う。 // 依存を注入 const doSomething = DoSomething.bind(null, { appService: new MyAp
DI って何でするのかわからない人向けに頑張って説明してみる「本来の意味」 - Qiita
DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる を、単体テストにフォーカスしたら単体テストが本来の目的では無い的なコメントが散見されました。 確かに DI コンテナは元々は SOLID 原則の D に該当する依存性逆転の原則 (Dependency inversion principle) の「具体ではなく、抽象に依存しなければならない」に大きく関係するものになります。 Wikipedia から引用します。 ソフトウエアモジュールを疎結合に保つための特定の形式を指す用語。 この原則に従うとソフトウェアの振る舞いを定義する上位レベルのモジュールから 下位レベルモジュールへの従来の依存関係は逆転し、結果として下位レベルモジュールの 実装の詳細から上位レベルモジュールを独立に保つことができるようになる。 例えば以下のように上位レベルのモジュール（Present
DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる - Qiita
追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる（と私は思ってる）Dependency Injection（DI）について、何故使ってるのか？というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
TypeScript用のDIライブラリを公開しました - エムスリーテックブログ
エンジニアリンググループの冨岡です。 TypeScript向けのDIライブラリを公開したので紹介します。 github.com モチベーション Clean Architecture等の設計手法を使ってコードを書いていると、抽象に依存することが多くなってきます。 class CreateUserAccount { constructor(private userAccountRepository: UserAccountRepository) {} } const forProduction = new CreateUserAccount( new PostgreSQLUserAccountRepository( buildPostgreSQLConfig(process.env) ) ) const forTest = new CreateUserAccount(new InMemoryU
Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
DIコンテナのインジェクション方法の使い分けについて - 日々常々
DIコンテナを使う時にどのインジェクションを使うかって話です。 たぶん誰かがどこかで同じようなことを書いているだろうけれど、気にせず書くよ。 「他の誰かが書いている」なんてのを書かない理由にしてると何も書けなくなるし。 コンテナ DIコンテナのこと。 コンテナ管理 インスタンスのライフサイクルをコンテナが管理していること。雑に言えば、使う側で new しないってこと。 インジェクション Dependency Injectionのこと。 Short Answer コンストラクタインジェクションを使いましょう。使い分けなくていいです。 3種類のインジェクション インジェクションには3種類ありますね。他あっても知らない。 フィールドインジェクション セッターインジェクション コンストラクタインジェクション フィールドインジェクション 一番よく見るかな。 class Hoge { @Inject
ソフトウェア開発におけるデザイン視点の変化 - arclamp
2015/11/14（土）に開催されたJavaOne2015報告会で話をしてきました。資料は以下。 この資料を作る中で気づいたというか、思ったことは、この20年でソフトウェア開発におけるデザインの視点が変化しているな、ということです。 ユニットテストとDIコンテナが変えたもの ユニットテストは衝撃的なものでした（はい、僕も@t_wadaの薫陶を受けたのです）。 ユニットテストを端的に説明するなら「自分で書いたコードを、自分のコードで確認する」ということですが、いわゆる「テスト」というよりは「実装技法」であると考えたほうがよいと思っています。 （それはTDDの事だとか、UATとしてのテストコードは別の意味があるとか、そういう話を含めたとしても、僕はユニットテストを実装技法だと理解しています。話がややこしいですが、「単体テスト」はテストでしょうね） もちろん、DIコンテナも大きな変化でした。「
全力で ES Decorator使ってみた - Qiita
Proposalはここ wycats/javascript-decorators stage: 1 なのでまだまだ仕様変わる可能性あり。 typescriptやbabelでつかいたい場合は次のようなコンパイラオプションが必要 デコレータの振る舞い クラスデコレータは Class Functionをとって Class Function を返す関数 クラスの関数デコレータは instance とname と descriptor を引数に descriptorを返す関数 引数を取るデコレータは、関数を返す関数として実装する(部分適用っぽい感じ) クラスに所属しない関数へのデコレータはbabel/typescriptともに未実装？ 使ってみた感想 元の振る舞いを変えずに参照透過を維持するような関数が見通しが良い 用途は以下が考えられる DI Logging Memoize Mixin アノテーシ
Angular 叩きが流行っているようなので一言言っておくか - ボクココ
元ネタはここ。 Angularそっちのけで、Vue.jsについて所感 まぁタイトルからして釣りっぽい雰囲気はあるけど、そこは気にせず。 覚え切れそうな分量のAPI Angularだって最低限覚えなきゃいけないのはたかが知れてる。全部覚えようとしなくてもいいのはどのフレームワークだってそうだ。徐々に覚えていけばいいだけ。 プロパティによる宣言っぽさ たくさん書かないといけない、というようなことを書いているけれども、それはAngular がDIを推奨した構造にしているからであって、そのおかげでコードに一貫性が出るし依存関係が一瞬でわかる。テストも書きやすい。 その辺Vueは開発者に委ねられている。複雑なロジックや大規模なものになればなるほどカオスになっていくだろう。もちろんそれも開発者の腕次第ではあるが。 後半からはもはや宣伝だなw Angular の Directive に相当するだけの話だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita
Angular2で階層的DIを使う - Qiita