👌

SOLID原則:オープン・クローズドの原則(Clean Architecture 達人に学ぶソフトウェアの構造と設計)

2025/01/23に公開

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

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

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

この原則の目的

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

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

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

オープン・クローズドの原則(OCP)に最も適しているのは、Interactorである。DatabaseControllerPresenterViewを変更しても、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原則を意識した設計をしていきたい。

Discussion