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 and application examples.

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