CSC/ECE 517 Fall 2007/wiki3 8 as

OO Package Design Principles

O-O design guru Bob Martin has developed a set of design principles that relate to packages (one level above the class-oriented strategies we consider in this course). Report on the

Reuse/Release Equivalency principle,

Common Closure principle,

Common Reuse principle,

Acyclic Dependencies principle,

Stable Dependencies principle, and

Stable Abstraction principle

Find the best descriptions and examples of each that you can find on the Web.

Packages

Robert C. Martin describes the term “Package” as “a logical grouping of declarations that can be imported into other programs”. Since packages serve as a container for a group of classes, those classes need to be partitioned based on some criteria and then allocate the partitioned classes to their appropriate packages. The relationship between those packages identifies a high level organization of the application. Martin has put together many design principles for guiding the creation, interrelationship and use of packages.
Three principles of Package Cohesion are –

Reuse/Release Equivalency principle

Common Closure principle

Common Reuse principle

Three principles of Package Coupling are –

Acyclic Dependencies principle

Stable Dependencies principle

Stable Abstraction principle

Package Cohesion Principles

Reuse/Release Equivalency principle

When developers reuse a class, it is a disadvantage when they have to recompile the code everytime there are changes done to the class. There should be a process of controlled release to enable maximum class reuse. The principle as stated by R.Martin in his article Granularity -

   “The Granule of Reuse is the granule of Release.
   Only components that are released through a tracking system can be effectively reused. 
   This granule is the package.”

Principles of Object-Oriented Design- gives a brief explanation about Reuse/Release Equivalency principle on page 15. It describes how packages of reusable components have to be grouped to enable maximum reuse.
Reuse/Release Equivalency Principle- is a blog that explains the REP principle and also provides the reason why not individual reusable classes are being released.
OO Design Principles- page 54 of this document gives the requirements of a reusable software and provides summary of this principle.

Common Closure Principle

This principle ensures that classes within a released component share a common closure, i.e. if a class in a released package requires a change then all the classes in that package needs a change. The principle as stated by R. Martin in his article Granularity –

   “The classes in a package should be closed together against the same kinds of changes. 
   A change that affects a package affects all the classes in that package”

Principles of Object-Oriented Design - gives a brief explanation about the common closure principle on page 19. It also compares reusability and maintainability by specifying when to use REP, CCP and CRP.
Common Closure Principle -
OO Design Principles & Metrics – defines the principle with a basic diagram as an example.

Common Reuse Principle

The principle is stated by R.Martin in his article Granularity as –

   “The classes in a package are reused together. 
   If you reuse one of the classes in a package, you reuse them all”

This principle helps to decide how the classes can be put into a package. If the classes are being reused together, then they should be put into a package. In his article, Martin gives a simple example of a container class and its associated iterators which can be put into a package since the classes are tightly coupled to each other and they have to be placed in a single package.

Common Reuse Principle - is a link to a blog that describes the necessity of the common reuse principle. It also states the principle and gives an example about a package of matrix calculations.
Principles of Object-Oriented Design - gives bulleted hint about the principle. It also gives the Façade pattern as an example of a common reuse in practice.

Package Cohesion Principles

Acyclic Dependencies principle

This principle ensures that the packages are not indirectly dependent on it. Martin’s solution to this problem of dependency is to partition the development environment into releasable packages. The dependency problem can be solved by drawing the dependency graph structure of the packages by using the packages as nodes and directed dependency releationships as edges. Such a structure is called the Directed Graph. The principle in Martin’s article Granularity states the Acyclic Dependencies Principle as-

   "The Dependency Structure between packages must be a directed acyclic graph(DAG). 
   That is, there must be no cycles in the dependency structure”.

The article gives the effect of a cycle in a package dependency graph and explains how to break that cycle.

Principles of Package Design - describes how to apply ADP and break any cycles that appear in the dependency graph. Although there is not much information, it gives quick points on the principle.
OptimalAdvisor - is a static code analysis and refactoring tool and It can be used to indicate problems and solutions. The tool finds problems in dependency structure and suggests solutions to fix them by using the acyclic dependencies principle.

Stable Dependencies principle

In his article Stability Martin gives detailed explanation and examples about stability and dependency. He stresses on the stability property of classes, as stables classes are both Independent and Responsible. The principle is states as –

   “The dependencies between packages in a design should be in the direction of the stability of the packages. 
   A package should only depend upon packages that are more stable that it is.”

The article also explains about Stability Metrics which is used to measure the stability of the package. It also mentions that not all packages can be maximally stable, since it would render the system unchangeable.
[www.parlezuml.com/metrics/OO%20Design%20Principles%20&%20Metrics.pdf OO Design Principles & Metrics]– gives reasoning why stable dependencies principle should be applied on the package. It also explains the stability metrics with an example.

Stable Abstractions principle

This principle states that a stable package should be abstract too, so that it gives an opportunity to be extended. The article Stability by Martin gives the best description and example of the principle.
It is stated as –     “Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.”

It also gives a way to measure the abstractness of a package. The mathematical explanation helps to decide if a package is abstract or concrete. The “main sequence” explained in the derivation is the position where a package is neither ‘too abstract’ nor ‘too instable’. It also provides a link http://www.oma.com which provides a bash script that scans C++ directory structure and calculate all the metrics.
http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ - gives a brief description of stable abstractions principle. The blog speaks about the relationship between stability and abstractness. It refers to Martin’s mathematical explanation of measurement of abstractness in a package.
http://staff.cs.utu.fi/kurssit/Programming-III/PackageDesing.pdf - gives a brief hint of the stable abstraction principle. It also describes the relationship between stability and abstractness.
http://labs.cs.utt.ro/labs/acs/html/lectures/6/lecture6.pdf - defines the principle and describes how to measure the abstractness of a package.

Conclusion

One of the powerful tools of OOD is to manage complex projects using packages and their interdependencies. Reusable, robust and maintainable software can be easily created if the above principles are followed.

References

1. http://www.codeproject.com/gen/design/nfOORules.asp
2. http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF
3. Patterns and Advanced Principles of OOD. - book
4. http://www.cmcrossroads.com/articles/agile-cm-environments/principles-of-agile-version-control:-from-ood-to-tbd.html