Java Reference
In-Depth Information
this in mind, we now have all the pieces in place to more concretely define what we
mean by the term
module
in the context of this topic.
MODULE
A set of logically encapsulated implementation classes, an optional
public
API
based on a subset of the implementation classes, and a set of
dependencies on external code.
Although this definition implies that modules contain classes, at this point this sense
of containment is purely logical. Another aspect of modularity worth understanding is
physical modularity
, which refers to the container of module code.
Logical vs. physical modularity
A module defines a logical boundary in your application, which impacts code visibility
in a fashion similar to access modifiers in object-oriented programming.
Logical mod-
ularity
refers to this form of code visibility.
Physical modularity
refers to how code is
packaged and/or made available for deployment.
In OSGi, these two concepts are largely conflated; a logical module is referred to as
a
bundle
, and so is the physical module (that is, the JAR file). Even though these two
concepts are nearly synonymous in OSGi, for modularity in general they aren't, be-
cause it's possible to have logical modularity without physical modularity or to pack-
age multiple logical modules into a single physical module. Physical modules are
sometimes also referred to as
deployment modules
or
deployment units
.
The
OSG
i module layer allows you to properly express the modularity characteristics
of applications, but it's not free. Let's look in more depth at why you should modular-
ize your applications, so you can make up your own mind.
2.2
Why modularize?
We've talked about what modularity is, but we haven't gone into great depth about
why you might want to modularize your own applications. In fact, you may be think-
ing, “If modularity has been around for almost 40 years and it's so important, why isn't
everyone already doing it?” That's a great question, and one that probably doesn't
have any single answer. The computer industry is driven by the next best thing, so we
tend to throw out the old when the new comes along. And in fairness, as we discussed
in the last section, the new technologies and approaches (such as object orientation
and component orientation) do provide some of the same benefits that modularity
was intended to address.
Java also provides another important reason why modularity is once again an
important concern. Traditionally, programming languages were the domain of logical
modularity mechanisms, and operating systems and/or deployment packaging sys-
tems were the domain of physical modularity. Java blurs this distinction because it's
both a language and a platform. To compare to a similar situation, look at the .
NET
platform. Microsoft, given its history of operating system development and the pain of
