Bought this book for my nephew. His comment was "there are a lot of good parts, but you have to search for them."

I haven't seen the first edition of this book.

The examples are rather good and the diagrams are in UML. Compare it to diagrams in [GOF95] which are written in some wierd ancient notation.
Although the exampled are in Java this book is good for C++ devs. This books is the fastest way to understand design patterns.

This book covers roughly the same territory as the GOF (Gamma, Helm, Johnson, Vlissides) book, only with simpler examples, in Java.

I found it easier to read than GOF; it gave me with a better overall understanding of the topic in general, and of specific design patterns. Grand's book may be slightly less valuable as a reference, however, when you need to actually use one of the patterns.

This book covers roughly the same territory as the GOF (Gamma, Helm, Johnson, Vlissides) book, only with simpler examples, in Java.

I found it easier to read than GOF; it gave me with a better overall understanding of the topic in general, and of specific design patterns. Grand's book may be slightly less valuable as a reference, however, when you need to actually use one of the patterns.

The help this offers is for students who haven't learned a lot of languages yet. For them, the effort of picking Java sense out of C++ or Smalltalk may defeat the rest of the pattern discussion. For them, Java code samples and references to familiar Java library elements can make all the difference.

For the rest of us, this book has decidedly mixed value. The real problem is that Grand seems to equate the terms "desgin pattern" and "good idea". Design patterns are good ideas, at least in the right context, but not all good ideas are design patterns.

For example, delegation of responsibility is a good idea. It's the basis of any system decomposition. I have trouble justifying that as a design pattern - you may as well say that passing function parameters is a design pattern. It's just too broad. At the other end of the spectrum, Grand points to "marker" interfaces, Java interfaces with identities but not content, as a design pattern. Again, this is a useful but language-dependent hack. Ada or C# would have done the same things with attributes, and C++ could have done the same using marker fields or values in the class. Language tricks aren't patterns.

Still, many of Grand's patterns are good ideas. The "Object Pool", for example, is a common and useful pattern. It's closely related to two GoF patterns. It's like a Singleton, except there's more than one of them. It's like a Flyweight, except the units aren't distinguishable or shareable.

One real annoyance is the tendency of this Volume I to refer to necessary information in Volume II. If the author is going to create independently saleable units of book, they should be independently readable. I do not appreciate the implicit plug for the author's other work.

I use this book, but mostly for its bad examples. Think hard about whether this is the way to spend your budget for DP books.

About every month or so I get spammed by this author touting his great seminars so I thought I'd give his book a shot. I guess you could say that he finally wore me down. Luckily I actually purchased the book used for $2 and still think I was royally ripped off.

The book begins poorly and gets worse. Specifically, the author definitely has a pension for patronizing his audience. He speaks as though he invented Patterns and is delivering them to the masses after bringing them down from the mountains inscribed on clay tablets.

Now, I'm not a guy to worry too much about a few typos here and there. After all, mistakes are made in code and text alike. However, the author's examples are not at all practical to the point of being useless and far too many of them flat out don't work!!

I'm not so much upset about the measly two bucks as I am about the several hours lost trying to decipher what the author meant and working through the typos. Anyway, hopefully this review will save someone else the time I lost.

Not as good as the GOF book, but much better than others. You'll be needing the GOF to understand plentifully the patterns. A nightmare the sea of typo errors throughout the whole book. As others reviewers wrote, the author should have paid more attention to the final draft before sending it to print.

Not as good as the GOF book, but much better than others. You'll be needing the GOF to understand plentifully the patterns. A nightmare the sea of typo errors throughout the whole book. As others reviewers wrote, the author should have paid more attention to the final draft before sending it to print.

The first time I read this book was to look up the Decorator Pattern. I went directly into the chapter and was highly disappointed by the numerous mismatches of class names found in the examples. My head was spinning after reading the chapter and gave up the whole book altogether. (I dont want to take the risk of writing another list of printing errors found in each chapter I read. I am a reader not their proofreader!!!)

For example, the text refers to a name 'DoorController' but the diagram (Fig 7.28) only has 'DoorControllerIF', 'DoorControllerWrapperA', and 'DoorControllerWrapperB'. What the hell does it refer to?

In Fig 7.30, the interface has 2 methods - 'Operation1()' and 'Operation2()', but all subclasses of it use the names 'Operation()' and 'Operation2()', instead. Does it mean 'Operator1()' and 'Operation()' are 2 different methods?

The source code in P280 uses the type name 'SurveillanceMonitorIF' but there is no such a type ever found in the text - the closest match is 'surveillanceIF' only!!!!!

This *could* be a great book provided that the author/publisher pay SERIOUS attention to the importance of consistent naming.

If you are a hands on Java programmer and want the design patterns explained as you can understand them in code, this book is worth it. I notice other reviewers slate this book, picking up on what they consider to be "errors". Well, ultimately GOF4 is always going to be the authority on patterns but GOF4 is very dry - this book gives a practical java code explanation of the patterns. I often browse through it looking for ideas.

I read the first edition, and this is a huge improvement-new examples really show how to apply these patterns to everyday situations. The vendor-neutral solutions make this a great book for anyone working with Java.

Design patterns presented are not any one company's best solution, but simply the best proven solution regardless of product or methodology. With most vendors incorporating design patterns into their products, this book is a great introduction to the topic of design patterns and how they can fit into your Java applications.

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!!

Current average of the book is 2.5. I think this book deserves more than 2.5 points.
I also have Gof book. I think Gof is easiler to read, but many examples are UI related. This book gives me examples like traffic control and security system. I will buy it for those examples. Java and UML in the book are also a good reason to buy. Do not expect the example to run. Try to understand the idea. You need to have good Java skill and a bit UML to read this book.

The code examples are sketchy and incomplete, and often utilize techniques that may be good practice but that obfuscate the concept the reader is trying to learn.

For example his coverage of the Delegation pattern (which I have yet to see documented in any other book, I'm still looking :) is verbosely explained but the accompanying example code is so vague and has so many ...'s as to be almost unusable.

If you are a Java programmer without years of experience, the GoF book may be quite difficult. This book is not as thorough but is a lot easier and has the sample code in Java. This book does adequate job in introducing the pattern concept and the most important patterns to the not-so-experienced coder. If you feel intimidated by the GoF book, buy this first. If not, then you might want to pass this one.

I too bought the Java Design book to cover the subject with an affinity to Java and UML. Concurrently reading GoF and comparing patterns which is almost like comparing a work of Shakespeare with that of an amateur. Ended up just toughing through the smalltalk examples and pre-UML diagramming conventions to end with clearer explanations and correct coverage. I almost bought volumne 2 at the same time.. I'm glad I did not. Unfortunately there are not many alternatives out there.

I read the first chapter of this book and it does seem easier than the Gof book, although the reviews scare me away. On the other hand I'm afraid I'll get confused with the multiple inheiritance of C++ in Gof. Another book to consider is Bruce Eckel's java design patterns book. It isn't out yet, but it's at his web site. I liked his book about object oriented programming. Maybe I'll just print it out.

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.

This book was my first introduction to patterns and I absolutely loved it. What I love about it is that the author gives examples of where a lot of the patterns are used in the standard java api's. In this way, it really helps to visualize how you might use the pattern. Also, there are introductory chapters on UML and the software development lifecycle, which advantageous for those that aren't familiar with the topics.

I have two volumes and I am looking forward to future volumes!

The explanations here are more clear than those in Go4 or other pattern catalogs I've read. This book was written with the reader in mind. Very nice.

If you really want to get to know a book, make it a required text for a course you teach. That's what I have done. This is one of very few books that have not disappointed me as a text in a course.

I have not looked at the source code that comes with the book. The explanations are so clear, it is easy to implement the patterns yourself. Keep up the good work, Mark.

Here's what I did to evaluate design pattern books: Read GofF and then sat in a B&N bookstore with every design pattern book they had. This was the one I found to be the most useful. Some caveats: First of all, if you're not at least an intermediate java programmer, you probably will have a hard time reading this book. Buy Volume 2 first (kind of strange but it's actually not as advanced) which is less about design patterns and more about fundamental design principles. Second, even if you are an intermediate to advanced Java programmer, it can be difficult to understand. But then, the subject matter is by nature abstract. Unfortunately, I haven't found anything more useful, including GoF. It's written for C++/Smalltalk and sometimes the multiple inheritance allowed by those languages makes it difficult to translate the pattern to Java. I have found this book to be the one I end up getting the most out of when I'm doing Java design work. It makes a great reference.

...I've read about 8 or 9 patterns in Grand's book. The writing is good, and clear, but lacks the snooty vocabulary of Rational publications (thank goodness!). I think this book is an excellent resource - to the point, and if you don't know C++ or SmallTalk, you'll get a lot more out of this book than you will from Gamma et al.

Well, if you think you could understand from an incomplete Java code, this would be the right book for you. For most of us in the planet earth, we learn from trial and error (proven) methods.

This book is sort of ok. What I don't like about it, is that the Author reallys just rehashes what others has already written (Gamma et al Design Patterns and Current Programming in Java by D. Lea). The only advantage this book has to Gamma et al, is that it uses UML and Java - which is cool if that's what you know.

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.

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..

As a frequent reader I found this book quite simply one of the best. I loved the way it was written, and the way it involved the reader. A must read. Better than a weekend at Reeco's.

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 just read everything, from the intro, mini case study, to the first few patterns.) Like others have stated, this book is full of distracting typos and lots of misindented and broken code. Many of the long descriptions are confusingly worded and peppered with bad grammer, such as runon sentences and missing commas. I will never buy a Mark Grand book again without being able to easily return it (ala amazon.com). My opinion of Wiley as a publisher has gone down a few notches for letting such a low quality book get published.

Oh my, that this book misses the mark so badly is laughable (you have to laugh or you'll cry!). The author doesn't truly understand the subject matter at all with numerous bad implementations of the GoF patterns. This shows a lack of true understanding of the GoF patterns in the first place as well as a lack of true understanding of Java (interfaces leaps out as an example here).

I agree with another reviewer. The only book worse than this is Volume 2.

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.

I have seen more than a hundred books on Java. The only Java book worse than volume 1 of this series is volume 2. The author demonstrates only a superficial understanding of his subject matter. Countless errors range from code bugs to thorough misunderstanding of the issues associated with the patterns he presents. Readers of this volume will be guided into inferior designs with greater likelihood of rework.

Some companies are now starting to use this material to judge applicants. Applicants who quote this material or show similar levels of misguidance are being turned away, judged not fit to hold positions as experienced software developers.

Readers wishing to learn design patterns should start with the GoF book (Design Patterns by Gamma, Helm, Johnson, and Vlissides). A thorough understanding of that book's material will greatly benefit the reader. Patterns in Java will serve only to midguide, misinform, and confuse.

I found the first edition of this book to be pretty good - many of the comments here with low ratings for this book are really for the second edition, which does have many of the problems described.

I was excited when this book came out and bought it w/o hesistation. Unfortunately, after reading the book I came to realize that the author has only a superficial understand of design patterns, what's even worse is some of his explanations were completely off the mark! This book should never had been published and is ample testament to the poor quality of recent books released by the publisher.

Anyone claiming that this book is 5 stars is totally clueless or is in someone's payroll.

I have bought the book, but have not read it yet. Given that many of the reviews are so poor, I may not read it. But, can one of the disgruntled readers suggest another alternative that addresses pattern designs specific to Java?

The material is good, interesting and usefull, but very badly printed: you never got the diagrams where you expect them to be, right by the text talking about them. It shouldn't have been a big affort to make the text and the images fitting... The result is a difficult reading and a confusional effect.

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.

Yes, it is high time to apply design patterns to Java. Java presents opportunities and challenges that were not present in C++.

In this two-volume series, Mark Grand converts well-established design patterns into Java. Unfortunately, he fails to demonstrate even a rudimentary understanding of his material. These books in this series read like hopelessly flawed research papers, not the fruit of experience. I finished them wondering whether the author had ever actually implemented any of these patterns in a real-world design.

He misinterprets some key points while missing others altogether. Some of the GoF patterns use inheritance for mixins. That's fine in C++, but Java provides only single inheritance. Wasting inheritance as he does, the author's implementations make it impossible to use inheritance for normal (more important) purposes. Interfaces solve many of the problems that the author creates. In some cases, the implementations totally defeat their patterns. They contain hard code that flatly contradicts the intended generality of the patterns.

Volume 2 demonstrates that the author does not know the difference between a coding technique and a design patterns. Some of his so-called "design patterns" (under his own name, of course) are mere coding techniques that have been around for years. Assertions are a typical example.

This book may fool less experienced readers. Too bad they will eventually have to unlearn the garbage they pick up here.

This book gets one star only because it is the lowest rating I can give. Mr. Grand, please stop writing! You're only embarrassing yourself. Please do not release your intended third volume while your first two are in such desperate need of rewrites by knowledgeable professionals.

very good as computer books go. i have read reviews that say it is hard to read. well it can force you to think, if that is a problem.

i read the reviews on the second book and am confident that it stinks. but this first one is a good one. It addresses things abstractly, and then gives a nice simple implimentation. in my experience, there are not alot of people who can both think abstractly, and also are practical programmers. but this author is clearly one of those.

frank

I was very excited about this book when I first got it and quickly scanned through it. When I sat down to try and implement some of the patterns, I found flaws in the code that comes with the book, shoddy written examples and poor explanations. This book could have been much more, but has turned out to be a half-assed, rushed implementation.

Others have said it all. Flawed; just plain flawed. Pattern implementations that are wrong (some of which undo the value of the pattern itself!) inconsistent explanations of the patterns, poor code examples and more.

An attempt to "port" GoF but the author shows that he really doesn't fully understand and appreciate the originals, nor Java and what it offers, to port properly and put it all in the Java context.

The value you can get out of this is to look at all those who rate the book highly and put them on your hiring blacklist.

The new two book series tries to have more patterns and tie them all to Java. One advantage to this approach is that some patterns make sense in Java that do not make sense in other OO language. Apparently from reading Volume 2, it appears that a Volume 3 is planned.

An odd thing about this series is that the first three chapters are the same in both books. I wish they were in Volume 1 only to save me some money, shelf space and to save trees.

It is true that the books gives you a large library of patterns. However, it has been discussed between myself and others that some of the patterns are not really patterns at all. For example, the so-called "Testing Patterns" have been around forever and are methodologies not Patterns. Also, they are not related to Java in any way.

The explanations in this book in no way compare to the explanations found in GoF. The descriptions of patterns in GoF were pretty consistent in understandability. "Patterns in Java" was a real mixed bag. Some patterns had wonderful explanations. Others did not make sense to me even after repeated readings. Most were just okay though.

Many of the code examples seem overly complex to me. Instead of just showing the patterns in isolation, the examples tend try to do something else which masks the patterns itself. Also, I saw some bugs in some of the code and others have told me the same. For example, the singleton code examples claims "If you play all audio clips through the AudioClipManager object, there will never be more than one audio clip playing at the same time." However, from looking at the code, I see a race condition that is not handled.

In summary, if the book was executed properly, it would be incredibly useful to all Java programmers. However, the implementation is very flawed. It is still marginally useful in that it documents a lot of patterns that GoF does not. A second edition, which focused on improving explanations and code examples, is needed to make these books really good.

When I saw this book at Borders bookstore I consulted it rapidly and I bought it immediately. Patterns, Java and UML: what's more than this? After various reading, I and other five software developers of my company are still reading and translating in Java the C++ examples of Go4 Design Pattern. Unfortunately (for us) your book rest in peace on the bookshelf....:-(( We tried various times implementing patterns throughout this book but we was confused by your explanations: It's impossible understand the essence and needings of those patterns and their use. We tried looking at the code examples shipped with the book but results was worst than before... Did you notice that your example of STATE pattern uses more switch and variables than the Procedural examples ? Why I need an ABSTRACT FACTORY if I use a constant for my factory method ? I was very disappointed to find simply: not -working code examples. How do you think I can use a code without running it, I mean your examples doesn't have a main() method !!! In all the patterns examples source code there is no trace about a possible simple client or user class of them. We spent one hour trying to run Your STATE pattern. Where is a stupid Dialog box that use the DirtyState class ? I mean stupid, simple and little class, but with the correct call sequence of methods. Have you never thought that someone that take your CD and goes on the source code examples , does that because he didn't understood the book explanation and he want run a ready to go dummy example. All the examples lacks of "HowTo" concept that is the final target of a book so called catalog.... A more generally mysterious thing to me, is the race toward the last release of every product. Do you used JDK1.2, marvelous inner classes and other stuff because are you concerned about the "obsolescence" of your book ? Go4 Design Pattern is still valid after five years. Now I'm here in USA for some months working in a very large Java project. They uses a JVM JDK 1.1.4 compliant and only AWT not Swing ! I use borland JBuilder for developing process and the latest release of it uses JDK1.1.6 and Swing 1.0.1 Our applications most of the times are installed on RISC machines like IBM AX or DEC Alpha and they support "only" JDK 1.1.7. We have applications installed on 400 PC designed two years ago with only JDK 1.1 and AWT interface: they are still working and they need to be maintained. This is the Industrial standard reality for who works in real projects,not the latest release after one week it come up !!! I don't think we are using Java (only) for colorful applets on our web pages. Instead we are using it for the promise: "Write once run everywhere". I think that customers for a pattern catalog book will be programmers involved in medium large industrial strength applications that are trying to improve their code or solve designing problems.... I don't think using the latest Java features add any values to a "Design Pattern" book. Instead make it less "understandable" from that peoples that (unfortunately, like me) spends much of their time working on real and money consuming projects. I was very upset finding how this book claimed to go so near the target and at the same time missed it in a so badly way, and it's really a shame for everybody.

The beginner will be challenged by myriad inaccuracies, inconsistencies and typos. The veteran will be surprised by the author's inaccurate treatment of the examples he borrows from Go4 ("Design Patterns" / Gamma et al), and will be annoyed by the book's numerous "forward-dependencies" on Volume 2 (still unpublished!). This book fails to live up to its potential as a new catalog of design patterns, because of the author's lack of mastery both of the essence of those patterns and of their clear presentation. Having said that, the author should be praised for his ground-breaking attempt to present a comprehensive introductory book combining design patterns, java, and uml.

Because I'm a Java programmer and think UML is cool, I chose this book over GoF, and I was disappointed. The writing style is bland, the examples aren't so useful, and it's not always easy to find the pattern you're looking for.

I purchased this book a week ago since I had to study for a test on Java design and patterns for a company interview. After taking the exam, I got exactly what I was looking for--I passed the exam. I can honestly claim that this book has contributed in making me a better Java developer through the use of patterns.

X and Y reviewed the "Patterns in Java" book from Mark Grand as a potential candidate for our next patterns study cycle, and we came to the conclusion that it was not an appropriate material for the following reasons: - Despite claiming to be an illustration of the GoF patterns, some fundamental mistakes have been made in both the commentaries and the java examples. - The essence of the patterns are not mastered by the author. - The examples are not typical of the patterns, leaving the reader confused - Numerous typos and textual mistakes

In summary, this is neither a good patterns book nor a good java book, and we just wanted to warn you if you ever considered acquiring it.

I'd say that I agree with the author here. It is one thing to say that an author expects to be paid for his book, but it is a totally different thing to say that an author merely tries to GRAB your money. This is a serious, yet probably groundless, accusation. This kind of review can hardly be called objective, and certainly doesn't add any value for would-be buyers in getting a description of the book itself.

Ok, I am an aspiring Java programmer, but I have considerable experience in both programming and development on a number of platforms. I purchased "Patterns in Java" this afternoon, and have been locked into it for 6 or 7 hours. It is fascinating! This is my first exposure to using patterns in system design, and the first tutorial I've read on UML notation. I now "know" UML, but that is almost beside the point. The main thing is I now have a handbook for designing object oriented systems - what a relief! And it uses short, understandable samples of java code, to boot.

I have a shelf full of books on the Java language itself, some good, some pretty rough. But "Patterns" is one of a kind in terms of the combination of subjects it treats (Java, UML, Patterns), as far as I know. It is well thought out and serious, and the subject matter is fascinating and very germane to virtually any modern developer. The prose is a bit terse, but it definitely packs a wallop. Enjoy ;)

Mark Donaghue