Fog Creek Software
Discussion Board




Book on Design Patterns

I am thinking about to get the following book on Design patterns:

Design Patterns
by Erich Gamma (Author), Richard Helm (Author), Ralph Johnson (Author), John Vlissides (Author)
ISBN: 0201633612

I am starting to learn java/j2ee - I am  new to design patterns and I am not sure if the above is the best for me.

The review on Amazon were mixed and basically made me more confused on whether to get it or not.

Thanks,

Nik

Nik
Friday, September 19, 2003

It's like asking whether you should accept getting a BJ.

The Big Lewinski
Friday, September 19, 2003

There's a nice plugin for Eclipse to automagically insert design patterns (i.e. the corresponding code framework) into your Java code. Go Google, I remember it being a commercial plugin for a reasonable price.

Johnny Bravo
Friday, September 19, 2003

If you want the BJ from someone else, Bruce Eckel was working on a Thinking in Patterns book done in Java. The free downloadable version can be found at http://www.mindview.net

Nick
Friday, September 19, 2003

Great book.  But I have a problem with a couple patterns.  My biggest gripe is Visitor.  Anyone else hate this pattern?

christopher baus
Friday, September 19, 2003

What about Visitor do you hate?

How else would you solve the same problems?

There are variants on Visitor that get around some of its shortcomings (for example, Acyclic visitor fixes the "add a new subclass, redefine everything" problem).

I don't love the Vistor pattern, but I don't hate it either, and I have made good use of it from time to time.

Chris Tavares
Friday, September 19, 2003

The problem with visitor is it creates dependencies between to otherwise unrelated hierarchies.  Visitor by definition is a hack.  I would bite the bullet re-arch the hierarchies.

christopher baus
Friday, September 19, 2003

I would argue the "completely unrelated" criteria - the whole point of the visitor classes is that they do processing on the element classes.

The big problem I have with Visitor is that it couples the base class of the element hierarchy with it's own subclasses, since the base visitor class has to know about all the possible subclasses of element. There has been a lot of writing about this, for example:

    http://www.objectmentor.com/resources/articles/acv.pdf

for the Acyclic Visitor, which removes this particular wart.

Chris Tavares
Friday, September 19, 2003

I disagree that Visitor creates dependencies. When we use it, it removes tight couplings, not adds them. I honestly couldn't imagine not having a double dispatch mechanism at hand, and it's even doubly useful in a metadata rich environment like Java or .NET, where reflection can prevent you from writing a lot of the grunt code.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, September 19, 2003

I'd recommend GOF/DP as a 2nd or 3rd book.  I'd go with Eckels' "Thinking in Patterns" or something similar first.


Friday, September 19, 2003

If those unrelated hierarchies happen to cross library boundaries, you've just coupled two libraries together.  This can kill compile times when modifying shared headers, and make it impossible to build componets as stand alone entities.  I worked for a large desktop software company.  I was working on a new project that could benefit from functionality from a specific module in a specific product.  Unfortunately that module as dependant on about every other module in the product.  So basically I would have ended up including the entire product in my new system just to use a subset of the functionality.  To my dismay, I ended up cutting and pasting and reimplementing a huge amount of functionality.

That is the type of dependency problems that Visitor can create with the veil of doing the right thing because it is in GoF. 

christopher baus
Friday, September 19, 2003

"If those unrelated hierarchies happen to cross library boundaries, you've just coupled two libraries together.  This can kill compile times when modifying shared headers, and make it impossible to build componets as stand alone entities."

I have to presume you use C++. I have none of those issues doing reflection-based visitors in .NET. There is absolutely no "wiring together" at compile time, except for classes implementing the visitor interface (which can be put off into a separate library).

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, September 19, 2003

Heck, even in C++ it's not an issue. You place the visitor interface in one header file, and the implementations in another. Done. The visitor interface is part of the Element library, not the visitor implementations.

So the visitors are coupled to the elements (as is expected) but not vice versa.

Chris Tavares
Friday, September 19, 2003

Oh, and just to get back on topic:

This book is what finally pushed me over the top into being a decent software designer, not just a programmer.

There's lots of good stuff in there that is well worth reading. Definately recommended.

Chris Tavares
Friday, September 19, 2003

"Design Patterns Explained: A New Perspective On Object Oriented Design" ( http://www.amazon.com/exec/obidos/ASIN/0201715945/qid%3D1064012771/sr%3D11-1/ref%3Dsr%5F11%5F1/104-2337967-3867907 ) is the design patterns book you should get first.

And while you're about it pick up "Expert One on One J2EE Design & Development" ( http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/qid=1064012847/sr=1-1/ref=sr_1_1/104-2337967-3867907?v=glance ).

Walter Rumsby
Friday, September 19, 2003

Yes, Shalloway's book should be good if you're a beginner.

GP
Saturday, September 20, 2003

The Visitor pattern is easier to implement using generic functions (Lisp, Dylan, etc.) or a similar reflection-driven mechanism such as protocol adaptation (Python) or dynamic casts (C++).

Some references:

C++ -- http://citeseer.nj.nec.com/nordberg96variations.html

Python -- http://peak.telecommunity.com/protocol_ref/dispatch-example.html

Phillip J. Eby
Sunday, September 21, 2003

Gamma etc. is a great reference, but trying to read that sucker is.. ugh!


Monday, September 22, 2003

In languages where the object system is based on generic functions (like Common Lisp and Dylan) it's not so much that Visitor is easier as that it's completely unnecessary. Visitor is a workaround for a drawback that languages like Smalltalk and C++ have; languages without that drawback don't need it.

(I don't mean to say: Therefore Common Lisp and Dylan are *better* than Smalltalk and C++. There are tradeoffs. I think it's harder to get such fast code with generic-function-based OO, especially when you throw multiple dispatch into the mix. I happen to prefer the CL/Dylan side of the tradeoff for most purposes, though.)

Gareth McCaughan
Monday, September 22, 2003

Learning by doing is always the best way to learn.

On one of my first large OO projects before I had read the GOF book, I designed and wrote it without reference to patterns. A short while later a very experienced developer challenged me to identify the various patterns that I had re-invented wrt the GOF book. This I did and found maybe five of them, two that spring to mind were Singleton and Facade, but there were others. After that I sat down and read the book properly with renewed enthusiasm.

I agree that reading the book from scratch without reference to some other real code is a bore and is not recommended. The GOF book is good, but its not K&R.

whattimeisiteccles
Monday, September 22, 2003

I hadn't seen the object mentor article before, but it is interesting, because when ended up using dynamic cast to clean up some of the ugliness of the original GoF C++ implementation.  This just revalidates that solution.  I should make it clear that 90% of the work I do is in C++ and the remainder is in Java. 

christopher baus
Monday, September 22, 2003

*  Recent Topics

*  Fog Creek Home