Package principles

In computer programming, package principles are a way of organizing classes in larger systems to make them more organized and manageable. They help us understand which classes should go into which packages — called package cohesion — and how these packages should relate with one another — called package coupling. Package principles also includes software package metrics, which help us quantify the dependency structure we design, thereby giving us different or more precise insights into the overall structure of our classes and packages.

Overview

Principles of package cohesion

1. Reuse-release equivalence principle (REP)

REP essentially means that the package must be created with reusable classes — “Either all of the classes inside the package are reusable, or none of them are”. The classes must also be of the same family. We don’t want to include classes that are unrelated to the purpose of the package. If we construct a package as a family of reusable classes, we can more closely guarantee a focused, reusable package.

2. Common-reuse principle (CRP)

The CRP states that classes that tend to be reused together belong in the same package together. It is a way of helping us decide which classes belong in which package.
We also want to keep in mind that when we depend on a package, we want to make sure that the classes are inseparable, and interdependent, which is also handy when culling classes that don’t belong.

3. Common-closure principle (CCP)

CCP states that the package should not have more than one reason to change. If change were to happen in an application dependent on a number of packages, ideally we only want changes to occur in one package, rather than in a number of them.
This helps us determine classes that are likely to change and package them together for the same reasons. If the classes are tightly coupled, put them in the same package.

Principles of package coupling

1. Acyclic dependencies principle (ADP)

In a development cycle with multiple developers, cooperation and integration needs to happen in small incremental releases. The ADP states that there can be no cycles in the dependency structure, and that when an incremental release is made, the other developers can adopt and build upon it.

2. Stable-dependencies principle (SDP)

Designs, by nature of the environments they are used in or by, are changing. So we need to design our packages to be able to change as well. The SDP states that any packages we want to be volatile should not be depended on by a package that is difficult to change.

3. Stable-abstractions principle (SAP)

The SAP says that a stable package should also be abstract so that its stability does not prevent it from being extended. It also states that an instable package should be concrete since its instability allows the concrete code within it to be easily changed.

See also

References

This article is issued from Wikipedia - version of the Thursday, February 18, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.