uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかReactとかFregeとかJavaとか -

「DI技術の有用性」と「DIコンテナの有用性」は異なる

DIコンテナを利用することは、当然DI技術を使用することでもあるのですが、両者の有用性の意味には差があります。

DIフレームワークは、DI技術の適用のベストプラクティスを、容易に利用可能な形で利用者に提供してくれます。たとえば、JDBCのDataSourceの切り替えやロガーなどは既定義されたものから設定で選択すればすぐ使えるというわけです。

そのような利用法の場合、DI技術を使用しているといいう意識が薄れることになります。DIコンテナ利用者(DI上での開発者)からみると「ある設定をすればある動作をする」と認識すればよいからです。

DIについて以下の二通りの使いかたがあります。

  • (1)それらを理解し、開発対象システムの設計時に、適用可能・適用して有用なパターンを探し出し、実際にDIでの設計方針を編み出し、実装し、動作させる
  • (2)フレームワーク側が用意してくれた、あるいは誰かが編み出してくれた、DIのベストプラクティスパターン(DataSourcdeのインジェクション、Mockなど)に従い、それを使う

この両者は、得られる利点は当然同種のものではあるのですが、質的あるいはスキルレベル的にも結構違います。この2つを大雑把に言うと(1)が「DI技術の利点」であり、(2)が「DIコンテナ利用の利点」といえるのではないでしょうか。もちろん、両者は背反なものではなくて、重なりのあるものではありますが。

「DIの有用性をよく認識・体感できない・説明しにくい」という場合、上の(1)(2)をごっちゃにして考えてしまっている可能性があります。DIフレームワークは、DI技術の有用性を、それとはわかりにくいように・意識せずにすむ様に作り上げられているわけです。(2)のレベルでの利点をまずは十全に得たうえで、次の段階として(1)を習得し、熟達する、というような二段階で考えるべきでしょう。

また、DIに限らず、一般に、AOPオブジェクト指向技術や、デザインパターン、といった要素技術についても同じ構図が見て取ることができます。つまりそれらそれぞれについて

  • 「AOPの適用場面を見つけ出して設計し実装する人・既定義のアドバイザーを利用する人」
  • 「クラスライブラリを作る人・使う人」
  • デザインパターンを駆使してフレームワークを作る人・残されたコールバックを埋める形で業務固有ロジックを記述する人」

というような、2つの面があるのです。