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.
Object Oriented Programming (OOP) is a methodology for modeling and designing software systems which encompasses the basic concepts of encapsulation, abstraction, inheritance and polymorphism. This methodology is guided by a set of principles, called the Design Principles. These principles show the right direction of designing and helps in avoiding costly mistakes at the designing stage. The design principles are not important only from a software design point of view, but also from a business because design principles enable flexible designs, which can evolve with the business requirements with minimum effort, time and cost.
There are Class Design principles and Package Design principles, here we will discuss on the Package Design principles alone.
Bob Martin
Robert C. Martin has been a software professional since 1970. In the last 35 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, and C++ Programming. He has published dozens of articles in various trade journals. Today, He is one of the software industry's leading authorities on Agile software development and is a regular speaker at international conferences and trade shows. He is a former editor of the C++ Report.
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 communicates 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 therefore 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
Let's 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. The library developed as a package has many functions and only some of them may be used of each person.
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 emphasizes those classes which 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) re-comments 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 localize 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 de-normalization 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 behavior 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 particular 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 package, it better have only those classes related to matrices and not trigonometric functions.
Acyclic Dependencies Principle (ADP)
The Acyclic Dependency Principle (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 maintainable, 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 cyclic 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 un-maintainable.
Stable Dependencies Principle (SDP)
The Stable Dependencies Principle (SDP) states that
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.
According to this principle, a package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, packages can reliably depend on this stable package. This principle can go to an atomic level of classes and say that classes should depend on more stable classes only. This is a direct derivation of the Dependency Inversion Principle (DIP). Why do we need to look at stability point of view? We need to do this as we define a dependency chain, which can help in localising the changes and create a system which is still flexible but not prone to erroneous changes.
Quiet often, a single change in a class and hence a package triggers a chain-reaction causing changes to more than expected places. This is a classic case leading to overflow of estimates and sometimes leading to failure. By applying SDP the typical chain reaction can be avoided, as the more stable packages are lower in the chain. It is important to identify stable packages and unstable packages. The packages that are expected to changes should be designed to change and acknowledged accordingly. This information can give a better handle on the changes to be done and the corresponding estimates.
Example
An interface called Logger will be more stable than classes FileLogger or DBLogger
Stable Abstraction Principle (SAP)
Stable Abstraction Principle (SAP) states that
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.
Stable Abstractions Principle (SAP) can be considered to be a corollary of the Stable Dependencies Principle (SDP), which said that packages should depend only on more stable packages. Applying Dependency Inversion Principle (DIP), flexibility is built into a design by introducing abstract classes. Concrete classes depend on the abstract classes for re-usability and extensibility. An abstract class tends to be more stable, as it does not depend on concrete classes. The concrete classes, which are instable, and are expected to change, depend on the concrete classes. This ultimately means that dependencies in packages are in the direction of abstraction.
Example
Let's try to explain this by discussion. An abstraction is used to contain high-level design, which is used to hold the concept. Objects of concepts don’t exist in nature, and rightly so abstract classes cannot be instantiated. The concrete classes which depend on the abstractions are instantiated and can be modeled after the real world objects. As time goes by, the real world objects change more frequently than the concept itself. This leads us to a corollary that abstraction brings stability.
References
Books
- Designing Object-Oriented C++ Applications using the Booch Method
- Agile Software Development: Principles, Patterns and Practices
Links
- Principles of Object-oriented design
- Presentation on package design principles
- Principles of Software Development