Slashdot Mirror
Applied Java Patterns
Check your sources.
The title is published by Sun Microsystems Press, and the two authors are instructors for Sun Microsystems. As you would expect, this means you won't find any discussion of Java's darker corners; this isn't a particularly damning criticism in a book about Design Patterns, but it does mean that, for example, you won't see discussion on why double-checked locking implementations of the Singleton pattern don't work. (I might be reading more authorial/editorial bias into this than was intended of course -- I'm a bit paranoid. Too much caffeine, I expect.)
What's the book about?
From the blurb:
"[...] After briefly reviewing the fundamentals of design patterns, the authors describe how they can be applied effectively to the Java platform and present proven techniques for all types of patterns, from system architecture to single classes. Next, they present a pattern catalog."
In other words, what we get is an adequate intro, followed by about 275 pages of pattern catalog (mostly from Gamma et al, with a few threaded items from Doug Lea's Concurrent Programming in Java). This is what you're buying the book for, and on the whole it's decent material.
It continues:
"In addition, they identify patterns in the core Java APIs and present techniques for pattern use in distributed development. [this title] also features a section on pattern use in systems built with J2EE and Jini technology and coverage of the servlet, JSP, and EJB APIs."
Just about! This entire section is very much secondary to the catalog. The core Java APIs discussion is about 20 pages, the distributed section about a dozen, and the rest only 15! I've seen as much discussion of the pattern usage in the JDK in asides in, for example, Bloch's Effective Java (an excellent book by the way).
Of much more interest are the appendices. In reverse order -- Appendix B is a welcome bibliography. Appendix A is an odd decision on the part of the publisher. Appendix A is "Full Code Examples." Normally I'd think that this is a good thing, but appendix A is 224 pages, as compared to 273 for the whole pattern catalog. I feel it would have been better delivered on a CD. I realise this adds, what? $5?, to the cover cost, but the book would have been substantially thinner, with a knock-on effect on price.
A more important consideration is that this appendix distracts from the catalog, and adds little (other than working framing code) to the discussion of the patterns.
Target audience?
Experienced Java developers - but ones who haven't been exposed to Design Patterns before. I doubted that this was a huge audience, but then realised that Java is often used as a teaching language now, and I may be wrong in assuming most graduate programmers would be comfortable with the C++ and Smalltalk examples in Gamma et al. I could see this being a useful niche title for those mono-linguists starting out their professional careers.
What's good?
Overall, this isn't a bad title. It's decently written on the whole, has passable explanations of the main Patterns, and is presented clearly. It's just that there's nothing superb about it, and the problems (below) offset the overall competent tone. (It's a weird book to review: the majority of the content isn't original, and as a repackaging exercise I can't comment on, say, how brilliant it is to have a name of the Factory concept at long last.)
What's bad?
Too much for a simple port of GoF to Java. Let's start with the obvious flaws and then move onto "missed opportunities":
- Diagrams
Sorry, but there is no way that the UML diagrams in this title are acceptable in a professional publication. They're woeful, jagged-edged screen-capture affairs. - Appendix A
As discussed above, the book has a schizophrenic feel with a LOT of material relegated to, or repeated in, Appendix A. A much more useful approach would have been to provide more material on the applicability of each pattern, or to flesh out some of the alternative implementations discussed. - The example application
This title tries to do something laudable, but ill-thought out. What they do is start to discuss an example application (the Personal Information Manager) in the first pattern, and then carry that example through to all the other examples. This isn't a bad idea, but think about it. How do you use your pattern books? I flick through mine. I pull it off the shelf and read one pattern, or pass it to a colleague saying, "You want to change that to a [whatever]."When reading this title my flatmate was struggling with some OO design homework -- flicking to the pattern under discussion (Composite) starts us into another discussion of the PIM! This isn't what I want and puts me off the title immediately as I feel like I'm missing some background. The examples need to be more standalone. (To be fair, this only affects the blurb text, the code is independent.)
- Oh editor, where art thou?
While talking over the Composite pattern with my confused flat-mate, I noted that the Deliverable snippet actually gives the code for the ProjectItem again (page 163). Sadly, it's also wrong in Appendix A. On the full read-through this type of simple proof-reading error occurred too often. - Oh code reviewer, where art thou?
Here's a hint for publishers. When writing a book for a professional audience which necessarily thrives on pedantry, try and have examples peer-reviewed first. Much of the code in Appendix A is not great. Now, I realise we're developing educational examples here, and we want to keep the focus on the pattern, but the impression given by the full code examples isn't good. Continuing the above example, the error handling of the Composite pattern is feeble. (Static ints defined in an exception class and then if-elsed on the main class to get printable versions? Yeugh.) I'm being picky here, but this is a book about better design, and people-in-glass-houses, etc. In addition, the core concepts aren't original, and so it's this (slightly sub-standard) example code which gives the added value, or rather, should. - Fly-leaves
You know what I love most about Design Patterns? The fly-leaves -- to find a pattern I open the cover, skim the list and turn to appropriate page. Brilliant for a reference title. Applied Java Patterns misses a simple trick here. A hardcover edition would also be nice. As would those nice GoF ribbons. (My apologies if there is a softcover version of the GoF book featuring neither fly-leaves nor ribbons and I've been comparing apples to oranges.)
So, overall the impression that this book gave me was of an opportunity missed. Too many little details wrong, or lacking when compared to the GoF title.
Alternate titles?
There is another Java Design Patterns title: Addison-Wesley's Java Design Patterns -- A Tutorial, by James W. Cooper (2000, ISBN 0-201-48539-7). I can't say I recommend this title either -- it's much thinner, comes with a CD, takes a more tutorial tone, but suffers many of the same flaws (sloppy editing, lack of 'flickability,' chunks of dodgy code and some bloody examples).
Sorry, but the undisputed king still reigns -- the original GoF book is still superior in almost all respects. Only a lack of recent examples, and the fact that the examples are only in C++ and Smalltalk can be called criticisms. (Details: Design Patterns: Elements of Re-usable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Addison-Wesley, 1995, ISBN 0-201-63361-2)
If you feel that the GoF book is a bit, well, academic and intimidating for your taste then might I suggest a side order of John Vlissides's companion volume, Pattern Hatching: Design Patterns Applied (1998, ISBN 0-201-43293-5). This slim volume talks about applying patterns -- where, how, etc -- in a clear way, using a tutorial approach. The example system developed helped me "get" some of the concepts first time through. The examples are in C++.
I don't want to give the idea that there are no new Design Pattern books worth reading - for example, for J2EE work I think highly of Core J2EE Patterns by Deepak Alur, John Crupi, and Dan Malks (2001, Prentice-Hall, ISBN 0-13-066586-X).
So, to sum up, this isn't a bad book, but it does feel like a pale imitation of the GoF title, and offers very little to anyone who develops in Java but has access to the GoF book. Any publishers or wannabe authors listening? Seems like now might be a good time to think about issuing The Design Patterns Java Companion, along the lines of the existing Smalltalk title. (Hmm, maybe I should take my own advice ...)
You can purchase Applied Java Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Bruce Eckel has a book
Thinking In Patterns
How does this book compare to that?
S
Very Interesting.
My experience is that Java is great for learning to program in OO, because it adheres more cleanly to modern ideas about OO-programming.
Implementing an interface for example is a different thing in Java from extending a class, where in C++ both things are done with inheritance. This makes for a more clean seperation of ideas.
Also, when you look at the Java API, patterns are virtually everywhere (look at the Java Collection Framework to see what I mean).
That being said I would to add that though Java is a great choice for teaching, I'm still not very much convinced about it's merits in normal software development, especially when it comes to building GUI applications...
PageTurner Reader: open-source e-reader for Android with cloudsync. http://pageturner-reader.org
Java Companion is a free (PDF) download of a good treatment on the subject. As a practicising java developer there's no substitute for the GoF Design Patterns especially the discussion on each pattern. But sometimes it's hard to gather the full meaning because a C++ demonstration is used replete with multiple inheritance or even just inheritance that may be realised in Java as composition. With Java, one requires little bit help, some lateral thinking to come up with an equivalent. The download has helped me immensely.
Design patterns describe some common code design problems, give a solution to it and analyzes the problem and the solution. So in short when you are facing a structural design problem (like "how should all my GUI widgets interact in the GUI toolkit I am writing"), you might wanna check these out.
Usually programmers "use these" without even knowing them (after all, they are common solutions to common problems).
Here is a FAQ.
Patterns are named solutions to problems, which resolve constraints in a a given context. They aren't rigid (like, say, a template), they are abstractions of commonly occuring problems and solutions that occur in programming. For instance, "one object needs to do something to another group of objects" might be a problem, and the Visitor pattern might help you find the solution. The code you use to implement the pattern might be radically different than the code someone else uses, but underneath the pattern is the same.
They come from Christopher Alexander's work in architecture, where he saw the same recurring patterns in architecture and felt that they arose from deeper truths about people and societies. An example of Alexander's architectural patterns: "Intimacy Gradient", which is a pattern that describes how the front of a home is less personal and intimate than the back of a home. For instance you might leave your stuff laying out in a back room, but you keep the front room neat for guests.
Very interesting from a philosophical point of view as well, and helps you to better understand why some programs/houses/objects are pleasant to work with, and others are a chore.