Java Reference
In-Depth Information
In 1994, the book
Design Patterns: Elements of Reusable Object-Oriented Software
, by Erich
Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley, 1994) (the “Gang of
Four” or “GoF”), applied Alexander's ideas to software. This topic expounded OO patterns and
ushered in a wave of best-practice solutions, addressing a number of design requirements that
surfaced over the years with a design strategy that is reusable across applications.
As server systems grew, enterprise infrastructure such as Java EE emerged that provided
abstractions of technologies and services. However, using Java EE does not naturally lead to
best-practice architecture and design. John Crupi, Dan Malks, and Deepak Alur first established
Java EE design patterns based on their experience of architecting enterprise systems.
Applying these Java EE design patterns to the development of a Java EE-based application is
de rigueur
to achieving best-practice architecture and design. That said, ensuring best-practice
architecture and design is not enough to ensure reusable, maintainable, extensible software. Even with
the Java EE design patterns in place, a software project is often afflicted by a phenomenon called
entropy
, a measure of the degree of disorder. According to the Second Law of Thermodynamics,
everything in the universe moves from low entropy (a state of order) to high entropy (disorder) and
eventual chaos. Everything in nature is bound by this law of physics, and nature deals with this
irrevocable law by means of evolution.
A software project too often tends to move from low entropy to high entropy, and to deal with the
disordered state, it needs to keep evolving. That is not to say that evolving your project supersedes
project management and methodologies; despite the most finely honed project management,
sharp-edged methodologies, and a team with a keen sense of style, a software project may fall into
a state of high entropy. Figure
3-1
presents the evolutionary steps in Java EE's web tier that help
deal with entropy in software projects.
Figure 3-1.
The evolution in the Java EE web tier
As you can see in Figure
3-1
, not only have the technologies in the Java EE web tier evolved, but new
ones are added with each new release. If you are still using J2EE 1.4, for instance, you will not have
the unified EL (EL 2.1) in your toolbox. It is essential to keep up with the evolution of any technology
to keep from falling into the eventual state of high entropy that can afflict any software project.
This chapter elucidates the importance of gradually evolving a project with any new technologies
available with each new release of Java EE and using them to deal with high entropy in the project.
The chapter then discusses the importance of the Java EE patterns and explains how the web
