システム開発時のよくあるパターンとして、機能を追加しようとすると既存のコードの複数箇所に修正をしなければならない、ということはよくあります。
修正をすることで別の箇所でエラーが発生して……、という頭の痛い展開を防ぎたいものです。

では、どのようにすれば良いでしょうか。

OCPのクラス設計方針とは

いきなり英語が出てきましたが、Open / Closed Princpleの略となります。
日本語にすると解放/閉鎖原則となります。そのままですが、よけいに意味がわからなくなったかもしれません。
意味するところは、記事タイトルのように、

拡張に対して開いている（Open）
修正に対して閉じている（Closed）

上記方針を守った、クラスの設計方針のことです。
仕様変更に対して、機能追加は簡単にできるように、かつ既存のコードを変更しないでいいようにすることを指します。
巨大なシステムであるほど、既存のコードに対する修正はリスクが高まり、機能追加時に修正が不要になることは大きなメリットがあります。

OCPをどのように使うのか？

どのような方針で設計をすれば良いのでしょうか。
『アジャイルソフトウェア開発の奥義』の著者ロバート・C・マーチンがあげる例によれば、呼び出すクラスに依存させるのではなく、インタフェースや抽象クラスに依存させることを指針とすべきだ、というものです。
直接クラスを使用すると依存箇所ができてしまうため、インタフェースを実装したクラスを使用することで、インタフェースを実装したクラスであれば差し替え可能にすることで、変更を防ぐというものです。
差し替え可能にすることで柔軟性を保つという発想は、依存性の注入（Dependency Injection）とも重なります（ここでは割愛）。

まとめ

複雑なシステムを構成するには、機能追加に柔軟な設計になっていることが必要となります。
『アジャイルソフトウェア開発の奥義』には他にも有用な考え方が多数掲載されており、筆者も勉強中となります。

ところで、上記内容を解決するための根本的な発想はもう１つあります。
コードを書かないでいいようにすることです。
コードがなければバグもない、そんなの当たり前と考えるかもしれませんが、クライアントと相談するなどすれば意外とコードを書かないでも解決できてしまったりすることがあるのです。
OCPに沿ったコードそのものが本当に必要なのか、書かないでいい方法はないか、ここから問うようにしましょう。

●Wantedly掲載情報(エンジニア想いの環境でJavaやPHPにチャレンジしたいエンジニア募集！)

株式会社CPR ソリューション事業部はこちら