What do you want in a design patterns reference?

[Kathy Sierra]

Howdy all,
We finished the HF Design Patterns book, which is an in-depth *learning* book on the main GoF patterns, but people have been asking for a companion book that is more of a reference/catalog (but in the Head First style). So, we're thinking about doing a smaller, 300 pages handbook/almanac/catalog (don't know what to call it) that will have about 50 patterns including all of the GoF patterns, all Core J2EE patterns, and some others.

We'd REALLY like to know what you like/dislike about patterns catalogs (again, we're not talking about in-depth teaching of the patterns from the ground-up -- we're talking about maybe 3-8 pages per pattern at most).

If you could have the ideal patterns reference book, what would it look like? What aspects of the pattern would you want to see? Code? Class diagrams for both the pattern *and* an implementation example? Examples/stories of when to use it?

As always, we'll be happy to give a few books away to people who give us some good ideas (no formal contest, but we're always willing to send some books out, and the big design patterns book is coming out in a week or so, and we might be tempted to give a few out to folks who help us out here in this discussion

cheers,
Kathy
(on behalf of Eric, Beth, and Bert)

[Edwin Keeton]

I'm intrigued by the "medical reference" idea. It would be interesting to codify symptoms of "diseased" code other than by "code smell". OTOH, I suspect it would require more than just a few pages per pattern.

For a catalog/reference approach, I would ideally like to see class diagrams, (including alternative implementations), sequence diagrams, simple code examples, and some discussion and examples of appropriate and typical situations for using the pattern. At another level, what I want is a way to recognize a design pattern out of either whatever mess I've already created, or from the problem I'm trying to solve. (And hopefully it will usually be the latter.) And I think there needs to be some discussion of alternative implementations of various patterns. After I have recognized that I need to use the Locomotion design pattern to go to the grocery store two blocks away, I also want to know that I don't always need to implement Airplane, but I can also use Walk, DriveCar, or RideBicycle.

[Edwin Keeton]

Thinking about it some more, theJ2EE Patterns Catalog has about the right level of information, diagrams, code examples, alternatives, etc.

It lacks brain-friendliness, and of course it only applies to the core J2EE patterns, not the GoF or other patterns.

[Jason Hocker]

lots of boring text only confuses me... what I need are pictures or "fun" text to help. And examples are good. But choose not so obvious examples. Picking something obvious does not help me being creative to see where else I could apply the pattern.

[Sri Ram]

Kathy when you go for examples, please have only one application and try to use all patterens if possible ... and pictures along with "fun" text to help. I really like your HF Brain friendly concept .. it helped me to get 96% on SCBCD. I was 100% sure that I answered 67 questions correct before I clicked on the FINISH button .. I never felt like this before in any of my certifications.. looking foward to see HF Design Patterns.

Good Luck to HF team! It really rocks.

Vanniarajan PMP
SCJP
SCBCD

[Pardha Akalamkam]

Kathy
Since it's a reference book to the design patterns, I would like the following to be included.

1. It should give a detailed example for each design pattern along with class diagrams.
2. Also it should separate the usage of design patterns based on the tier they are used (business, database , domain tier etc).
3. How an existing design pattern can be modified or updated to meet the latest requirements (like changing from EJB 1.1 to EJB 2.0 and to EJB 3.0).
4. The detailed working example of any application that uses many patterns at different interfaces.

Pardha
SCJP,SCBCD,SCWCD

[Nicholas Cheung]

Kathy,

I wanna to have a Core J2EE patterns, preferably that a small but enough simple application be described based on SCEA part II. Thus, we can both learn the patterns, while we can have a references for SCEA.

Sounds good?

Nick

[angelo celeste]

Hi Kathy.
The biggest frustration that I find in reading "technical" books is that they are inconsistent with the examples they use.
For example they start out discussing animals and compare it to a banking example

Please understand that I can only imagine the hard work that goes into writing books and my hat's off to all of the authors out there.

What would be benificial would be that the examples be consistent so that there would be an oranges to oranges comparison not oranges and tellers

Looking forward to the deivery of my Heads First Design Patterns book.

Best Regards,
Angelo

[Axel Janssen]

I think that bad_smell_examples does clearly not fit in a short pattern reference. This would fit more in a HF Pattern 2 book (Refactoring to patterns)*. Just some patterns, when to apply it, uml-diagrams and simple code.
To further nitpicking about posts so far (sorry):
For my taste, there doesn't need to be an 1-application-where-all-patterns fit approach. Examples should be as simple as possible, especially if its directed to people without too much experience.
To mention lots of scenarios (or examples from java packages) where to apply the pattern would make sense.

Axel

* a similar book does exist in Martin Fowler series and it requires separate book.
[ November 04, 2004: Message edited by: Axel Janssen ]

[Axel Janssen]

To highlight one point once more:
I think that one side efect of having tried to put in ones brain patterns is that it simplifies/fosters understanding of java.* apis.
So notes about when specific pattern is used in specific java api might be usefull. I am currently reading Pankaj Kumars good "J2EE Security"-book and java.security.* is full of patterns (though author doesn't refer to).
In a pattern book it might deepen understanding, if people know that such and that pattern is used in this or that api, or even famous open source package.

Axel

[Axel Janssen]

Originally posted by Gian Franco Casula:

Summing up existing frameworks
as comparison material would, in my eyes, require
some a priori knowledge of them, and explaining
the workings of api's would take some lengthy
wordings as well, with the risk not being
appealing if too specifically focussed to some
api.

Gian,

I do a agree with you. There is certainly a danger to get lost in explanations. I just meant that a few hints , where people might look up for real world implementation. There are a lot.

Patterns as such I see as a more static approach, whereas Refactoring is dynamic (to get from bad design to much better design).
It might be simpler for not that experienced people to first learn about good design and then how to do refactoring.
Refactoring should be work book style.
If you allready have read something about Design Patterns, it might be simpler to grasp refactoring, because you know where refactoring is heading too.

Axel

[Jayesh Lalwani]

For reference book on patterns, I would love to see a section that describes the drawbacks of a particular pattern. Yes, I said *drawbacks*. When most people start using patterns, they usually end up using the wrong pattern at the wrong place.

[Madhu Kumar Vatts]

I am looking for a design patterns book with these features

1. Contains Java code to test the design pattern and understand how it works
2. Applicability, Where is it good to be applied?
3. A small graphical representation of the applicability with an example
4. A small game in which each design pattern fight each other and convey that I will be the best to do this ..so u back off..(I believe if I can understand where it can applied, than rest of it is easier of how to write the code)

Thanks kathy for all the books and I admire your work.

Thank you,
Madhu

[Jason Hocker]

Keeping the the HF mold and to add to a previous post...

what if its a companion, and notes from reading the big book. But not just notes. Of course there would be bulleted lists of notes and such, but what if the notetaker put down more thoughts, like which peers/projects she should talk to at her company to introduce it. And her notes wouldn't just be what project and what design, but why she needs to tell them about the design pattern.

[Aneesha Singh]

Hi there,

Besides applicability and the like, while reading the GoF patterns most times, I keep thinking that some of them are so alike and if some comparisons between the patterns are given (when to use which, etc .. scenarios, differences, similarities ), it would be great ...
I like the HF representation anyway .. helps to remember things better !!

Thanks for the great books you've done previously!! Really helped!

Aneesha