現役車載組込みソフトエンジニアの竹です。
今回はSOLID原則のD、依存関係逆転の原則についてまとめます。
この記事は依存関係逆転の原則の概要を説明するものであり、具体的な実装例については触れない初心者向けの内容となっています。
SOLID原則
- S：単一責任の原則(SRP：Single Responsibility Principle)
- O：オープン・クローズドの原則(OCP：Open-Closed Principle)
- L：リスコフの置換原則(LSP：Liskov Substitution Principle)
- I：インターフェース分離の原則(ISP：Interface Segregation Principle)
- D：依存関係逆転の原則(DIP：Dependency Inversion Principle)
依存関係逆転の原則とは
「具象へ依存するのではなく抽象へ依存せよ」
具象・抽象・依存という言葉の示す内容を説明し、その上で原則を守ることでどういったメリットがあるかを説明します。
具象と抽象
具象とは実体・本体・実物のことであり、何かを指すときそれ自体のことを指す言葉です。
対して、抽象とは実体そのものをある一定の見方をして表現したもの、ある特徴にだけを抽出したものです。
具象への依存
では具象に依存するとはどういうことでしょうか。
例えば以下の条件を全て満たす食材を切る道具を必要とする料理人がいたとします。
- 岐阜県関市で作られた
- 職人Aさんが作った
- 出刃包丁
- 持ち手が木製
- 持ち手は黒色
この料理人は具象に依存しています。
この状況で職人Aさんが引退してしまうと職人Aさんが作ったという条件が満たせなくなり、持ち手が木製のものが廃盤になっても条件が欠けてしまいます。そのような些細なことで、この具象へ依存する料理人は食材を切ることができなくなり、結果として本来の目的のはずの料理もできなくなります。これが具象に依存することの弊害です。
抽象への依存
抽象へ依存する場合の例を挙げてみます。
食材を切れるなら何でもいいよ、という料理人がいたとします。
この人の場合は、食材を切ることができるという抽象にのみ依存しています。
この条件に当てはまる道具は無数にありますし、包丁なら出刃包丁でも穴あき包丁でも、ひょっとしたらアウトドア用のナイフでもOKでしょう。これなら具象に依存した料理人のように、こだわりの包丁を失うことで肝心の料理がでくなくなることはありません。
抽象に依存するメリット
抽象とは、実体そのものではなく、それに対して一定の見方だけを期待するものです。
そのため、実体の姿が多少変わったとしても期待する性質が変わってさえいなければ関係を維持できます。
ソフトウェアは機能拡張が容易で、柔軟な変更が可能という特性があり、アップデートされることでその機能・性能が向上していきます。実際はあり得ませんが包丁の例えで通すなら、食器棚にしまっておいた包丁が自動アップデートされてセラミック製になったり、持ち手が滑りにくい樹脂素材になったりとそんな感じでしょうか。
そうしたことが起こった際、具象に依存する料理人はその包丁を使えなくなります。
ただ切れればOKという抽象へ依存する料理人は何の不自由もなく、勝手に高性能化した包丁を使うことができます。
つまり、後者のような抽象的なことにだけ依存している方がソフトウェアのレベルアップに対して都合が良いのです。
なぜ依存関係“逆転”の原則なのか？
無意識な設計開発では、具象に依存する設計が自然と出来上がります。
システムAを動かすためのソフトウェアであれば、システムAの具象に依存し、システムBを動かすためのソフトウェアならシステムBの具象に依存します。しかし、システムAに依存したソフトウェアはシステムBを動作させることはでず、システムBのソフトウェアもまたしかりです。システムA用のソフトをシステムBに転用できるようにするには、システムAの具象への依存を避けて抽象に依存するようにしておけばソフト自体はシステムBに移しても動作するようにできます。
このように、自然な開発の中ではどうしても具象に依存する設計になるところを、あえて抽象に依存するように設計させましょう、というところから依存関係を逆転させるべき、依存関係逆転の原則となっています。
まとめ
今回は依存関係逆転の原則の概要を例を用いて説明しました。今後、より具体的にどういった実装をすべきなのかなども扱っていけたらと思います。
なお、原則の説明補助として使用した例にある内容は個人の意見を含まず、道具へのこだわりを批判する意図はありません。
参考書籍
コメント