Common Closure Principle

Definitions

CCP (Common Closure Principle) - “The classes in a package should be closed against the same kinds of change; A change that affects a package affects all the classes in that package.” - R. Martin, 1996.

OCP (Open Closed Principle) – "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" – Bertrand Meyer, 1988

REP (Reuse-Release Equivalence) – “The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.” -R. Martin, 1996

What is CCP?

The Common Closure Principle s defined as “The classes in a package should be closed against the same kinds of change; A change that affects a package affects all the classes in that package.” [R. Martin, 1996]. The real concept here is to ensure that all the classes within a single package are cohesive and decoupled from other classes as much as possible. If you remember this is a typical design principle for classes that for this principle has been extended to entire packages.

The Common Closure Principle is closely associated with the Open Closed Principle. The CCP is tightly connected with the closure portion of OCP. The OCP states that classes should be closed for modification but open for extension. [Granularity] They key idea here is that we should be able to add more functionality to our code without altering the existing functionality in any way. This ensures backwards compatibility for older code systems but allows for future improvements if needed. This is directly tied to expected function signatures and expected function output values for any users that have developed on top of a previously used package.

The Common Closure Principle augments the OCP principle by specifying specific closure practices for a specific package. The principle requires that if code must be modified, possibly for a bug or some other critical reason, then all of the required changes to resolve the issue should be limited to a single package. CCP requires that if any two classes are so closely coupled that they will likely need to be edited in unison in the future that they be part of the same class. The need for this principle is exemplified in the next section.

Why do we need to use CCP?

The Common Closure Principle is targeted at maintainability rather than reusability, which many times is much more important. [Principles of Package Design] We can clarify this concept by a simple example.

 Imagine you are a project manager for a large java software project and after the release of the software you have uncovered a critical bug.  This bug pertained to a specific usage case which was not covered in your testing strategy and covers a wide number of classes.

 Now imagine that the work on your project has been divided up among smaller teams by the specific packages you’ve implemented.  Which would you rather have, a single team able to handle the entire code alteration ensuring that they can intracommunicate and insure that all the required changes are cohesive in the classes?   Or would you rather distribute the work and require a large amount of intercommunication between teams to ensure cohesion?

The obvious answer from the example above is to allow a single team to handle the resolution of the problem. This will simplify testing and integration of the next release by preventing separate teams from introducing separate bugs into the code and preventing the need for each of the packages to be revalidated independently. Also this will correlate the resolution of the bug to a single package change which can make it easier to distribute the patch to clients.

Conflicting Principles

The CCP principle can sometimes lead to confusion when also considering the Reuse-Release Equivalence Principle. This principle tells use to combine code into packages based on user convenience and usage patterns. Essentially if classes are typically used in unison then why not package them together?

Many users find it hard to find a balance between obeying both REP and CCP. The trade off here is user convenience and maintainability. Program designers need to be careful to separate new and moderately unstable code from older and highly stable code in packages when considering how to package code for user convenience. Maintainability and User Convenience are both very important and a good balance for both need to be discovered when packaging code.