This chapter highlights the problems inherent in the large-scale
enterprise Java frameworks that most programmers work with today. I
will cover not only what's wrong with these bloated
frameworks, but how they got that way. Finally, I will lay out the
core principles we'll cover in the rest of the book.
Many programmers fall into the same trap, believing that the more
complicated their code, the better it must be. In fact, simplicity is
the hallmark of a well-written application. This chapter defines the
principle of simplicity, while drawing a distinction between simple
and simplistic. I will also examine the tools and processes that help
you achieve simplicity, like JUnit, Ant, and Agile development.
Programmers need to resist the urge to solve huge problems all at
once. Code that tries to do too much is often too entangled to be
readable, much less maintainable. This chapter traces the path from
being presented with a problem, to truly understanding the problem
and its requirements, to finally solving the problem through
multiple, simple, and targeted layers. It finally describes how to
design your layers to avoid unnecessary coupling.
The programming community has tried for years to solve the problem of
cross-cutting concerns. Generic services, like logging or database
persistence, are necessary for most applications but have little to
do with the actual problem domain. This chapter examines the methods
for providing these kinds of services without unnecessarily affecting
the code that solves your business problemthat is, how to
solve them transparently. The two main methods we examine are
reflection and code generation.
Every choice of technology or vendor you make is an embodiment of
risk. When you choose to use Java, or log4j, or JBoss, or Struts, you
are hitching yourself to their wagon. This chapter examines some of
the reasons we choose certain technologies for our projects, some
traditional choices that the marketplace has made (and why they may
have been poor choices), and some strategies for making the right
decisions for your project.
You simply can not know every use to which your application will be
put when you write it. Any application that is worth the effort put
into it will have a life outside the imagination of its authors. Your
application needs to allow for extension after its release to the
world. This chapter examines the techniques for providing extension
points, from interfaces and inheritance to configuration and the
Hibernate is an open source persistence framework that provides
transparent object-to-relational mapping. It is a straightforward and
simple implementation that focuses on the job of persisting your
domain objects so that they can in turn focus on solving the business
problems at hand.
Spring is an open source application service provider framework on
which to deploy enterprise applications. It has a simple, lightweight
container for your objects, and provides access to a variety of core
J2EE services. However, it does so without all the heavy requirements
of standard J2EE frameworks, and with no intrusion into the design of
your domain objects.
Building on the principles this book espouses, this chapter examines
the construction of a sample application, the Simple Spider. This
application provides indexing and search capabilities for a web site
by crawling its pages, indexing them with Lucene, and providing
multiple interfaces for searching the results.
Having built the Simple Spider, we now examine how easy it is to
extend an application (the jPetstore sample from Chapter 8) if you follow the principles in this book.
We replace the existing jPetstore search feature with the Simple
Spider, then replace the persistence layer with Hibernate.
Finally, this chapter looks ahead to what is coming on the horizon,
new trends and technologies that are here or just around the corner,
and how the ideas in this book are part of a changing landscape in
enterprise Java development.