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 (REP) 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.

Common Reuse Principle (CRP)

The Common Reuse Principle (CRP) states that,

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

This principle stresses on the importance of a package (a set of cohesive classes) to be used for releasing reusable software, and the importance of releasing software that can be tracked, so that the users get a guarantee of interface and behaviour from the author.However, it is very important to decide which classes should be bound together by a package. Improper selection of classes can create unwanted dependencies and complicate usage of that package. Common Reuse Principle (CRP) lays down the foundations to determine which classes should be packaged together.

According to this principle, only cohesive classes should be packaged together. The packaging of classes and the cohesiveness should be defined from the user’s perspective. If a user uses a package, all the classes in that package should be reusable in the same context. A rule that can be a derivative of this is that all the classes related to a functionality should be packaged together. For example,

As specified by Reuse/Release Equivalency Principle (REP), even if one or two classes are being used, the granularity to be considered is the entire package. This dependency means that with every revision or release of that package, the software has to be tested and revalidated, irrespective of whether the modified class is being used or not. Hence, only those classes should be packaged together which will be reused together.

Example

For a matrix calculations pakage, it better have only those classes related to matrices and not trigonometric functions.

Acyclic Dependencies Principle (ADP)

The Acyclic Dependency Priniciple (ADP) states that

  The dependency structure between packages must be a Directed Acyclic Graph (DAG).

This principle is important from a deployment perspective. A package apart from being reusable and maintanable, should also be deployable. The package design should have defined dependencies so that it is deployment-friendly.

DAG implies that in the package dependency traversal, there should be no path which includes the same package more than once. DAG leads to a clear dependency structure, which can instantly identify the packages that can get affected if a certain package is modified. Cyclic dependencies usually happen when multiple developers work on the same package, on the same module or on the same class. These cyclick dependencies can be broken. One of the methods is to use Dependency Inversion Principle (DIP).The dependency graphs lead directly to the map for building the packages and the entire application. Considering this at the early stages of package design saves lot of time and effort.

Example

The simplest cyclic dependency means that a package A depends on package B, which again depends on package A. Not only does this lead to wrong class dependencies, but also makes deployment a difficult and unmaintainable.