Open closed principle
m (adding two more 'see also' links) |
JaninaVoigt (Talk | contribs) m |
||
| 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. | ||
Revision as of 22:27, 30 July 2009
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. (Read the Refactoring and design page. Also 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 an existing code.
