SOLID原則とは？SOLIDのO、オープンクローズドの原則をわかりやすく解説、そこから考えられる良いエンジニアとは？

今回はSOLID原則のO、オープンクローズドの原則についてまとめていきます。

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)

オープンクローズドの原則とは

「ソフトウェアの構成要素は拡張に対しては開いていて、修正に対しては閉じていなければならない」

機能拡張を行うたびに既存のコードの色々な部分を書き換えなければならないようなソフトは良いソフトとは言えません。そのことを簡潔に言い表しているのがこのOCPです。

拡張と修正

まず、拡張と修正という言葉のイメージを確認します。例えば、機能A・Bで成立している既存のシステムがあったとします。そこに新たに機能Cを追加する際に、

• 既存のA・Bとは別にCを追加する機能追加方法を「拡張」
• 既存機能を修正して例えばA+C機能とするような機能追加方法を「修正」

といいます。

拡張に対してオープンとは

例えば、メイン関数の中から複数のロジックを呼び出すような構造で、呼び出される機能同士が独立している構造は拡張に対してオープンであると言えます。

こういった構造なら、新規関数を作って予め用意された呼び出しポイントからその関数を呼び出すだけで、ソフトの機能を拡張できます。極端な言い方をすれば、既存機能の中身を知らずとも新しく追加したい機能を追加することもできるでしょう。

拡張によって機能追加できる構造を持つと、機能追加時に他の既存コードへの影響検討を最低限にできるというメリットがあります。なお、拡張性の高い構造が用意されていても開発者がそれに気が付かずに修正による機能追加をしてしまうと意味はなく、構造だけではなく開発者の視点も重要になります。

修正に対してクローズドとは

拡張と修正の図で示したような既存機能AをA+Cとするような変更をした場合、既存機能同士の依存関係に基づいて影響を検討して実装する必要があります。

言い換えれば、Cという機能を追加したいだけなのに既存機能AとBの両方の仕様を詳細に把握しなければならないということです。

この例のように、既存機能が２つだけという簡単なケースであればそれほど難しくないかもしれませんが、現実的な規模の開発となるとその苦労は避けたいものでしょう。

修正による機能追加は、拡張による機能追加と比べて、既存コードへの影響を入念に確認する必要があるというデメリットを持っています。

まとめ

オープン・クローズドの原則を意識することで、機能拡張性の高いソフトウェアを実現できるでしょう。

アーキテクトがOCPを十分に理解して、拡張に対してオープンな構造を構築することも重要ですが、機能追加を手掛ける開発者が、拡張に対してオープンで修正に対してクローズドなマインドを持つことも同じくらい重要です。良い開発者とは、単に動くものを作るのではなく、これからのことを考えられる人のことなのでしょう。

参考書籍

Clean Architecture(著：Robert C.Martin,2018)