Package cohesion is a way of composing packages that makes them reusable and easily maintainable. There are three package cohesion principles, reuse-release equivalence, package common reuse and common closure.
Let's look at the reuse-release equivalence principle.
The granule of reuse is the granule of release
However, I prefer the longer definition of:
All classes in a package must be reusable, and all packages must be released via bug tracking, version control and other forms of release.
A good example of this is the
io package in Java. It's a package that is easily usable in complex input/output situations. All classes in the
io package depend on either default types or types included in itself.
For example, we would only include classes from the
io package if we used
An example of a package breaking the REP, is if the package needs other packages to be used. Take the example below:
Exploring the files menu, we can see that the the Player package is dependent on the Armor and Weapon packages, limiting its reusability. The Armor and Weapon packages are more reusable since it does't depend on other packages. Like the Math package, a reusable package should be useable in a different project. If the Player package was exported to a different project, it wouldn't be usable since the Armor and Weapon packages are not defined.
We can fix this by combining the classes into one GameObjects package.
The reuse-release equivalence principle is great for ensuring that packages can be used across multiple projects. One major benefit of this principle is a single package can be used across multiple versions of a project since all changes are inclusive.
One thing we didn't talk about is releasing a package. That largely depends on the developers as there are many different bug tracking, version control, documentation tools, support tools, etc. that are available and it's largely based on preference. The gist of the idea, is, as packages are created and made reusable they should be released to the wider project and/or public.