WHAT’S IN THIS CHAPTER?            

• The good—how design patterns can lead to success
• The bad—how overuse and misuse of design patterns can lead to trouble
• And the ugly—how some “de-facto” standards can lead to failure

So far, this book has covered many of the classical design patterns from the GoF¹ book as well as some additional patterns that may find their way to becoming classics in the future. This book was written with the aim of being something that the authors would have bought themselves if they had not written it.

As is true with everything in life, design patterns do not always do good. They can do harm as well by leading you into implementing an anti-pattern. This chapter focuses on the good, the bad, and the ugly aspects of design patterns and hopefully provides a better approach for your heavy arsenal of patterns.

THE GOOD: PATTERNS FOR SUCCESS

As has been mentioned many times before, design patterns are the collective wisdom and experience of many smart developers. They unleash a great depth of experience that you can utilize to solve many common problems that occur in software development. Even in the early days of programming when using goto was considered legal (and acceptable), many projects failed. One of the early important resources on software engineering and project management was The Mythical Man-Month written by Frederick Brooks while he was managing development of OS360 for IBM.² Although the book was published in 1975, it still addresses many concerns and problems in modern software projects. At that time, one of the first 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³ commented that “Object-oriented programming is an exceptionally bad idea which could only have originated in California,” it was the first 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 first book to bring together a collection of solutions to common problems as design patterns. That book covered 23 design patterns that have been referred to as classical patterns throughout this book, 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.⁴

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 book Core J2EE Patterns: Best Practices and Design Stratgies.⁵

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 book 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 difficulty 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) configuration and a heavyweight Enterprise JavaBeans (EJB) container. Beans needed to extend specific 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⁶ offered a lightweight container approach, the upcoming design of Java EE favored inline code annotations over configuration files. 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 book. Finally, Context and Dependency Injection (CDI) introduced a new container with great flexible features. With the help of CDI, you can implement many patterns, such as observer and decorator, with little hassle.

THE BAD: OVER AND MISUSE OF PATTERNS

The first training I received on design patterns simply blew my mind. The following month I spent all my time reading Head First Design Patterns⁷ and next, of course, the GoF book. I was armed with the knowledge of patterns and was ready to use them. As time passed by, I realized I didn’t even need to use inheritance and could build all models and object hierarchies with decorators. I even created a set of utility classes consisting of several singletons, some message busses for observers, and some generic decorator and observers that I always included when I created a new project.

I was always proud to show my code and let others see how great and sophisticated a programmer I was. It did not take long to realize my way of using design patterns was just over-complicating my code and adding too many layers during run time. Even simplifying the existing code resulted in better performance. Complex and sophisticated code does not make you a better programmer, and it doesn’t make the code optimized and maintainable. Engineering is the art of using the right tool at the right place and building a system efficiently.

…AND THE UGLY

Design patterns and Java EE are old pals. However, this friendship did not always work out well. As J2EE became more accepted in the corporate world and began addressing large projects, design patterns came to the rescue. Many of the classical patterns from GoF found their place in J2EE applications. Enterprise patterns followed soon after to address common problems in the J2EE platform.

J2EE gained popularity and drove many new concepts such as Service Orientated Architecture (SOA) and Web Services. However, the complex structure of J2EE doomed many projects to fail. J2EE beans relied on extending classes and needed a heavyweight container on which to run. Because the beans rely on the container, the development process needed full-blown heavyweight servers to slow down the development and needed costly hardware to run on. Still, those enterprise containers were slow, resulting in sluggish restarts and refreshes. Testing and unit testing was hard to perform properly.

Besides, J2EE configuration was heavy and relied on XML files. Although separating the configuration and code seemed like a good idea, soon it turned out to be an XML hell. Heavy configuration was needed to create a simple bean.

As J2EE became the platform of the enterprise, consultants, architects, and vendors released sophisticated guidelines that resulted in over-complex, over-architected, and overly layered applications that were impossible to test and hard to develop (due to long restarts), debug, and deploy.

Luckily, Enterprise Java had a happy ending. The POJO and lightweight container movement led by Rod Johnson⁸ gained a huge following and soon became a competitor to J2EE. Spring offered a lightweight container and the ability to run on simple Java servers. The POJO approach was great for testing and did not need the container most of the time, but even if the container was needed, it was not hard to use.

The success of Spring caused a renaissance in the Java Community Process. Java EE 5 was designed from scratch to support POJO EJB and lighter containers. Java EE had evolved and matured.

However, old habits and development techniques did not change overnight. Still, many developers follow the patterns of J2EE, creating overly layered and complex applications while not using the lightweight containers and servers. Just like the English language has changed since Shakespeare’s time, platforms and programming languages have changed. Don’t get stuck in the past by resisting change.

SUMMARY

Design patterns are one of the most important, challenging, and useful topics in software. No object-oriented programmer would be complete without proper knowledge of common design patterns.

Good knowledge provides a great toolset for common problems you are likely to face. Java EE takes this a step further and introduces a much easier and integrated way to use design patterns in enterprise projects. Most patterns in Java EE have been introduced after long debates and pain, which ensures they are well implemented and mature.

All patterns described in this book rely on Java EE standards, so they are almost guaranteed to work successfully.

Still, patterns are neither silver bullets nor magic wands. If they are used extensively without reason, they tend to overcomplicate the project. Knowing a pattern does not necessarily mean you have to use it unless you know it fits and solves a potential problem.

Read and learn design patterns, and try to keep your memory fresh on where they fit and what problems they solve. You will save many lines of code and earn respect.