Java Reference
In-Depth Information
DLL hell, recognized this connection early in . NET , which is why it has a module con-
cept called an assembly . Finally, the size of applications continues to grow, which makes
modularity an important part of managing their complexity—divide and conquer!
This discussion provides some potential explanations for why modularity is coming
back in vogue, but it doesn't answer this section's original question: Why should you
modularize your applications? Modularity allows you to reason about the logical struc-
ture of applications. Two key concepts arose from modularity decades ago:
Cohesion measures how closely aligned a module's classes are with each other
and with achieving the module's intended functionality. You should strive for
high cohesion in your modules. For example, a module shouldn't address many
different concerns (network communication, persistence, XML parsing, and so
on): it should focus on a single concern.
Coupling , on the other hand, refers to how tightly bound or dependent differ-
ent modules are on each other. You should strive for low coupling among your
modules. For example, you don't want every module to depend on all other
modules.
As you start to use OSG i to modularize your applications, you can't avoid these issues.
Modularizing your application will help you see your application in a way that you
couldn't before.
By keeping these principles of cohesion and coupling in mind, you'll create more
reusable code, because it's easier to reuse a module that performs a single function
and doesn't have a lot of dependencies on other code.
More specifically, by using OSG i to modularize your applications, you'll be able to
address the Java limitations discussed in section 1.1.1. Additionally, because the mod-
ules you'll create will explicitly declare their external code dependencies, reuse is fur-
ther simplified because you'll no longer have to scrounge documentation or resort to
trial and error to figure out what to put on the class path. This results in code that
more readily fits into collaborative, independent development approaches, such as in
multiteam, multilocation projects or in large-scale open source projects.
Now you know what modularity is and why you want it, so let's begin to focus on
how OSG i provides it and what you need to do to use it in your own applications. The
example paint program will help you understand the concepts.
2.3
Modularizing a simple paint program
The functionality provided by OSG i's module layer is sophisticated and can seem over-
whelming when taken in total. You'll use a simple paint program, as discussed in
chapter 1, to learn how to use OSG i's module layer. You'll start from an existing paint
program, rather than creating one from scratch. The existing implementation follows
an interfaced-based approach with logical package structuring, so it's amenable to
modularization, but it's currently packaged as a single JAR file. The following listing
shows the contents of the paint program's JAR file.
Search WWH ::




Custom Search