Doesn't Java's object orientation enable modularity? Well, yes and no. Java does a
great job of providing modularity at the class and package level. Methods and class
variables can be declared public, or access can be restricted to the owning class, its
descendants, or members of its package. Beyond this, there's little facility for modular-
ity. Classes may be packaged together in a Java Archive ( JAR ), but the JAR provides no
encapsulation. Every class inside the JAR is externally accessible, no matter how inter-
nal its intended use.
One of the reasons modularity has become increasingly necessary is the scale of
modern computer programs. They're developed by globally dispersed teams and can
occupy several gigabytes of disk space. In this kind of environment, it's critical that
code can be grouped into distinct modules, with clearly delineated areas of responsi-
bility and well-defined interfaces between modules.
Another significant change to software engineering within the last decade is the
emergence of open source. Almost every software need can now be satisfied by open
source. There are large-scale products, such as application servers, IDE s, databases,
and messaging engines. A bewildering range of open source projects that address par-
ticular development needs, from Java bytecode generation to web presentation layers,
is also available. Because the projects are open source, they can easily be reused by
other software. As a result, most programs now rely on some open source libraries.
Even commercial software often uses open source componentry; numerous GUI appli-
cations, for example, are based on the Eclipse Rich Client Platform, and many appli-
cation servers incorporate the Apache Web Server.
The increasing scale of software engineering projects and the increasing availabil-
ity of tempting open source libraries have made modularization essential. Stepping
back, what exactly do we mean by modularity, and what problems does it fix?
Thinking about modularity
Modularity is one of the most important design goals in modern software engineering.
It reduces effort spent duplicating function and improves the stability of software over
We've all heard code that's too coupled and interdependent described as spaghetti code
This sort of code is unfortunately common—both in open and closed source proj-
ects—and is universally despised. Not only is code like this hard to read and even
harder to maintain, it's also difficult to make even slight changes to its structure or
move it to a new system. Even a slight breeze can be enough to cause problems! Given
how strongly people dislike this sort of code, it should be a lot less common than it is,
but, sadly, in a world where nothing stops you from calling any other function, it's easy
to write spaghetti by accident. The other problem with spaghetti is that, as soon as you
have some, it tends to generate more quickly. . .