開放/閉鎖原則(かいほうへいさげんそく、open/closed principle、OCP)とは、オブジェクト指向プログラミングの設計への提言である。 ソフトウェア要素(クラス、モジュール、関数など)は、拡張に対しては開いており、修正に対しては閉じているべきである。software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. この原則に従っていれば、ソースコードの修正をせずとも、各要素の振る舞いを拡張することが可能になるとしている。 この開放/閉鎖の原則は、1988年にバートランド・メイヤーが提唱したものと、1996年頃にらが提唱したものの二通りがある。どちらも継承やポリモーフィズムによる汎用化を用いて、開放/閉鎖のジレンマ解決を図っているが、その目標と技術と結果は異なっている。 この原則は、本番環境で稼働中のソフトウェアにとって特に重要である。稼働中のソフトウェアでは、ソースコードを変更した場合、コードレビューやユニットテストなどの品質検査が必要となる。しかし、開放/閉鎖原則に沿ったソフトウェアは、既存のソースコードを変更せずに機能修正や機能追加を行うことができる。そのため、品質検査を再実行する必要がない。

Property Value
dbo:abstract
  • 開放/閉鎖原則(かいほうへいさげんそく、open/closed principle、OCP)とは、オブジェクト指向プログラミングの設計への提言である。 ソフトウェア要素(クラス、モジュール、関数など)は、拡張に対しては開いており、修正に対しては閉じているべきである。software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. この原則に従っていれば、ソースコードの修正をせずとも、各要素の振る舞いを拡張することが可能になるとしている。 この開放/閉鎖の原則は、1988年にバートランド・メイヤーが提唱したものと、1996年頃にらが提唱したものの二通りがある。どちらも継承やポリモーフィズムによる汎用化を用いて、開放/閉鎖のジレンマ解決を図っているが、その目標と技術と結果は異なっている。 この原則は、本番環境で稼働中のソフトウェアにとって特に重要である。稼働中のソフトウェアでは、ソースコードを変更した場合、コードレビューやユニットテストなどの品質検査が必要となる。しかし、開放/閉鎖原則に沿ったソフトウェアは、既存のソースコードを変更せずに機能修正や機能追加を行うことができる。そのため、品質検査を再実行する必要がない。 (ja)
  • 開放/閉鎖原則(かいほうへいさげんそく、open/closed principle、OCP)とは、オブジェクト指向プログラミングの設計への提言である。 ソフトウェア要素(クラス、モジュール、関数など)は、拡張に対しては開いており、修正に対しては閉じているべきである。software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. この原則に従っていれば、ソースコードの修正をせずとも、各要素の振る舞いを拡張することが可能になるとしている。 この開放/閉鎖の原則は、1988年にバートランド・メイヤーが提唱したものと、1996年頃にらが提唱したものの二通りがある。どちらも継承やポリモーフィズムによる汎用化を用いて、開放/閉鎖のジレンマ解決を図っているが、その目標と技術と結果は異なっている。 この原則は、本番環境で稼働中のソフトウェアにとって特に重要である。稼働中のソフトウェアでは、ソースコードを変更した場合、コードレビューやユニットテストなどの品質検査が必要となる。しかし、開放/閉鎖原則に沿ったソフトウェアは、既存のソースコードを変更せずに機能修正や機能追加を行うことができる。そのため、品質検査を再実行する必要がない。 (ja)
dbo:wikiPageExternalLink
dbo:wikiPageID
  • 884871 (xsd:integer)
dbo:wikiPageLength
  • 4481 (xsd:nonNegativeInteger)
dbo:wikiPageRevisionID
  • 91230450 (xsd:integer)
dbo:wikiPageWikiLink
prop-ja:wikiPageUsesTemplate
dct:subject
rdfs:comment
  • 開放/閉鎖原則(かいほうへいさげんそく、open/closed principle、OCP)とは、オブジェクト指向プログラミングの設計への提言である。 ソフトウェア要素(クラス、モジュール、関数など)は、拡張に対しては開いており、修正に対しては閉じているべきである。software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. この原則に従っていれば、ソースコードの修正をせずとも、各要素の振る舞いを拡張することが可能になるとしている。 この開放/閉鎖の原則は、1988年にバートランド・メイヤーが提唱したものと、1996年頃にらが提唱したものの二通りがある。どちらも継承やポリモーフィズムによる汎用化を用いて、開放/閉鎖のジレンマ解決を図っているが、その目標と技術と結果は異なっている。 この原則は、本番環境で稼働中のソフトウェアにとって特に重要である。稼働中のソフトウェアでは、ソースコードを変更した場合、コードレビューやユニットテストなどの品質検査が必要となる。しかし、開放/閉鎖原則に沿ったソフトウェアは、既存のソースコードを変更せずに機能修正や機能追加を行うことができる。そのため、品質検査を再実行する必要がない。 (ja)
  • 開放/閉鎖原則(かいほうへいさげんそく、open/closed principle、OCP)とは、オブジェクト指向プログラミングの設計への提言である。 ソフトウェア要素(クラス、モジュール、関数など)は、拡張に対しては開いており、修正に対しては閉じているべきである。software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. この原則に従っていれば、ソースコードの修正をせずとも、各要素の振る舞いを拡張することが可能になるとしている。 この開放/閉鎖の原則は、1988年にバートランド・メイヤーが提唱したものと、1996年頃にらが提唱したものの二通りがある。どちらも継承やポリモーフィズムによる汎用化を用いて、開放/閉鎖のジレンマ解決を図っているが、その目標と技術と結果は異なっている。 この原則は、本番環境で稼働中のソフトウェアにとって特に重要である。稼働中のソフトウェアでは、ソースコードを変更した場合、コードレビューやユニットテストなどの品質検査が必要となる。しかし、開放/閉鎖原則に沿ったソフトウェアは、既存のソースコードを変更せずに機能修正や機能追加を行うことができる。そのため、品質検査を再実行する必要がない。 (ja)
rdfs:label
  • 開放/閉鎖原則 (ja)
  • 開放/閉鎖原則 (ja)
owl:sameAs
prov:wasDerivedFrom
foaf:isPrimaryTopicOf
is dbo:wikiPageRedirects of
is dbo:wikiPageWikiLink of
is owl:sameAs of
is foaf:primaryTopic of