|
Handling import dependencies between packages is an important aspect of structuring an object model. A package depends
on another if any of its classes have relationships that are navigable to classes in the other package. To express such
dependencies you use the import dependency from one package to the package on which it depends.
Dependencies between packages are expressed by import dependencies.
You evolve import dependencies in the following manner:
-
Before you start working with the object model, make outlines of dependencies for use as guidelines during the
work.
-
When the model is completed, use it to show the dependencies actually there. This entails updating the import
dependencies in the object model.
-
If you divided the model into packages early on, use the import dependencies to show where dependencies are
allowed.
-
How packages depend on one another affects a system's tolerance to change. An object model will be easier to change
if you:
-
Reference a minimum number of contained classes from outside each package. If you reference many classes, the
package may have too many different responsibilities and should be divided into two.
-
Make each package depend on few other packages.
-
Test each package separately. This means that you should be able to test a package by simulating the package on
which it depends. You should not require other packages to be completely or almost completely implemented. If you
can test a package separately, system development and maintenance for each package will be easier.
-
Place general parts of the object model in separate packages on which other packages depend. If there is such a
package, pay strict attention to release handling, since several parts of the system may be affected by changes to
the package.
Example
Suppose you find something in common for the classes Customer Panel and Operator Panel in the recycling
machine. You assign these general services to a new class, Panel that you place in a new package, Panels.
The other two classes may then refer to this class to use the general services. Because the classes belong to two
separate packages, the two packages will depend on the new package. This elimination of redundancy implies that changes
to the common functionality only needs to be done in one place.
|
