Java Reference
In-Depth Information
On the other hand, if bundles are too big, they may have sprawling external depen-
dencies. For example, if the code for talking to both Oracle and
DB2
databases is in
the same bundle, that bundle will have dependencies on both the Oracle and
DB2
database packages when both are unlikely to be present at the same time. In a less
extreme case, a bundle that provides both a web frontend and a
JMS
backend will find
itself depending on many unrelated bundles. Bundles that are too big are difficult to
reuse in different contexts because they pull in piles of irrelevant dependencies, all of
which have to be provided before you can call even a single method (see figure 5.3).
In the sweet spot, a bundle will—hopefully—have few dependencies on other bun-
dles in the application, and few external dependencies. In day-to-day software devel-
opment, bundles with tiny dependency sets and few exported packages are much
easier to aspire to than to achieve! Both your authors have sometimes found them-
selves writing bundles with enormously long
Import-Package
statements, despite their
best intentions.
If you end up in a similar situation, you shouldn't beat yourself up over it—we've
all been there, and a lot of us are still there! But, it might be a good opportunity
to look at how your code is divided between your bundles, and see if rearranging your
bundle boundaries, or moving to a more service-oriented approach (see the section,
“Expose services, not implementations”), could neaten things up a bit. It may be that
after looking at your bundles, you decide they're highly cohesive and loosely coupled.
In these cases you've done well, and no restructuring is required. Minimizing imports
and exports is only a rough heuristic, and some highly cohesive and loosely coupled
bundles do naturally have large dependency sets. What's most important is the cohe-
sion and coupling, not how many lines there are in the manifest!
Figure 5.3
Bundles that are too big can have far too many unrelated dependencies. Splitting these bun-
dles up doesn't reduce the number of dependencies, but it can make the dependencies easier to manage,
and the bundles easier to reuse, by not requiring all the dependencies to be present all the time!
