- 3 -
Foreword
In the world of software, a pattern is a tangible manifestation of an
organization's tribal memory. A pattern provides a common solution
to a common problem and so, within the culture of one specific
organization or within one domain, naming and then specifying a
pattern represents the codification of a common solution, drawn from
proven, prior experience. Having a good language of patterns at your
disposal is like having an extended team of experts sitting at your side
during development: by applying one of their patterns, you in effect
take the benefit of their hard-won knowledge. As such, the best
patterns are not so much invented as they are discovered and then
harvested from existing, successful systems. Thus, at its most mature
state, a pattern is full of things that work, absent of things that don't
work, and revealing of the wisdom and rationale of its designers.
Deep, really useful, patterns are typically ancient: you see one and
will often remark, “Hey, I've done that before.” However, the very
naming of the pattern gives you a vocabulary that you didn't have
previously and so helps you apply that pattern in ways you otherwise
might have not have realized. Ultimately, the effect of such a pattern
will be to make your system simpler.
Patterns not only help you build simpler systems that work, but they
also help you build beautiful programs. In a culture of time starvation,
writing beautiful software is often impossible. That's sad, for as
professionals, we strive to build things of quality. By applying a good
set of patterns, it is possible to bring a degree of elegance in to your
systems that might otherwise have been lacking.
The authors of Core J2EE Patterns have harvested a really useful set
of patterns. Don't get me wrong: J2EE is certainly an important
platform, enabling teams to build some very powerful systems.
However, reality is, there is still a wide semantic gap between the
abstractions and services that J2EE provides and the final application
that a team must build. Patterns such as specified in this book
represent solutions that appear again and again in filling that gap. By
applying these patterns, you thus carry out the primary means of
reducing software risk: you write less software. Rather than
discovering these solutions on your own, apply these patterns, which
have already proven their utility in existing systems.
More than just naming a set of patterns, the authors make them
approachable by specifying their semantics using the UML.
