Mastering modularity - OSGi in Action - page 26

Assume you need some functionality for your application. You sit down and start
writing Java classes to implement the desired functionality. Do you typically imple-
ment all your functionality in a single class? No. If the functionality is even remotely
complicated, you implement it as a set of classes. You may also use existing classes
from other parts of your project or from the JRE . When you're done, a logical relation-
ship exists among the classes you created—but where is this relationship captured?
Certainly it's captured in the low-level details of the code, because there are compila-
tion dependencies that won't be satisfied if all classes aren't available at compilation
time. Likewise, at execution time, these dependencies will fail if all classes aren't pres-
ent on the class path when you try to execute your application.
Unfortunately, these relationships among classes can only be known through low-
level source code inspection or trial and error. Classes allow you to encapsulate the state
and behavior of a single, logical concept. But numerous classes are generally necessary
to create a well-designed application. Modules encapsulate classes, allowing you to
express the logical relationship among the classes—or concepts—in your application.
Figure 2.2 illustrates how modules encapsulate classes, and the resulting inter-module
relationships. You may think that Java packages allow you to capture such logical code
relationships. Well, you're right. Packages are a form of built-in modularity provided by
Java, but they have some limitations, as discussed in section 1.1.1. So packages are a good
starting point in understanding how modularity helps you encapsulate code, but you
need a mechanism that goes further. In the end, object orientation and modularity serve
different but complementary purposes
(see figure 2.3).
When you're developing in Java, you
can view object orientation as the imple-
mentation approach for modules. As
such, when you're developing classes,
you're programming in the small , which
means you aren't thinking about the
overall structure of your application, but
instead are thinking in terms of specific
functionality. After you begin to logi-
cally organize related classes into mod-
ules, then you start to concern yourself
with programming in the large , which
means you're focusing on the larger log-
ical pieces of your system and the rela-
tionships among those pieces.
In addition to capturing relation-
ships among classes via module mem-
bership, modules also capture logical
system structure by explicitly declaring
dependencies on external code. With

Module2

Module1

Class1 Interface1 Class2

Class3

Figure 2.2 Classes have explicit dependencies
due to the references contained in the code.
Modules have implicit dependencies due to the
code they contain.

Visibility
Accessbility
Cohesion
Coupling

Object
orientation

Modularity

Figure 2.3 Even though object orientation and
modularity provide similar capabilities, they
address them at different levels of granularity.