Developing with POJOs: faster and easier - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 15

An Account maintains its balance and has an OverdraftPolicy , which determines
what happens when the account is about to become overdrawn. OverdraftPolicy is
an example of a Strategy pattern [Gang of Four] and there are two implementations
of OverdraftPolicy : one for each type of real-world policy. Better yet, an Overdraft-
Policy could encapsulate a rules engine and thereby enable the business rules for
overdrafts to be changed dynamically. TransferTransaction , which is a subclass of
BankingTransaction , records the transfer of money between two accounts.
Using an object-oriented design has a number of benefits. First, the design is
easier to understand and maintain. Instead of consisting of one big class that does
everything, it consists of a number of small classes that each have a small number
of responsibilities. In addition, classes such as Account , BankingTransaction , and
OverdraftPolicy closely mirror the real world, which makes their role in the
design easier to understand.
Second, our object-oriented design is easier to test: each class can and should
be tested independently. For example, we could write unit tests for Account and
for each implementations of OverdraftPolicy . In comparison, an EJB can only be
tested by calling its public methods, for example, transfer() , which is a lot more
difficult. You can only test the complex functionality exposed by the public meth-
ods rather than test the simpler pieces of the design.
Finally, the object-oriented design in figure 1.2 is easier to extend because it
can use well-known design patterns, such as the Strategy pattern and the Template
Method pattern [Gang of Four]. Adding a new type of overdraft policy simply
requires defining a new subclass of OverdraftPolicy . By contrast, extending an
EJB -style procedural design usually requires changing the core code, and rewrit-
ing or chaining procedure calls together.
As you can see, our object-oriented design has some important benefits. But it
is essential to know when it is not a good choice. Later in this topic I describe how
to decide between procedural and object-oriented approaches.

1.2.2 Using POJOs

Once you break free of the constraints imposed by the EJB 2 programming model,
implementing the object model shown in figure 1.2 is easy. Java provides all of the
necessary features, including fine-grained objects, relationships, inheritance, and
recursion. It is straightforward to implement expressive object models like this
one using POJO s and thus benefit from improved maintainability and testability.
Java is an object-oriented language, so it is foolish not to use its capabilities.
As a bonus, POJO s have these other important benefits: