Open closed principle
m (Reverted edits by Ebybymic (Talk); changed back to last version by Joey Scarr) |
|||
| (7 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
The '''Open closed principle''' states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" as [http://www.objectmentor.com/resources/articles/ocp.pdf Dr. Bertrand Meyer] said. That means | The '''Open closed principle''' states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" as [http://www.objectmentor.com/resources/articles/ocp.pdf Dr. Bertrand Meyer] said. That means | ||
| − | code | + | code should be designed in such a way that it allows extension without having to edit code that already exists. |
The idea was that once completed, the implementation of a class could only be modified to correct errors. So if you want to add new or changed features/functionalities, you would need to create a different class. That class could reuse coding from the original class through inheritance. The derived subclass might or might not have the same interface as the original class. | The idea was that once completed, the implementation of a class could only be modified to correct errors. So if you want to add new or changed features/functionalities, you would need to create a different class. That class could reuse coding from the original class through inheritance. The derived subclass might or might not have the same interface as the original class. | ||
| Line 6: | Line 6: | ||
Another take: To leave a module open for extension but closed for modification, it should be possible to add new functionality by adding new code, but never have to modify existing code. This is achieved by adding new derived classes. | Another take: To leave a module open for extension but closed for modification, it should be possible to add new functionality by adding new code, but never have to modify existing code. This is achieved by adding new derived classes. | ||
| − | No program can be completely closed under all circumstances, instead there is a strategic approach applied by the developer to allow the code to be easily extended in the directions that it is expected to grow in | + | No program can be completely closed under all circumstances, instead there is a strategic approach applied by the developer to allow the code to be easily extended in the directions that it is expected to grow in (See the [[Refactoring and design|Refactoring and design]] page as well as [[Do the simplest thing that could possibly work]]). This is the origin of many of the metrics and principles now used in object oriented design. Some of the key devices used to support the open closed principle are: |
* [[Abstraction]] | * [[Abstraction]] | ||
| Line 15: | Line 15: | ||
There are varying opinions on the danger of using these concepts. Abstraction is a good technique for encapsulating design and removing dependence of one module on another. The benefit of this is the increased ease of extension for new functionality. Public variables within a class open your class to modification from the outside, this means that your class can never be fully closed. It also means that your class can be subjected to the whims of another misbehaving class. For similar reasons Global variables are considered bad. Any class that relies on global variables can never be independent of any other code that uses the same global variables. | There are varying opinions on the danger of using these concepts. Abstraction is a good technique for encapsulating design and removing dependence of one module on another. The benefit of this is the increased ease of extension for new functionality. Public variables within a class open your class to modification from the outside, this means that your class can never be fully closed. It also means that your class can be subjected to the whims of another misbehaving class. For similar reasons Global variables are considered bad. Any class that relies on global variables can never be independent of any other code that uses the same global variables. | ||
| − | This also prevents you from introducing new bugs in | + | This also prevents you from introducing new bugs in existing code. |
== See also == | == See also == | ||
* [[Robert Cecil Martin 1996a]] | * [[Robert Cecil Martin 1996a]] | ||
| + | * [[Software reuse]] | ||
| + | * [[Common closure principle]] | ||
| + | * [[Common reuse principle]] | ||
| + | |||
| + | [[Category:Bob Martin's principles]] | ||
Latest revision as of 03:22, 25 November 2010
The Open closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" as Dr. Bertrand Meyer said. That means code should be designed in such a way that it allows extension without having to edit code that already exists.
The idea was that once completed, the implementation of a class could only be modified to correct errors. So if you want to add new or changed features/functionalities, you would need to create a different class. That class could reuse coding from the original class through inheritance. The derived subclass might or might not have the same interface as the original class.
Another take: To leave a module open for extension but closed for modification, it should be possible to add new functionality by adding new code, but never have to modify existing code. This is achieved by adding new derived classes.
No program can be completely closed under all circumstances, instead there is a strategic approach applied by the developer to allow the code to be easily extended in the directions that it is expected to grow in (See the Refactoring and design page as well as Do the simplest thing that could possibly work). This is the origin of many of the metrics and principles now used in object oriented design. Some of the key devices used to support the open closed principle are:
- Abstraction
- Make all Member Variables Private
- No Global Variables
- Run Time Type Identification is dangerous.
There are varying opinions on the danger of using these concepts. Abstraction is a good technique for encapsulating design and removing dependence of one module on another. The benefit of this is the increased ease of extension for new functionality. Public variables within a class open your class to modification from the outside, this means that your class can never be fully closed. It also means that your class can be subjected to the whims of another misbehaving class. For similar reasons Global variables are considered bad. Any class that relies on global variables can never be independent of any other code that uses the same global variables.
This also prevents you from introducing new bugs in existing code.
