Customer Reviews

Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML, 2nd Edition, Volume 1

5 star:		(18)
4 star:		(10)
3 star:		(9)
2 star:		(9)
1 star:		(18)

 

 

There appears to be a flame war in a bookshop about this book, with everybody giving it either 1 star or 5. I believe the truth is somewhere in between.

I'm using the book as a course text for a final year undergraduate course I'm teaching which focusses on patterns. It's far from ideal, but there's nothing out there better as far as I know. There are many typos and thing which could be explained better, but I disagree with those reviewers who claim that the author doesn't understand the subject - in my opinion he clearly does. With one exception (the bizzare characterisation of Marker Interface as a fundamental design pattern) I don't believe there's anything fundamentally wrong.

I'd like to encourage those people who are complaining that it's rubbish to either write a better book, or contribute detailed comments to the author, so he can produce an improved second edition (I'll be doing the latter). It has the potential to be a very good book.

I agree with those who are saying that that volume 2 is very disappointing, but reviews of that shouldn't be contributing to the "score" of volume 1.

I was really excited for a Java-slanted version of the famous Design Patterns book. This should have been an easy home run but Grand let us down on the details. I went into this book knowing some about Patterns and was eager to learn more. However, after wasting my time hacking my way through incorrect diagrams and inconsistencies between code and text I am about ready to through the book out, learn C and read Gamma's book. I don't know who edited this book but they obviously didn't know much about UML or Code.

You want detail examples: Chapter Eight (Chain of Responsibility GoF95). A pretty simple pattern made difficult because of the incorrect UML diagram in the context (association arrows going the wrong direction), and the incorrect text conflicting with the code. I figured the pattern out by comparing it to Gamma's example, it is really quite simple.

The there are many more examples, especially frustrating on some of the more abstract patterns. Grand should have hired a better editor.

If you buy this book and know little about patterns I suggest you also get Gamma's book and refer to it often.

Having written several Java books myself and being a self confessed design pattern addict, I was looking forward to reading this book. Unfortunately I was immensely disappointed with the content. I agree with most of the negative comments written here about both Vols 1 and 2 and only add my own voice to the crowd to ensure the weight of numbers prevails.

The big problem with this book is that it is _so_ inaccurate, both syntactically and semantically, you cannot _trust_ the content.

Some of the text is accurate: for example the description of the Visitor pattern is semantically fairly accurate although there are numerous typos and diagramming errors. However, the accompanying code is not a Visitor pattern. Since the key benefit of this book over other design pattern books is that the code is in Java, the usefulness of the book is lost.

The net effect is that the beginner will not learn design patterns correctly.

Given that a major benefit of design patterns is the common understanding of certain coding idioms, this is a very damaging book. It is like learning to play the piano the wrong way - once the damage is done to the technique it can take years of hard work to repair. You are much better off learning to play properly from the beginning. In the context of design patterns, this means reading the GoF, Siemens, and Doug Lea books.

Like others, I eagerly anticipated an encyclopedia of design patterns implemented in Java. Alas...

I've hosted a bimonthly design pattern discussion group for just over a year. We recently began studying patterns from Grand's book which we had not yet covered. I acknowledge that I hold my opinions more strongly and am more vocal than most, and I would never try to speak on behalf of others. Even so, I think it would be fair to say that our study circle's concensus is "Patterns in Java, Vol 1" is a poor book.

I, of course, have a much stronger opinion: I think "Patterns in Java" is actually detrimental to both the design pattern and Java communities. The writing is terrifically bad. The errors are countless. The intepretation, context, and presentation of the patterns are misguided at best. The example implementations are remarkably sophomoric. As one wag put it, "This book is an excellent source of anti-patterns." An item by item critique of "Patterns in Java" would be roughly twice as long as the book itself; certainly not a task I would relish.

I've been advised to take the good with the bad. Sure, no book is perfect. For instance, our circle was less than satisfied with the presentation of both Flyweight and Intepreter in "Design Patterns" by Gamma et al. But I think we all agree that "Design Patterns" is an excellent book overall. I also accept that patterns appearing in the PLoP books are sometimes formative. Schucks, I even value most pattern articles and features in the various magazines.

Having said all that, I have found NOTHING whatsoever of value in "Patterns in Java". I strongly recommend that you NOT buy this book. All of the patterns presented in "Patterns in Java" are covered better elsewhere. And if you are new to design patterns, "Patterns in Java" will only serve to misguide you.

By allowing an author to threaten legal action based on a negative review, you destroy the viability of providing product reviews in the first place. If we are to be scared into not criticizing product, then the reviews are pointless.

The review to which Mr. Grand refers (not mine, by the way) is by no means libelous -- every author expects to be paid. Insinuating that Mr. Grand expects to make good money off his book is a perfectly valid opinion. You will do your reviewers a great service by removing Mr. Grand's threatening anti-review.

As to the book itself, my prior commentary stands but I now dock the book a star, regardless of my fear of "author reprisal."

This is a book which illustrates strongly the old saying "Don't judge a book by its cover." The title of the book was so attractive that almost every Java Developers that I know of bought it for reference. However, it turns out to be a nightmare to most. The material in the book was so poorly explained that I got lost reading it even after a few times. Sometimes, the author tried to illustrate the implementation of the Pattern by presenting a Java Code fragment. the code was so incomplete that I had no idea what is going on. Furthermore, in the chapter about Snapshot Pattern. The author first describes the pattern by mentioning a typical computer game example which is an interesting introduction. He should have explained more based on this example instead he confused readers by mentioning about serialisation and jump straight to game model class without any class diagrams.

Nowhere near the GoF treatment. The author is merely cashing in on the combined craze of Java & Design Patterns and does justice to neither. Good business for him, poor book for you.

I have read GOF book as well as this book(Vol1). This book is aim at Design Patterns with Java programmers in mind. One thing I like about this book is that it uses different example for each patterns. (The Gof book is based on SmallTalk & C++ and uses through out the book, the long-winded "Maze game" example which I lose interest quickly and hard to understand. I think The GOF book needs updating with different examples for each patterns and also with Java code.). One thing I found is typos and errors in this book. Also, author needs to be very clear and precise about what he is referring to in a pattern as there are several interacting classes around. Use the class name if he needs to. At times, I found that he is not clear..and I lost him.

Other than that, it is probably the best book after GoF. Remember, if people can't see your point, they get's frustrated..

I pity the individual whom selected this book as their first exposure to Design Patterns. A total abuse to the Java programming language or any language. After reviewing Mark's explanation of the Composite and State Patterns, they were far from "Grand". Illustrations are incorrect or incomplete; I am not sure which. The coding examples do not reinforce reusability and are incorrectly implemented. USING CASE LOGIC FOR THE STATE PATTERN! I nearly lost my lunch.

On your next camping trip, take this book with you; it will make a great firelog. NOW THAT'S REUSABILITY!!

Java has been crying out for a translation of popular C++ Design Patterns. This is not it. All the good stuff that Java can do is ignored in this book. I took a look at 2 classic patterns which have been crying out for a nice clean interpretation in Java using Interfaces - Composite and Visitor! Neither pattern in this book makes use of Interfaces. The author almost points it out directly when explaining Composite Pattern when he suggests that it is useful for Tree structured data - you mean like "TreeModel" interface in Swing? Yeh, of course. So why aren't you using interfaces in your implementation? I get irked by the constant justification of the implementations because they were used in the JDK or the JFC. Does that mean the Sun people are infalible? How many Swing developers have wished that JComponent was an Interface and not an essential super class? The truth is that such an implementation on Composite Pattern is a hinderance and not a help in Java. You only have one go at Inheritance in Java and the implementation shown wastes it. If you really want to learn good design techniques using real Java advantages then get Java Design by Peter Coad et al.