Java Reference
In-Depth Information
Today in Java EE 7, most “classic” design patterns described in the GoF book are embedded in
the platform ready to be used “out of the box.” Unlike the J2EE era, most of these patterns can be
implemented via annotations and without the need for convoluted XML coni guration. This is a
huge leap forward and offers the developer a simplii ed programming model.
Although there are several great topics on design patterns and the new features of Java EE, there
seems to be a missing link on how those patterns are implemented in Java EE.
Plain Old Design Patterns Meet Java EE
Even from day zero, Java has been friendly toward design patterns. Some of the patterns have a
built‐in implementation that is ready to use, such as the observer pattern in Java SE. Java itself also
uses many design patterns; for example, the singleton pattern is used in the system and runtime
classes, and comparators are a great example of the implementation of the strategy pattern.
The tradition has continued with Enterprise Java, but especially Java EE, which has built‐in imple-
mentations of many of the patterns described in the GoF book. Most of these patterns can be
enabled and used with simple and easy‐to‐use annotations. So instead of looking at class diagrams
and writing boiler plate code, any developer with experience can enable a pattern with just a few
lines of code. Magical? Well, not quite. Because the Java EE run time has a more sophisticated
design, it can offer many capabilities, relying on the power of the underlying platform. Most of the
functionality that those patterns need would not be available without Java EE's superset of features
such as EJB and Context and Dependency Injection (CDI). The Java EE container does most of the
work for you as it adds many embedded services and functionality to the server. The drawback is
that it has resulted in a heavyweight server runtime environment, especially compared to basic web
servers such as Apache Tomcat. However, this has improved, and the latest runtime builds on Java
EE 7 are more lightweight.
Still, why do people continue to need design patterns in enterprise applications? Well, patterns are
needed now more than ever before. Most of the enterprise applications are built for corporations by
different teams of developers, and different parts need to be reused often. Unlike solving a common
problem pattern on your own or in a small team, your solutions are now exposed to the whole corpo-
ration and beyond to potentially the whole world (if your project is open source). It is easy to introduce
a poorly designed application and let it become a corporate tradition or development strategy. Because
libraries, utility classes, and application programming interfaces (APIs) are exposed to more develop-
ers, it has become even harder to break compatibility and make radical changes. Changing one return
type or even adding a new method to an interface may break all projects relying on that piece of code.
It is clear that enterprise software development requires a higher level of discipline and coordination
between developer teams. Design patterns are a good way to approach this problem. However, most
enterprise developers still do not make good use of classical design patterns even though they have
been in Java EE since version 5.0. Although enterprise patterns can solve many issues, the original
design patterns continue to have much to offer. They are well worn and proven solutions, they have
stood the test of time, and they have been implemented in almost all object‐oriented languages.
Finally, because most of those patterns are already integrated in the Java EE platform, there is no
need to write the full implementation code. Some may require a little XML coni guration, but most
of the patterns can be implemented by applying an annotation to the class, method, or member
