Common closure principle
m (Reverted edits by Ebybymic (Talk); changed back to last version by Joey Scarr) |
|||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
The Common closure principle is concerned with program maintainability. It states: | The Common closure principle is concerned with program maintainability. It states: | ||
:''The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package.'' [http://ifacethoughts.net/2006/04/08/common-closure-principle/ ifacethoughts.net] | :''The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package.'' [http://ifacethoughts.net/2006/04/08/common-closure-principle/ ifacethoughts.net] | ||
| − | + | <Big>"</Big>More important than reusability is maintainability<Big>"</Big>, | |
| − | + | <Big>"</Big>The CCP is an attempt to gather together in one place all the classes that are likely to change for the same reasons<Big>"</Big> | |
This is closely related to the [[Open closed principle]]. | This is closely related to the [[Open closed principle]]. | ||
[[Robert Cecil Martin 1996b]] | [[Robert Cecil Martin 1996b]] | ||
Latest revision as of 03:11, 25 November 2010
The Common closure principle is concerned with program maintainability. It states:
- The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package. ifacethoughts.net
"More important than reusability is maintainability",
"The CCP is an attempt to gather together in one place all the classes that are likely to change for the same reasons" This is closely related to the Open closed principle. Robert Cecil Martin 1996b
Although most design principles advocate loose-coupling between classes, sometimes it is unavoidable. This may be because of a consequence of the design, or a deliberate action such as performance tuning. In these cases, these classes should be packaged together, so a change only affects the classes in that package. This makes updating the system easier, as only the new package needs to be distributed. The Law of Demeter is a useful way to find out which classes know other's structure, and thus should probably be in the same package.
