"I like learning from my mistakes ..., but I would much rather learn from your mistakes." -- Bruce Tate, "Bitter Java", page 313.
If design patterns are success stories, anti-patterns are lessons you can learn from other people's failures. Consultants like Bruce Tate make money to support his Kayak hobby by identifying anti-patterns in customer projects and offering valuable advices to refactor them. Now, he has offered his advices for all of us for [$] in Manning's new book "Bitter Java" (ISBN 193011043X).
So, what exactly are anti-patterns? Are they only relevant to software architects? Now, consider the following questions:
Do you know that Java applications might have memory leaks too? Have you written 500 line servlets or JSP pages? Do you notice that your container managed EJBs cannot scale when the load is high? If any of the answers is "yes", Java anti-patterns might be more relevant to you than you think.
This book avoids discussing anti-pattern in academic terms. Instead, it gives a real world server side Java application that an inexperienced developer is likely to write and then refactors it all the way through various anti-patterns to a scalable, maintainable solution. Tate not only teaches you the anti-patterns you encounter, he also gives a valuable example on the software development process to refactor an poorly written existing application.
The author uses extensive real world code examples throughout the book to explain the problems and why we should avoid them. Like all other Manning books, the code examples are well commented and annotated in the main text. Although the anti-pattern examples in the book are mainly in the context of J2EE application servers, the author has done a good job to generalize the problems and illustrate how they might appear in other Java applications. Anti-patterns such as memory leak, synchronized cache read/write and round tripping can have negative impacts on a big range of Java applications.
The author is very good at comparing the relative merits of different approaches, technologies and patterns. There are numerous comparison tables throughout the article and they are great resources for readers who just want a quick summary of what to do/what not to do in a given circumstance. Examples of those helpful tables include the different EJB types comparison on page 241 and the all anti-patterns listing at the end of the book.
In general it is a great book well worth the time and money for all Java developers, especially if you are working on J2EE projects. Of course, there are also things that could be improved.
1. While I liked the kayak stories, some people might find them distracting. However, those side line stories are well separated from the main content using italic fonts. So, this is really not a problem.
2. In chapter 8, I wish the author could talk more about the trade-offs between performance and code maintainability in CMP (Container Managed Perssistency) EJBs. He could also talk a bit about JDO (Java Data Objects), which is a lightweight entity bean alternative.
3. In chapter 3 and 4, the author mentioned that Jakarta Strut's "action" is essentially his "command" pattern. But since Strut is such a popular tool, it would still be nice to give examples on how to use Strut to achieve MVC model along with the "command" pattern example.