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
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 –
Three principles of Package Coupling are –
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.”
http://labs.cs.utt.ro/labs/acs/html/lectures/6/lecture6.pdf - gives a brief explanation about Reuse/Release Equivalency principle. It describes how packages of reusable components have to be grouped to enable maximum reuse.
http://iface.wordpress.com/2006/04/04/reuserelease-equivalency-principle/ - is a blog that explains the REP principle and also provides the reason why not individual reusable classes are being released.
www.mppmu.mpg.de/english/kluth_ss02_oodp.pdf - slide 55 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”
http://labs.cs.utt.ro/labs/acs/html/lectures/6/lecture6.pdf - 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.
http://iface.wordpress.com/2006/04/08/common-closure-principle/ -
www.parlezuml.com/metrics/OO%20Design%20Principles%20&%20Metrics.pdf – 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.
http://iface.wordpress.com/2006/04/05/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.
http://labs.cs.utt.ro/labs/acs/html/lectures/6/lecture6.pdf - 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.
http://staff.cs.utu.fi/kurssit/Programming-III/PackageDesing.pdf - 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.
http://javacentral.compuware.com/pasta/concepts/layering.html - optimal advisor 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 dependencied 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 shoul d 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 – 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://parlezuml.com/blog/?postid=361