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.
The original "Design Patterns - Elements of Reusable Object Oriented Software" is absolutely definitely the best book to describe design patterns. Ok so it has some C++ code, but if you are a Java coder worth your salt, you should be able to follow it to some extent.
The main point is that design patterns are supposed to be language neutral! Most of the "Design Patterns in XXX" books pretty much break the idea, as they tie a pattern in to an implementation. The pattern of course is a collection of; pattern name, problem, solution, consequences, and not just some code.
My point is that some of these books are great, and some are poor. But the original really is the only one to give you the real feeling of the patterns philosophy.
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).
Propoganda
Design Patterns in Dynamic Programming
"Design Patterns" Aren't (google cache link)
GOF-style patterns get carried away with "using code to model your nouns". I find using relational techniques and tables superior because they do not depend on the physical structure of code (beyond relational formulas), but rather use as-needed "virtual patterns". It is like the differences between doing calculus by counting rectangle approximations under the curve and diriving dirivatives via formula transformation. GOF is a bunch of rectangles hand-weaved together in my viewpoint; a bunch of classes hand-indexed together the old-fashioned way. I would rather let the database engine and compact formulas do most of the weaving for me.
In procedural/relational design, the programming code is less tied to the "noun-model". Thus if you want to change the noun model or have multiple simultaneous noun models in play, the code does not need large-scale overhauls in its structure. This makes p/r more change-friendly IMO, and most software expenses are on maintenance, not creation.
If you tie your code tightly to noun models, like GOF and OOP tend to do, then your code needs more rework if you change your noun model/relations. Pretty simple.
Paul Graham has made similar comments about patterns, although he uses relational's cousin: functional programming and set theory, to do similar "virtualizing". (In essence, he uses relational-like formulas in LISP.)
More reading on my opinion of GOF-style patterns:
http://geocities.com/tablizer/prpats.htm
http://geocities.com/tablizer/whypr.htm
What we have in this slashdot story is TWO overhyped techologies: Java and GOF-like patterns. A 2-for-1 bargain. PHB's and fad chasers will love it.
Table-ized A.I.
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.
Don't mean for this to be the flame you expected, I'd just like to give the other side of the argument.
:)
> Near as I can tell, design patterns are to
> programming what paint-by-numbers is to art.
I can see how this comparison would occur to someone with little experience using Design Patterns. I think a better explanation is this:
Most anyone can, given a programming problem, come up with a solution that works. If you're working on a quick and dirty piece of code for one-time use, then using patterns might not be the answer. However, its very common that people want to add new features... support new file formats, etc. Most quick and dirty designs, even by good programmers start looking really bad when new features are added. If the system grows significantly larger than the original developer expected then the design becomes completely unwieldy and they start to see how it should have been designed in the first place. The next time that developer has to design a similiar piece of software they wont make the same mistakes.
This is where Design Patterns come in. A designer/programmer well versed in these patterns can see the end result of that first scenario before it happens. Learning design patterns helps teach good design faster. The solution to each common design problem is encapsulated in a well documented pattern.
> I haven't met a gifted programmer who made
> extensive use of them,
Wow, I've met alot of people who think they are gifted programmers and write really badly designed code that works (at first) who don't use design patterns.
On the other hand, if you judge code and design not by how much of a hack it is, but by how elegant it is, then Design patterns can make a huge difference. There is nothing beautiful about trying to cram a square peg in a round hole, even when it works.
So, instead of "paint-by-numbers", I see design patterns as a "magic eight ball" that can tell you what problems your design will have before you even start programming.
> but they seem to be a sort of helpful template
> for average coders of the sort hired in legion
> strength for "enterprise" projects in Java and
> the like.
While I am a fairly technical c++ programmer by trade, there is no reason to belittle java or "enterprise" programmers. There are some HUGE projects out there that simply cannot by done right by a few people hacking away. And I feel sorry for them when it becomes time for V2.
...between software engineers and mere coders.
--
CPAN rules. - Guido van Rossum
The basic idea is that certain problems arise frequently in designing code, and often people come up with very similar designs to implement the solutions. This gives rise to two ideas.
A design pattern is simply a named, streamlined solution to a common problem.
Many people, not least Gamma et al. in their book Design Patterns (Addison-Wesley, 1995, IIRC), suggest that if you find the same sort of idiom solving similar problems in two or three different places, then it's likely to be worth looking for the underlying common idea behind those solutions, streamlining and naming it, and thus producing a new design pattern. Some design patterns are quite general and occur in many OO designs in diverse fields, and others occur frequently in a particular field but are irrelevant elsewhere.
Design patterns are basically useful in two ways.
The final important thing to remember is that design patterns are never a goal in themselves. Code is not good just because it follows patterns or bad just because it doesn't. The benefit of patterns is simply that they make it easier to do what you might have done anyway, but probably with less effort, more confidence and better results.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.