依存関係逆転の原則とは？

きっかけ

下の記事を読んで，あれ，依存関係逆転の原則って何だっけとなったので，調べたことをメモとして残す．

実は前に自分のブログでも依存関係逆転の原則を扱ったことがあったのだが，ほぼ忘れていた．

ただ，この中ではあまり具体的な部分への深堀はせず，ほぼ実装面しか書いていない．そこで，追加で下の記事を読むことでどういうことかを理解した．

クラスAがクラスBに依存しているという関係に対して，クラスBのインターフェースを用意して，クラスAとクラスBをそのインターフェースに依存させるような形をとることで，依存関係が逆転するということ．クラスAからクラスBへ向いていた矢印が，両方からインターフェースへ向く形に変わる．

言葉だけだと非常に分かりにくいので，上で挙げた記事の図を見てほしい．

下の記事も比較的分かりやすかった．GoFのデザインパターンの1つであるFactoryメソッドについても扱われているので，その使いどころの勉強にもなった．

といっても自分はWebのバックエンドのAPI開発が今後メインになってくるだろうから，それにマッチした例も見てみたい．DBがクラスB的な立ち位置になる？と考えたけど，確か前にXでDBの取り換えはそんなに起こる話ではない，みたいなのを見かけたことがあるので，もっといい例が欲しい．

具体的に例を考えずとも，アーキテクチャのレイヤーを考えればいいのかもしれない．

2重引用させていただく．

書籍「アジャイルソフトウェア開発の奥義」では、このように書かれています。

a.上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。

b.「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。

過去にインターンでちゃんとアーキテクチャを意識して開発されているプロジェクトに関わったことがあるので，なんとなく理解した．ビジネスロジックを定義する側と，ビジネスロジックを使う側を直接依存させずにインターフェースを介する感じか．ほかにもいろいろあるだろうけど，あくまで1例として．

これを読みながら，アーキテクチャ周りをもっと勉強していくことで，こういったSOLID原則についての理解を深められそうだなと感じた．

最近コントリビュートしたOSSもいい例かもしれない．ちゃんとインターフェースを定義して，それに依存する形にしている．

なるほど．OSSコントリビュートがここで生きるか．もっとコントリビュートしていくと設計周りの知識がついていきそう．

依存関係の逆転がどういうことかは分かったけど，そのメリットは何だろう．

一番思いつくのは，クラスBを交換しやすいということかな？

上の記事ではテスト容易性についても触れられていた．具体的な実装ではなくインターフェースに依存しているので，テスト時にモックへ差し替えられるということ．

抽象的なまとめ方をすると，「ソフトウェア開発における拡張性や保守性を高めること」が目的で依存関係の逆転を行っており，それがメリットであるということだな．

ということで，依存関係の逆転についてはある程度理解できたのでヨシ．今後は途中で紹介したOSSへのコントリビュートやアーキテクチャの勉強をする中で，より具体的な用途やメリットを手を動かしながら学んでいきたい．