こんにちは。粘着系エンジニアのbamboo-houseです。
今回は、読書中の技術書「Clean Architecture 達人に学ぶソフトウェアの構造と設計」の中でオープン・クローズドの原則が出てきたので、この法則についてまとめてみました！
クラス、アーキテクチャの設計をしている人はぜひご参考ください！

オープン・クローズドの原則

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

この原則の目的

ソフトウェアの振る舞いを、既存の成果物を変更せず拡張できるようにする

例

最も重要なこととして押さえるべきは「あるコンポーネントは他のコンポーネントに依存すればするほど、変更しにくくなる」ということだ。
つまり、コンポーネントAがコンポーネントBの変更から保護されるべきならば、コンポーネントBからコンポーネントAに依存すべきである。

ここでは、Presenterを変更した時に、Controllerを変更する必要をなくしている。Viewsを変更した時に、Presenterを変更する必要をなくしている。他のすべてを変更した時に、Intferactorを変更する必要をなくしている。（矢印が依存の方向を示している）

オープン・クローズドの原則（OCP）に最も適しているのは、Interactorである。Database、Controller、Presenter、Viewを変更しても、Interactorには何の影響も及ぼさない。

なぜInteractorがそんなにも特権的な位置付けになるのだろう？それは、ビジネスルールを含んでいるからだ。Interactorは、アプリケーションの最上位レベルの方針を含んでいる。その他のコンポーネントは、周辺にある関心ごとを処理している。Interactorは、その中心となる関心ごとを処理している。

これにより、Interactorの振る舞いを、既存の成果物を変更せずに拡張できる。
つまり、Interactorの変更容易性の向上につながる。

コードでは下のように実現する。DI（依存性注入）を行うことで依存の方向を作っている。

  const interactor = new Interactor()
  const controller = new Controller(interactor)
  const presenter = new Presenter(controller)
  const view = new View(presenter)

この章を読んでの感想

私自身、SOLID原則は今まで何回も学習を繰り返してきた。今回の章を読んでSOLID原則の解像度がさらに上がった。今まではコードレベル、クラスレベル観点のSOLID原則の学習が多かった。しかし、本書ではコンポーネントレベル、アーキテクチャレベルの説明が中心なので、より抽象的に理解できた。また、具体的な事例を想像しながら読めたことで、抽象的なことを容易に理解できた。抽象的に理解できたことで、今後はアーキテクチャレベルにおいてSOLID原則を意識した設計をしていきたい。