Principles of Package Design
Agile Software Development is really an incredible book. After reading it, a lot had been talked about the Object-Oriented Principles on this blog .
Today, I’ll be talking about another section of the book, which
introduces principles used to maintain high package cohesion and a
desirable package dependency, known as Principles of Package Design.
Packages are used to organize larger
projects. More than this, they are containers of classes used to manage
the development and distribution on software. Package’s goal is separate
classes in an application according to some criteria. However, classes
often have dependencies on other classes, creating package dependencies
relationships. To help manage this situation, some principles were
created to govern the creation, interrelationship and use of packages.
The three principles in sequence are related to package cohesion, useful in deciding how to partition classes into packages.
The Reuse-Release Equivalence Principle (REP):
the granule of reuse if the granule of release
REP states that anything that we reuse
must also be released and tracked. Reusability is not only the creation.
It comes only after there is a track system in place that offers the
guarantees of support that reusers will need. Since reusability is based
on packages, if some software is going to be reused, then it must be
partitioned in a convenient structure for this purpose, so all classes
in a package become reusable by the same audience.
The Common-Reuse Principle (CRP):
the classes in a package are reused together
CRP helps in deciding which classes
should be placed into a package. This can be determined by reuse
characteristics. Classes that tend to be reused together should be
placed in the same package. Remember: if you reuse one class in a
package, you reuse them all. Although the CRP tells us what classes put
together, it also says what classes do not put in the
same package. If a class depends on another class in a different
package, it depends on the entire package. Every time the used package
is released, the using package must be revalidated and rereleased, even
the change was made in a different class that the using package depends
on. Therefore, CRP also says that classes which are not tightly related
to each other should not be in the same package, so every time I depend
on a package, I depend on every class in that package.
The Common-Closed Principle (CCP): a change that affects a package affects all the classes in that package and no other packages.
This is the same as SRP, but applied for
the packages context. Such as classes should have just one reason to
change, CCP states that packages should not have multiple reasons to
change. It’s preferable that changes occur in just one package rather
than distributed along the whole system.
Now, we are going to take a look at principles related to package relationship and dependency.
The Acyclic-Dependencies Principle (ADP):
allow no cycles in the package-dependency graph.
Package cycles create immediate problems,
and the most obvious one is when you have to release a package
that was modified. In order to release the package, it must be
compatible with all other packages that it depends on. A cycle in your
package-dependency graph makes release harder since you increase the
number of packages that you have to be compatible with. For example,
take the Figure 1 and Figure 2. To release package C in the first
situation we must be compatible with package E and F. However, in the
second case we also must be compatible with package A, B and D. Even
worst, if you want to test package C, we must link and build all other
packages in the system, instead of just two of them.
To break the cycle, two solutions are suggested:
- apply Dependecy-Inversion Principle.
- create a new package between C and A, and move the classes that they both depend on into that new package.
The Stable-Dependencies Principle (SDP):
depend in the direction of stability.
Stability has nothing directly to do with
frequency of change, but to the amount of work required to make the
change. In software, package stability is measured in number of classes
inside this package that depend on classes outside this package and
number of classes outside this package that depend on classes within
this package. Thus, a package is called instable if it is easy to change, in other words, just a few or none packages have dependency relationship with it. A package is called stable if it is hard to change,
or a lot of classes outside this package depend on it. The book
also brings a method to calculate stability metrics, but I’ll not be
such detailed. Just have in mind that a good design contains some
instable package and some stable package. Instable packages are on top
and depend on stable packages at the bottom, just shown below.
The Stable-Abstractions Principle (SAP): a package should be as abstract as it is stable.
This principle states that a stable
package should also be abstract so that its stability does not prevent
it from being extended, and an instable package should be concrete since
its instability allows the concrete code within it to be easily
changed. Thus, stable packages consist of abstract classes and instable
packages of implementations classes.
Conclusion
After some posts of OOP, we already know
how to create a good class design. However, in big systems, classes are
separate into packages which corresponds a very important part of the
system’s release and deploy. So, a new concern is how to divide classes
between packages and maintain the system’s consistency. In this post we
introduced six principles explained in Robert Martin book which help us
in solve a lot of package design problems. You can find a lot of more
information in the book, which I strictly recommend.
See you,
