開放/閉鎖原則(かいほうへいさげんそく、open/closed principle、OCP)とは、オブジェクト指向プログラミングにおいて、プログラム単位(クラスモジュール関数など)は、

  • 拡張に対して開いていなければならず、 "should be open for extension,"
  • 修正に対して閉じていなければならない。 "but closed for modification."

という設計上の原則である[1]。開放/閉鎖原則に従ったソフトウェアは、既存のソースコードを変更することなく、振る舞いを変更することができる。

この原則は、本番環境で稼働中のソフトウェアにとって特に重要である。稼働中のソフトウェアでは、ソースコードを変更した場合、コードレビューユニットテストなどの品質検査が必要となる。しかし、開放/閉鎖原則に沿ったソフトウェアは、既存のソースコードを変更せずに機能修正や機能追加を行うことができる。そのため、品質検査を再実行する必要がない[2]

この開放/閉鎖の原則は、1988年にバートランド・メイヤーが提唱したものと、1990年代にロバート・マーティンらが提唱したものの二通りがある。どちらも継承サブタイピングによる汎用化機構を用いて、開放と閉鎖のジレンマを解決しようとする動機は同じだが、そのテクニックと実装様式は異なっている。

メイヤーの開放/閉鎖原則(1988年)編集

元々の開放/閉鎖原則は、1988年のバートランド・メイヤー著書『Object Oriented Software Construction』で提唱されている。

  • 拡張できるならば、そのモジュールは開放されていると言える。そのモジュールは、データ構造にフィールドを追加できるはずだし、関数の集合に新しいものを追加できるはずである。
  • 他から安定使用できるならば、そのモジュールは閉鎖されていると言える。そのモジュールはよく定義されていて仕様が安定しているはずである。その際のインターフェース情報隠蔽英語版の意味になる。

新しいフィールド及び関数の追加と、それによるパフォーマンス変化のジレンマの解決策としてメイヤーは、契約による設計の型枠にはめて実装継承を前提にしたクラス継承を提示している。実装継承(implementation inheritance)とは具象メソッド(定義+実装)を引き継ぐための継承を指す。

すなわち初版のクラスで、事前条件と事後条件と不変条件などの契約(クラスの仕様)をきちんと定義しておき、拡張や修正が必要になったら、前回の継承によるクラス改訂を重ねていくというものである。改訂クラスの契約は初版クラスのままなので、他者からは同じ働きになる。同じ契約ならば、新しいクラスに変えるよりも、初版からの継承クラスを用いる方が無難であるとしていた。継承の可能性が大きく信じられていた時代ならではの考察である。

抽象メソッドに当たる延期フィーチャー(deferred feature)だけで構成されるクラスは、上述のインターフェースになる。インターフェースという純粋な契約を用意することで、そのインターフェース型の変数に、環境に合わせた改訂クラスの各版を代入するということも可能になる。これは専らコンパイル時サブタイピングになる。

マーチンの開放/閉鎖原則(1996年)編集

1990年代になると、開放/閉鎖原則は、インターフェースの実行時サブタイピングを重視するように意味が変わっていった。そこではインターフェース型変数への代入インスタンスの実行時決定と、インターフェースの多重継承が登場し、インターフェースの実装内容がポリモーフィックに入れ替えられた。

メイヤーのものとは対照的に、このアプローチでは抽象基底クラスから、抽象メソッド(定義だけ)を継承させる界面継承(interface inheritance)が重視されている。インターフェースの仕様は再利用されるが、そのコード実装は必要とされない。既存のインタフェースは修正に対して閉じており、それを実装する新規のクラスは(少なくとも)そのインタフェースの各メソッドをコード実装しなければならない。

1996年に発表されたロバート・C・マーチン英語版の『The Open-Closed Principle』が、このアプローチの著名な論文の一つである。2001年にクレーグ・ラーマン英語版が、このアプローチを保護的変容(Protected Variations)に関連付けて、デヴィッド・パーナスの情報隠蔽にも言及している[3]

脚注編集

[脚注の使い方]
  1. ^ Meyer, Bertrand (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3 
  2. ^ Martin 1996
  3. ^ Larman, Craig (2001-05). “Protected Variation: The Importance of Being Closed” (PDF). IEEE: 89-91. http://www.craiglarman.com/articles/The%20Importance%20of%20Being%20Closed%20-%20Larman%20-%20IEEE%20Software.pdf. 

参考資料編集

関連項目編集

外部リンク編集