Open closed principle

From CSSEMediaWiki
Revision as of 09:56, 13 September 2008 by Jason Clutterbuck (Talk | contribs)
Jump to: navigation, search

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 sould 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.

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. 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:

There are varying opinions on the danger of using these concepts. Abstraction is a good technique for encapsulating design and removing dependance of one module on another. The benefit of this is the increased ease of extension for new functionality. Public variables within a class open you class to modification from the outside, this means that you 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.

See also

Personal tools