CSC/ECE 517 Fall 2009/wiki3 3 jn

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 is 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 has been extended to entire package granularity.

The Common Closure Principle is closely associated with the Open Closed Principle. [Granularity] The CCP is targeted towards more accurately defining a specific requirement for the closure portion of OCP. The OCP states that classes should be closed for modification but open for extension. The 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 previous package release.

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.

!!Need Image that shows the two designs of the system. IE One with multiple edits and the other with only one edit!!

Now imagine that the work on your project has been divided up among smaller teams by the specific packages you have implemented. Which would you rather have, a single team able to handle the entire code alteration ensuring that they can intracommunicate and 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 package and 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 and prevent the users from defining multiple imports?

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. Maintainability and User Convenience are both very important considerations and a good balance for both need to be discovered when packaging code.

Links

[1] The Open-Closed Principle

[2] Principles of Package Cohesion

[3] Object Oriented Design Principles

[4] Java Design: Objects, UML, and Process

[5] Granularity

[6] Common Closure Principle (ifacethoughts.net)

[7] Object Orient Principles (Washington State University)

[8] Principles of Package Design (Colorado School of Mines)