Java Reference
In-Depth Information
many concerns and problems in modern software projects. At that time, one of the i rst design
patterns in software was becoming popular: object‐oriented programming (OOP). OOP was a set of
design rules and patterns that enabled real‐life situations to be modeled in code more effectively and
easily. It simply offered a magic wand for designing, coding, and maintaining software. Smalltalk,
C++, and Objective‐C pioneered the early golden years of OOP. Although Edsger Dijkstra
3
commented that “Object‐oriented programming is an exceptionally bad idea which could only have
originated in California,” it was the i rst major shift that changed how programs were written.
However, OOP was not a silver bullet either. First, using an object‐oriented language did not really
mean using an object‐oriented approach. Developers were, and still are, allowed to write procedural
code in any object‐oriented language. Second, complex and badly designed objects being used were
at least as capable at complicating things as any non‐OOP systems.
In the early 1990s, the famous Gang of Four, Erich Gamma, Richard Helm, Ralph Johnson, and
John Vlissides, published
Design Patterns: Elements of Reusable Object‐Oriented Software
,
which was the i rst topic to bring together a collection of solutions to common problems as design
patterns. That topic covered 23 design patterns that have been referred to as classical patterns
throughout this topic, and they included code examples in C++ and Smalltalk. Over the years, many
new patterns have been introduced and added to pattern catalogs by many great programmers such
as Jim Coplien.
4
However, design patterns are not language and platform dependent and can be implemented in any
software project. Design patterns solve common problems and offer a common dictionary between
developers. Instead of describing how you implemented a callback mechanism, which is only
triggered when there is a change on the resource, you can say, “Oh, we have observers on x.”
When Java was developed in the mid‐1990s, many design patterns were integrated into its run
time. Java made good use of design patterns in its internal design and exposed many patterns in the
language itself by providing a default implementation application programming interface (API).
With the release of Java EE, even more patterns were introduced, many of which were published in
the topic
Core J2EE Patterns
:
Best Practices and Design Stratgies
.
5
Reading pattern catalogues and learning their use cases does increase your knowledge of many
common problems and how to solve them, even before they have appeared. This topic has listed
many war stories about how a particular design pattern has affected the project. These stories are
from real‐life experiences. Reading and memorizing a pattern is no guarantee of a magic solution,
but it may give you some clues and hints about how to solve a problem when you come across a
similar difi culty or challenge. Very soon, and with experience, you will end up addressing problems
even before they have occurred by using an appropriate pattern.
Initially, the J2EE programming model relied heavily on Extensible Markup Language (XML)
coni guration and a heavyweight Enterprise JavaBeans (EJB) container. Beans needed to extend
specii c classes and implement each method to work properly. Very soon, this approach proved
not to be productive and almost became an anti‐pattern. Although Spring
6
offered a lightweight
container approach, the upcoming design of Java EE favored inline code annotations over
coni guration i les. The lightweight container and EJB based on Plain Old Java Objects (POJOs)
offered a productive and easy‐to‐test programming model. Subsequent releases of Java EE offered
many desired features, most of which have been covered throughout the topic. Finally, Context and
