開放/閉鎖原則

出典: フリー百科事典『ウィキペディア(Wikipedia)』
開放閉鎖原則から転送)

開放/閉鎖原則(かいほうへいさげんそく、open/closed principle、OCP)とは、オブジェクト指向プログラミングの設計への提言である。

ソフトウェア要素(クラスモジュール関数など)は、拡張に対しては開いており、修正に対しては閉じているべきである。 software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.[1]

この原則に従っていれば、ソースコードの修正をせずとも、各要素の振る舞いを拡張することが可能になるとしている。

この開放/閉鎖の原則は、1988年にバートランド・メイヤーが提唱したものと、1996年頃にロバート・C・マーチン英語版らが提唱したものの二通りがある。どちらも継承ポリモーフィズムによる汎用化を用いて、開放/閉鎖のジレンマ解決を図っているが、その目標と技術と結果は異なっている。

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

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

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

  • 拡張できるならば、そのモジュールは開放されていると言える。そのモジュールはデータ構造にフィールドを追加できて、関数の集合に新しいものを追加できるはずである。
  • 外部から使用できるならば、そのモジュールは閉鎖されていると言える。そのモジュールはよく仕様定義されていて安定しており、実装は情報隠蔽英語版されている[4]

メイヤーは、親クラスで不変の仕様を定義をして、それを継承する各子孫クラスで実装の修正または拡張を行なっていくべきとした。親クラスの変数には、親クラスまたは各子孫クラスのインスタンスが代入される。クライアントはその親クラス変数を恒久的に使えて、その変数に子孫インスタンスが代入されていても支障をきたさない[5]

メイヤーの原則では、具象メソッド(シグネチャ+コード)の実装継承(implementation inheritance)と、子クラスを追加定義していく深い継承が基本になる。

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

1990年代の開放/閉鎖原則は、インターフェースの実行時サブタイピングを重視するように意味が変わっていった。ロバート・C・マーチン英語版の1996年論文『The Open-Closed Principle』などが、これをアプローチしている。

抽象メソッドだけで構成される不変のインターフェースを定義して、それをコード実装するための兄弟クラスを様々に定義し、ランタイムでインターフェース変数への各兄弟インスタンスの代入と交換を行って、実行時ポリモーフィックするべきとした。

マーチンの原則では、抽象メソッド(シグネチャだけ)の界面継承(interface inheritance)が基本になる。継承関係はインターフェースの実装に留めて、クラスの継承は抑えることが基本になる。

2001年にクレーグ・ラーマン英語版が、このアプローチをGRASP保護的変容(Protected Variations)に関連付けて、デヴィッド・パーナス情報隠蔽英語版にも言及している[6]

出典[編集]

  1. ^ Meyer, Bertrand (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3 
  2. ^ Martin 1996
  3. ^ Robert C. Martin "The Open-Closed Principle", C++ Report, January 1996 Archived August 22, 2006, at the Wayback Machine.
  4. ^ Meyer, Bertrand (1988). Object-oriented software construction. New York: Prentice Hall. p. 23. ISBN 0136290493 
  5. ^ Meyer, Bertrand (1988). Object-oriented software construction. New York: Prentice Hall. p. 229. ISBN 0136290493 
  6. ^ 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. 

参考資料[編集]

関連項目[編集]

外部リンク[編集]