Java Reference
In-Depth Information
imports, perhaps it's trying to do too much in too many different areas (incohesive).
For example, does the code for generating servlets and the code for sending
JMS
mes-
sages need to live in the same bundle? The number of imports doesn't show anything
about coupling, but the nature of what's imported does. If a bundle imports low-level
API
s or, worse yet, implementation packages, perhaps it's too closely coupled to its
dependencies. Similarly, if a bundle has too many exports, it might be a bloated module
trying to do too much in too many areas. If it's exporting lots of packages, it may be
exposing too many of its innards to the outside world and encouraging an unhealthy
level of coupling; if it's exposing packages containing implementation classes, the cou-
pling is almost certainly too high. Keeping a handle on your imports and exports is a
nicely complementary goal to achieving a well-structured modularization.
The
Require-Bundle
header is also a big clue that two bundles are tightly coupled.
Ask yourself if you need those classes to come from that particular bundle rather than
somewhere else. If you do need your dependencies to come from a fixed place, then
the chances are that your classes should be packaged there too!
HOW TO MINIMIZE PACKAGE IMPORTS AND EXPORTS
The dependency graph of a well-architected application should look less like spa-
ghetti and more like a fork. Try to keep both the package exports and package
imports as small as possible. This can be a useful guide to sizing your bundles cor-
rectly. If the bundles are too small, function will be split between bundles and depen-
dencies that should be internal are forced to be external (see figure 5.2).
Figure 5.2
Bundles that are too granular will be forced to import and export lots of packages from other
parts of the application (solid lines). If the bundles are made slightly larger, many of those dependencies
become internal-only (dotted lines).
