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
(on behalf of Eric, Beth, and Bert)
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.
It lacks brain-friendliness, and of course it only applies to the core J2EE patterns, not the GoF or other patterns.
Good Luck to HF team! It really rocks.
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.
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.
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.
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.
* a similar book does exist in Martin Fowler series and it requires separate book.
[ November 04, 2004: Message edited by: Axel Janssen ]
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.
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
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.
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.
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.
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!