CSC/ECE 517 Fall 2007/wiki3 8 ss

Topic

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.

Reuse/Release Equivalency principle (REP)

The Reuse/Release Equivalency principle states that

    "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."

According to this, package is to be considered as the unit of distribution of software. When one wants to reuse components, package has to be the concrete unit that should be reused. The term package may also be interpreted as library, domain, functionality or a set of classes bound together.

An interesting argument can be that, why not use classes as the unit of distribution? The reason is that quiet often by design, we end up with more than one class that communicate with each other. If individual classes are released, tracking version and compatibility can become very difficult. Hence, packages which are in the level next to classes, are the granular units of release and therfore reused even if classes can be the units of design.

The tracking system is important because the author owns the responsibility of upgrading the package that is being reused. Changes or enhancements in the package can be triggered by many factors, like new standards, new requirements, bugs or sometimes new methodologies and technologies. The author has to track the changes in the package along with maintaining its source code.

Example

Lets say one wants use a file operations library. The library itself is the unit of distribution and usage (referred to as the package), even if we use only one particular class for reading a file.

Common Closure principle (CCP)

The Common Closure Principle (CCP) states that

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

This principle focuses at maintainability rather than usability. The principle guides on which classes should be packaged together from a change and distribution point of view. Though most of the class design principles advocate loose coupling between classes, so that they can change without affecting the other, dependencies between classes is inevitable. This principle 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. 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.

Example

A good example for application of CCP is a package modeled after a relational database. Class designs might need to be consciously violated during denormalization of the database model for performance improvements. During this time changes to the package affects all classes in that package.