Pragmatic Unit Testing is an easy to read introduction to unit testing. This book covers the basic information you need to know in order to effectively write unit tests.

This book covers in less than 200 pages:

• What is unit testing and why developers must unit test every piece of code they write.
• An introduction to unit testing with JUnit.
• How to effectively write unit tests.
• Testing on a project.
• How unit testing affects the design of the code.

The only thing that I didn’t like about this book is the insufficient coverage of the important paradigm of test driver development.

I read the Core J2EE Design Patterns 2nd edition in July 2005. Below I have written a review for this important book.

Core J2EE Design Patterns is one of the most important books on the traditional J2EE application architecture. If you are programming J2EE systems that are heavily based on EJB 2.x then this book is a must read for you. On the other hand if you are programming J2EE (without EJB ) with more lightweight tools, like Spring, don’t rush to go without considering to read this book. This book, no matter which technology you use to implement enterprise applications provides good information on object oriented design and layering.

Of course, as many people have said before, a lot of the core J2EE design patterns are not really patterns but they just provide ways to overcome several limitations in some of the J2EE technologies. Examples of “pseudo-patterns” include Composite Entity and Data Transfer Object which try to address some limitations of the EJB Entity Beans. I believe that the reader can also learn a lot from these “pseudo-patterns”. For example the Data Transfer Object can be seen as a way to decouple two layers or as a more general pattern for distributed computing where you aggregate all the information that you want to pass between the nodes in transfer objects and not just as a way with acceptable performance to get multiple fields from an Entity Bean. For example if for some reason you have a physically separated business tier and you use a technology like Hibernate for persistence you will probably need to have a remote facade that will return transfer objects with all the information that you need in the presentation tier in order to avoid any LazyInitializationException exceptions. I find almost everything in the book useful and educative.

For me a book on design patterns is useful if it has lots of code to illustrate how the patterns can be implemented. The Core J2EE Design Patterns not only provides implementations for all the patterns but also provides and analyzes various implementation strategies. You can see multiple ways to implements most of the patterns, learn the trade-offs of each implementation strategy and also get a deeper understanding of the various J2EE technologies.

The UML diagrams in the book are very good and very helpful since they help you visualize the interactions in the design pattern and you better understand the responsibilities of the participant objects.

I’d like to note two things that are specific to the second edition. First the existence of Web Service Broker, a pattern on how to implement web services in J2EE 1.4, tells us the important role of web services in the J2EE 1.4 update. Second the existence of Business Object tells us that the procedural style of EJB applications made J2EE programmers forget the basics of object oriented programming. You cannot create a rich in behavior domain model with Entity Beans cause they don’t support inheritance and they are not reentrant (if Entity Bean “A” calls Entity Bean “B” then in the same call stack B cannot call back to A). So J2EE programmers implemented all the business logic inside a service layer (with Session Beans), with anemic domain models using Entity Beans. A service layer can be good for things like transaction management, security and other infrastructure services but when you have complex business logic and an anemic domain model you can easily end up with lots of duplicate code. The Business Object is a back to the basics design pattern that acknowledges the importance of rich in behavior domain models.

I would also like to comment on the Composite Entity design pattern. I have very limited knowledge of Entity Beans. I have used Entity Beans in only one project. Most of the projects that I worked on were using Hibernate or JDBC. While reading this pattern I felt very strange since it is very awkward for me to program with Entity Beans. I believe that if you have an exposure to tools like Hibernate and you go back to implement persistence using Entity Beans you are continuously asking yourself “Why things have to be so hard to do and so restrictive?”. I am so glad to see the new EJB 3.0 Entity Beans specification, things are so much better now.

On the other hand, the Domain Store is a welcomed addition to the J2EE patterns. This pattern provides a good explanation for the generic POJO persistence frameworks like Hibernate, JDO and EJB 3.0 (JSR 220).

For me, the Core J2EE Design Patterns 2nd edition was a very pleasant reading since I expanded my knowledge of J2EE and also cleared some things in my mind. I was aware of most of the patterns in this book but reading them from this book made them more clear in my mind. From my experience a lot of J2EE programmers do not really understand most of the core J2EE design patterns and misuse them.

My conclusion for Core J2EE Design Patterns 2nd edition is that it is a very well written book that is a must read for every J2EE developer since not only does it provide valuable information about programming J2EE applications with the traditional architecture but it also defines a widely used vocabulary for common J2EE patterns and idioms.

Highly recommend if you are thinking to move your development to Java 5.