Mastering modularity - OSGi in Action - page 25

The goal of this chapter is to get you thinking in terms of modules rather than
JAR files. We'll teach you about OSG i module metadata, and you'll learn how to
describe your application's modularity characteristics with it. To illustrate these con-
cepts, we'll continue the simple paint program example that we introduced in chap-
ter 1; you'll convert it from a monolithic application into a modular one. Let's get
started with modularity.

2.1 What is modularity?

Modularity encompasses so many aspects of programming that we often take it for
granted. The more experience you have with system design, the more you know good
designs tend to be modular—but what precisely does that mean? In short, it means
designing a complete system from a set of logi-
cally independent pieces; these logically indepen-
dent pieces are called modules . You may be
thinking, “Is that it?” In the abstract, yes, that is it;
but of course there are a lot of details underneath
these simple concepts.
A module defines an enforceable logical
boundary: code either is part of a module (it's on
the inside) or it isn't part of a module (it's on the
outside). The internal (implementation) details of
a module are visible only to code that is part of a
module. For all other code, the only visible details
of a module are those that it explicitly exposes (the
public API ), as depicted in figure 2.1. This aspect of
modules makes them an integral part of designing
the logical structure of an application.

Module

Class1

Class2

Class3
Class4

Class5

Figure 2.1 A module defines a
logical boundary. The module itself is
explicitly in control of which classes
are completely encapsulated and
which are exposed for external use.

2.1.1 Modularity vs. object orientation

You may wonder, “Hey, doesn't object orientation give you these things?” That's cor-
rect: object orientation is intended to address these issues too. You'll find that modu-
larity provides many of the same benefits as object orientation. One reason these two
programming concepts are similar is because both are forms of separation of concerns .
The idea behind separation of concerns is you should break down a system into mini-
mally overlapping functionality or concerns , so that each concern can be indepen-
dently reasoned about, designed, implemented, and used. Modularity is one of the
earliest forms of separation of concerns. It gained popularity in the early 1970s,
whereas object orientation gained popularity in the early 1980s.
With that said, you may now be wondering, “If I already have object orientation in
Java, why do I need modularity too?” Another good question. The need for both arises
due to granularity .