CSC/ECE 517 Fall 2009/wiki3 3 cp

Common Closure Principle

In simple words the Common Closure Principle refers to classes that change topether, belong together, this is a very simple definition taken from the book Java Design: Objects, UML and Process written by Kirk Knoernschild.

A more explained definition of Common Closure Principle, given by Robert Martin, is

      THE CLASSES IN A PACKAGE SHOULD BE CLOSED TOGETHER AGAINTS THE SAME 
      KINDS OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL THE 
      CLASSES WITHIN THAT PACKAGE. 
      

See Granularity PDF Article written by Robert Martin for more details

In other words, what affects one, affects all broader and detailed explanations are given in this wikiwork.

Introduction and Objective

There are several web pages that explain in few words what is Common Closure Principle, but they fall short by just giving definitions and very few examples.

Therefore the objective of the wiki work is to dedicate a deeper investigation on this topic with examples.

A deep definition of Common Closure Principle CCP

CCP is another package design principle which tries to look at maintainability rather than usability. The principle advises on which classes should be packaged together from a change and distribution point of view

Even though most of the class design principles advocate loose coupling between classes, so that they can change without affecting the other, dependencies between classes cannot be avoided. CCP tries to look at classes that are dependent on each other from a code change perspective. Even though Open-Closed Principle (OCP) recomments full closure to code change, it is not always possible. Sometimes some of the class design principles are violated consciously to improve performance, just like denormalization in databases. However this violation should be a conscious decision and the product should be ready for changes because of it.

To enable easy distribution/update/release and maintainability, it is advisable to localise the changes to a package. Only the modified package can then be released, making the update easier. Even if the changes cannot be restricted to a single package, minimal packages should be required to be changed. To get an idea of the code change dependencies, we can take guidance from Law Of Demeter (LOD) principle, which tries to point out classes which know each other’s structures.

One issue is when dependencies between packages in a design should be in the direction of stability of the packages, in other words a package should only depend upon packages that are more stable than it is.

Some volatility is necessary if the design is to be maintained. This is achieved by using the Common Closure Principle, in this way we design packages to be volatile and we expect them to change. Any package that we expect to be volatile should not be depended upon by a package that is difficult to change.

Some things we don’t want to change. For example architectural decisions should be stable and not at all volatile. Therefore classes that encapsulate the high level design should be stable.

Regarding Granularity

More important than reusability, is maintainability.

If the code in an application must change, where would you like those changes to occur: all in one package, or distributed through many packages? It seems clear that we would rather see the changes focused into a single package rather than have to dig through a whole bunch of packages and change them all. That way we need only release the one changed package. Other packages that don’t depend upon the changed package do not need to be revalidated or rereleased.

The CCP is an attempt to gather together in one place all the classes that are likely to change for the same reasons. If two classes are so tightly bound, either physically or conceptually, such that they almost always change together; then they belong in the same package. This minimizes the workload related to releasing, revalidating, and redistributing the software.

This principles is closely associated with the Open Closed Principle (OCP). For it is “closure” in the OCP sense of the word that this principle is dealing with. The OCP states that classes should be closed for modification but open for extension. As we learned in the article that described the OCP, 100% closure is not attainable. Closure must be strategic. We design our systems such that the are closed to the most likely kinds of changes that we foresee.

The CCP amplifies this by grouping together classes which cannot be closed against certain types of changes into the same packages. Thus, when a change in requirements comes along; that change has a good chance of being restricted to a minimal number of packages.

What are the advantages and disadvantages?

Goal: limit the dispersion of changes among released packages u changes must affect the smallest number of released packages

Classes within a package must be cohesive

Given a particular kind of change, either all classes or no class in a component needs to be modified.

CCP makes life easier for maintainer

External Links

Bob Martin's

Appendix

Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification.

Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference.

Dependency Inversion Principle: Details should depend upon abstractions instead of abstractions depend upon details.

Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface.

Reuse/Release Equivalency Principle: They are almost the same, the only components that are released through a tracking system can be effectively reused.

Common Closure Principle: Classes that change together, belong together.

Common Reuse Principle: Classes that are not reused together should not be grouped together.

Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph.

The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.

The Stable Abstractions Principle: A completely stable category should consist of nothing but abstract classes