八葉の日記

日々、感じたことをまとめる場として利用する

SOLID原則:5つ目 依存関係逆転の原則(DIP:The Dependency Inversion Principle)

〇依存関係逆転の原則(DIP:The Dependency Inversion Principle)
上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである
「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。

構造化分析に従うと、システムをトップダウンで分析していき、主要機能を実現するのに必要なサブ機能を見つけていきます。これをそのままSW設計と実装に適用するとサブ機能の組み合わせで上位ができるため、上位は下位に依存する構成になります。

余談

こうなった時のデメリットとしては、些細な実装の変更が上位のモジュールに伝わってしまうため、すぐ変更が必要になってしまうことです。自分が作っている範囲ならいいのですが、上位と下位モジュールを別組織で作成していたりすると、変更自体が難しくなります。
例えば、下位担当が楽な変更を考えたとしても、上位への影響が大きいとか言われて、下位担当は楽じゃない変更をすることが起こりえます。また、上位からすると下位がちょっと変えてくれればいいのに他の上位モジュールにも影響があるから下位は変更できないとなります。
つまり、最終的に望むのは上位と下位が直接依存しないことになります。

閑話休題

以下の図では、Policy(方針)がMechanism、MechanismがUtilityに依存している。ここまでダイレクトな依存関係だとUtilityを変更することPolicyへ影響することになってしまいます。(そして、余談にかいてあるようなやりとりが発生します。f:id:konboi_kun:20171203140947p:plain)

f:id:konboi_kun:20171203135609p:plain
参考書籍にあった例:認識の甘いレイヤ構造

上位は自信が期待する振る舞いを定義したInterfaceを用意し、下位はInterfaceに沿った実装をする(下位が上位へ依存する)。この結果、上位はInterfaceに、下位はInterfaceに依存する構造のため、Interfaceで決めた範囲の変更では、余談に書いたようなことは起こりません。

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技