開放/閉鎖原則

開放/閉鎖原則(OCP：The Open-Closed Principle)

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

モジュール(クラス)は拡張に対して開いており、修正に対して閉じていなければならない。

かのBertrand Meyer先生による、ありがたいお言葉。有名な「OCP」です。
あえて俺流で別の言い方をするなら、「拡張できるけど、修正不要の原則」です。

拡張に対して開いているとは？

モジュール(クラス)が「拡張に対して開いている(Open)」というのは、
アプリケーションで随時発生する拡張要求に対して、
モジュールの振る舞い（メソッド）を随時、追加拡張することが可能である状態を指します。

修正に対して閉じているとは？

アプリケーションで随時発生する拡張要求に対して、
モジュール(クラス)の振る舞いを拡張したとしても、修正を要しない状態ことの言います。

機能を拡張するのに修正を要しないとは、一体どういうことか？

拡張の方法には大きく分けて２つあります。
１つはコードを書き換える方法、もう１つはコードを追加する方法です。

つまり、「修正に対して閉じている(Close)」とは、
既存のコードを変更することなく、コードを追加することだけで機能を拡張できれば、
その修正は他のクラスに影響を及ぼさないという考えを礎とした指針です。
これを満たす手段の１つとして、振る舞いと実装を分離する方法*1がある。

まとめ

つまり、開放/閉鎖原則(OCP)とは作成したクラスやシステムがどれだけ安全に、
他のクラスに影響を及ぼさず、機能拡張ができるかを示す指針です。

OCPは仕様変更に対してロバストである事を謳った原理です。
クラス仕様とOCPは常に対で考えられるべきです。
すなわち、オブジェクト指向による設計行う場合、クラス内でどこが変更されやすいかを
あらかじめ予測しておくことが重要なポイントとなることを意味します。

テレビゲームソフトなどのマルチプラットホームによる開発では、
クラスの設計により、プラットフォームの違いを吸収する必要があります。
つまり拡張に開いていることに対して、大変シビアに考えなければならなくなります。
各クラスが有する多くの振る舞いは、ことごとくインターフェイスとして抽出する必要がでてくる。
描画処理に関して言えば、DirectXですらプラットフォーム依存するので、
すべてラッパインターフェイスをかぶせて綿密なクラスを設計することになるだろう。
そういう変更されやすい箇所は俗に「ホットスポット」と呼ばれています。
ホットスポットを見極める力。オブジェクト指向を扱う人には必須のスキルなのかもしれない。

*1:関心の分離（Separation Of Concerns）