Practical Design Patterns for Java Developers: by Miroslav Wengner

Early in my career, I read “Design Patterns: Elements of Reusable Object-Oriented Software.” This book is often known as GoF (Gang of Four) after the four authors: Gamma, Helm, Johnson, and Vlissides). This was an excellent book and I referenced it heavily. The patterns are still useful to this day. This book was published in 1994. (Soon we can wish it a happy 30th birthday!).  In a fun coincidence, GoF is about the same age as Java.

“Practical Design patterns for Java Developers” breaks up the design patterns into the same groups – creational, structural, and behavioral. It adds examples of the features from the JDK itself which is great for linking it to things many Java developers have experienced.It also adds examples of implementing the pattern using modern Java. (Java 17 which was the most recent long term release at the time of the book's presenting.) These new features are used heavily making the book good examples of how to use the language.

Given that almost 30 years have past, there are more key patterns now. This book covers all the GoF creational patterns and adds object pool, lazy initialization, and dependency injection.  For structural, the book adds the filter, front-controller, marker, module, and twin patterns. For behavioral, the book adds the caching, null object and pipeline patterns.

The book also covers concurrency patterns and anti-patterns which weren't in GoF. And all that is parts 2 and 3 of the book. Part 1 of the book, gets everyone on the same page. It covers the OOP (object oriented programming), APIE (abstraction, polymorphism, inheritance, and encapsulation) and SOLID (Single responsibility, open-closed, liskov substitution, interface segregation and dependency inversion) terminology in addition to how the JDK is structured.

All chapters except anti patterns end with review questions (and an appendix with answers) to solidify the information. In addition to the patterns material, I particularly liked the memory graphs in the anti pattern chapter. If you bought a printed book, you get a PDF and color diagrams free. (I didn't try this as a got a review copy). The code is also available on GitHub including the commands to run each example.

You do need to be comfortable reading Java to make sense of this book. If you aren't there yet, grab another book first and come back to this one. If you are comfortable reading Java, this book is for you!

I give this book 10 out of 10 horseshoes.

I received a complementary copy from the publisher in exchange for writing this review.

Hello Mr. Miroslav.

I was going through the free chapter of this book. I have reservations around your description of following features of OOP.

1. Abstraction: In my understanding abstraction does not mean to extract the common functionality without providing specific implementation. Abstraction refer to abstracting away the complexity or hiding the complexity or the details of implementation from the calling program. That is why the most common example of abstraction given in text books since ages is that of a car. A driver (synonymous with caller progam) is just provided with steering, transmission, gas pedal and breaks. The driver does not need to know the details of how the engine should work. And we can implement abstraction by using access-specifiers. With the help of access specifiers we can ensure to whom and how much details can be exposed. I can make the methods that can be accessed by a calling program public but this public method can in turn call a private method that encloses the complexity.
Rather the implementation of an interface itself is public because the implementation of an interface i.e the overriding method cannot be more restrictive than overridden method. So i dont understand how interface can help hide complexity from the calling program.

2. Encapsulation : In my understanding, all the data that has one single reason to change must be enclosed in single construct (class) and thats encapsulation. If my Book entity defines - isbn, title, author, publisherName, publisherAddress, publisherPhone, publisherRegistrationNumber, edition then i better encapsulate all publisher info into a single Publisher class. Only expose whats required is actually abstraction and not encapsulation as I just mentioned above

Am I correct or missing something?  I love to be correct but I also enjoy being corrected.