Tags: package design
Package Design:
Group classes together in a same package that relate to the same abstraction. All User related classes should go in the user package.
Group classes together in a same package that are likely to change together. If a class imports lots of classes from another package, maybe it should be in that package - minimising imports is a useful heuristic in deciding where a class should go.
Minimise the number of 'visible' classes in a package. In the way that an object will expose an interface (public methods) but have many more internal ones (private methods), a package should have only one or a few classes that a client will ever have to interact with. Make the constructors / factory methods on the internal only classes 'protected' or 'private' to document this.
Do not allow cycles in the package dependency graph. For example A -> B -> C -> A is not allowed.
To break these cycles we can add a new package, to give us A -> D, A -> B -> C -> D
A better solution is to use the DependencyInversionPrinciple and extract an interface.
Depend in the direction of stability. Depend upon packages whose Package Instability (see MetricsPage) is lower than yours.
Last published: Tuesday 18th May 2010
<<Previous Next>>