Principles of Package Architecture

Below are three principles known as the Package Cohesion Principles, that attempt to help the software architect.

The Release Reuse Equivalency Principle (REP)1

The granule of reuse is the granule of release.

A reusable element, be it a component, a class, or a cluster of classes, cannot be

reused unless it is managed by a release system of some kind. Users will be unwilling

to use the element if they are forced to upgrade every time the author changes it.

Thus. even though the author has released a new version of his reusable element, he

must be willing to support and maintain older versions while his customers go about

the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element

unless the author promises to keep track of version numbers, and maintain old

versions for awhile.

Therefore, one criterion for grouping classes into packages is reuse. Since packages

are the unit of release, they are also the unit of reuse. Therefore architects would do

well to group reusable classes together into packages.

The Common Closure Principle (CCP)2

Classes that change together, belong together.

A large development project is subdivided into a large network of interelated packages.

The work to manage, test, and release those packages is non-trivial. The more

packages that change in any given release, the greater the work to rebuild, test, and

deploy the release. Therefore we would like to minimze the number of packages that

are changed in any given release cycle of the product.

To achieve this, we group together classes that we think will change together. This

requires a certain amount of precience since we must anticipate the kinds of changes

that are likely. Still, when we group classes that change together into the same packages,

then the package impact from release to release will be minimzed.

The Common Reuse Principle (CRP)3

Classes that aren’t reused together should not be grouped together.

A dependency upon a package is a dependency upon everything within the package.

When a package changes, and its release number is bumped, all clients of that pack-age must verify that they work with the new package -- even if nothing they used

within the package actually changed.

We frequently experience this when our OS vendor releases a new operating system.

We have to upgrade sooner or later, because the vendor will not support the old version

forever. So even though nothing of interest to us changed in the new release, we

must go through the effort of upgrading and revalidating.

The same can happen with packages if classes that are not used together are grouped

together. Changes to a class that I don’t care about will still force a new release of the

package, and still cause me to go through the effort of upgrading and revalidating.

The Package Coupling Principles.

The next three packages govern the interlationships between packages. Applications

tend to be large networks of interlated packages. The rules that govern these interrelationship

are some of the most important rules in object oriented architecture.

The Acyclic Dependencies Principle (ADP)1

The dependencies betwen packages must not form cycles.

Since packages are the granule of release, they also tend to focus manpower. Engineers

will typically work inside a single package rather than working on dozens. This

tedency is amplified by the package cohesion principles, since they tend to group together those classes that are related. Thus, engineers will find that their changes are

directed into just a few package. Once those changes are made, they can release those

packages to the rest of the project.

The Stable Dependencies Principle (SDP)1

Depend in the direction of stability.

Though this seems to be an obvious principle, there is quite a bit we can say about it.

Stability is not always well understood.

The Stable Abstractions Principle (SAP)1

Stable packages should be abstract packages.