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 to understand, which classes should go into which packages – (package cohesion – ) and how these packages should relate with one another – (package coupling). Package principles also includes software package metrics, which help to quantify the dependency structure, giving different and/or more precise insights into the overall structure of 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. Classes that are unrelated to the purpose of the package should not be included. A package constructed as a family of reusable classes tends to be most useful and reusable.

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 to decide which classes belong in which package.
When depending on a package, one want to make sure that the classes are inseparable and interdependent, which is also handy when culling classes that do not belong into the package.

3. Common-closure principle (CCP)

CCP states, that the package should not have more than one reason to change. If changes were to happen in an application dependent on a number of packages, ideally one only want changes to occur in one package, rather than in a number of them.
This helps to determine classes that are likely to change and package them together for the same reasons. If the classes are tightly coupled, they belong to 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 the package design needs to support change as well. The SDP states that any packages one 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 unstable 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. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.