Spring in action Third

Springing into action

1.1 Simplifying Java development

A BEAN BY ANY OTHER NAME...Although Spring uses the words
bean and JavaBeanliberally when referring to application components, this doesn’t mean that a Spring component must follow the JavaBeans specification to the letter. A Spring component can be any type
of POJO.

As you’ll see throughout this book, Spring does many things. But at the root of almost everything Spring provides are a few foundational ideas, all focused on Spring’s fun- damental mission:Spring simplifies Java
development.

To back up its attack on Java complexity, Spring employs four key strategies:

¡ Lightweight and minimally invasive development with plain old Java objects (POJOs)

¡ Loose coupling through dependency injection and interface orientation

¡ Declarative programming through aspects and common conventions

¡ Boilerplate reduction through aspects and templates

Almost everything Spring does can be traced back to one or more of these four strate- gies.

1.1.1 Unleashing the power of POJOs

To illustrate, if the HelloWorldBean class shown in listing 1.1 were to be rewritten to function as a Spring managed bean, it might look like this.

Isn’t that better? Gone are all of those noisy lifecycle methods. HelloWorldBean doesn’t implement, extend, or even import anything from the Spring API. Hello- WorldBean is lean, mean, and in every sense of the phrase, a
plain-old Java object. Despite their simple form, POJOs can be powerful. One of the ways Spring empow- ers POJOs is by assembling them using dependency injection. Let’s see how depen- dency injection can help keep application objects decoupled from each other.

1.1.2 Injecting dependencies

Coupling is a two-headed beast. On one hand, tightly coupled code is difficult to test, difficult to reuse, difficult to understand, and typically exhibits “whack-a-mole” bug behavior (fixing
one bug results in the creation of one or more new bugs). On the other hand, a certain amount of coupling is necessary—completely uncoupled code doesn’t do anything. In order to do anything useful, classes need to know about each other somehow. Coupling is
necessary, but should be carefully managed.

With DI, on the other hand, objects are given their dependencies at creation time by some third party that coordinates each object in
the system. Objects aren’t expected to create or obtain their dependencies—dependencies are injected into the objects that need them.

One of the most common ways that a dependency will be swapped out is with a mock implementation during testing. You were unable to adequately test Damsel- RescuingKnight due to tight coupling, but you can easily test BraveKnight
by giving it a mock implementation of Quest, as shown next.

INJECTING A QUEST INTO A KNIGHT

The act of creating associations between appli- cation components is commonly referred to aswir-ing. In Spring, there are many ways to wire components together, but a common
approach has always been via XML. The following listing shows a simple Spring config- uration file, knights.xml, that gives a BraveKnight a SlayDragonQuest.

SEEING IT WORK

In a Spring application, an application contextloads bean definitions and wires them together. The Spring application context is fully responsible for the creation of and
wiring of the objects that make up the application. Spring comes with several imple- mentations of its application context, each primarily differing only in how they load their configuration.

Because the beans in knights.xml are declared in an XML file, an appropriate choice for application context might be ClassPathXmlApplicationContext. This Spring context implementation loads the Spring context from one or
more XML files located in the application’s classpath. The main() method in the following listing uses ClassPathXmlApplicationContext to load knights.xml and to get a reference to the Knight object.

Here the main() method creates the Spring application context based on the knights.xml file. Then it uses the application context as a factory to retrieve the bean whose ID isknight. With a reference to the
Knight object, it calls the
embarkOnQuest() method to have the knight embark on the quest that it was given. Note that this class knows nothing about which type ofQuest
our hero has. For that matter, it’s blissfully unaware of the fact that it’s dealing withBraveKnight. Only the knights.xml file knows for sure what the implementations are.