Common Closure Principle

Definitions

Common Closure Principle (CCP) - “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.

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

Reuse-Release Equivalence Principle (REP) – “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] In many cases we would like the make packages as light weight as possible to allow code to be reused. If users don't typically use all the code in the package then we have a trade off of wasting space if we make the package too big. But if we make too many packages to ensure that they are lightweight we can run into the problem of inter-package coupling. This can cause the need for many packages to be updated if new functionality or code fixes are required. This is the key concept that the CCP is trying to prevent from occuring.

We can clarify this concept further 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 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. We also need to remember that every package and class will require its own level of testing. This should further clarify the need for the CCP as the amount of revalidation required is directly proportional to the number of packages involved. Also this principle will help 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.

XML Example

Consider that a newer standard of XML was released and you are responsible for implementing the java package which handles XML files. The key features of the new package must support all the old XML standards but also the newly updated standard, so how do you go about accomplishing this goal? Typically a newer standard of XML will require additional methods which are easy to accommodate by extending the current package. The problem arises when an old function needs to be updated to support the new standard, since the Open Closed Principle states to not change previous code.

The first option is to either create function calls by XML standard number. This allows us to virtually extend the design without violating the OCP. This requires the programmers to statically compile their code for a specific standard of XML and thus is not the best idea. A more viable option is to create a totally separate package which handles the newer standard of XML. This allows programmers to choose which version of the XML package they wish to support in their program. This can complicate programmer's code if they wish to support multiple versions as they must now dynamically load a package at runtime depending on the XML standard the user wishes to use. Multiple package versions can make others code easier to maintain since they can choose to use a stable version with known functionality or choose the newer and more versatile version. Thus the programmers can easily make requirements on the required package version they want their program to use for stability reasons. But this comes at a drawback that the program must now be released in multiple versions corresponding to the supported package version.

The main problem with creating multiple packages is that it violates the Common Closure Principle. Imagine that a very rare bug was found in some of the more stable portions of the XML code. This stable code where the bug was located could be in multiple packages and even all the way back to the original release. If you currently have launched 10 packages supporting different XML versions then you must first edit all 10 versions and then revalidate all the code. This can be a daunting task and is the key objective that the CCP is trying to avoid.

The best way to implement the newer version of XML is to alter the original by extending the support of each method. This of course violates the OCP principle by not allowing the original version of the code to remain closed but provides for easier future maintenance of the code if a bug was discovered. The advantage of doing this is that user’s code will not have to be recompiled to support the newer version of the code, as the method calls and package name will all remain exactly the same. The limitation here is that the new version may be unstable and the programmers must be aware of this fact to prevent from using something that might be unstable compared to previous versions. Thus the burden is on the consumers to ensure they have the proper version of the package that they wish to use. If we look at most modern day programming releases this is the most common solution. Programmers today will release beta and stable versions of code to allow users the option to choose when deciding what trade off they are willing accept for different availability of features.