Inkwell: Authors and Artists

    
We'd like to welcome Elisabeth and Eric Freeman, authors of _Head
First Design Patterns_, which discusses the use of design patterns in
software development. Design patterns are recurring solutions to
software design problems that appear over and over again in application
development. By analyzing and understanding design patterns,
developers can create reusable solutions.  There are other books that
describe design patterns and their use, but this book is particularly
effective partly because it uses O'Reilly Books' "Head First" approach:
described here: http://headfirst.oreilly.com/.

Elisabeth Freeman is an author, teacher and Java software developer.
She recently completed Head First Design Patterns for O'Reilly, with
Eric Freeman, Kathy Sierra, and Bert Bates. Prior to writing for
O'Reilly, Elisabeth spent four years with the Walt Disney Internet
Group, where she focused on Research and Development and Digital Rights
Management.

Eric Freeman is enjoying taking all the pixie dust from his four years
as a Disney executive and applying it to his passion, computer
science. He recently co-authored Head First Design Patterns for
O'Reilly (and never had so much fun). He previously co-authored
JavaSpaces: Principles, Patterns and Practice. Before Disney, Eric
worked closely with his mentor, David Gelernter, on technology and
startups. Eric holds a Ph.D. from Yale University in Computer Science
and has been honored by an MIT TR100 award, as a top technology
innovator.

John Brewer leads the discussion. John is a veteran programmer who has
worked on projects as diverse a s flight simulators, web browsers, and
CAD. He's been interested in design patterns since the early 90s when
he read an early draft of the "gang of four" Design Patterns book. He's
an active member of the Silicon Valley Patterns Reading Group, which
meets Tuesday nights in Cupertino to discuss various topics related to
design patterns and object-oriented design. He currently works for a
major search engine company, where he's sharing his knowledge of design
patterns and agile development practices. 
  

    
Thanks, Jon.  I'm really looking forward to this discussion, as I had to
learn design patterns the old-fashioned way, so I'm really fascinated by the
approach taken in this new book.

Eric and/or Elisabeth, let's kick things off by talking a little bit about
patterns.  What are design patterns, and why are they important?
  

    
Hi everyone - it's great to be here!

To answer your question John, Design Patterns are "freeze dried
experience."  They are best practices in design that come from the
experience of programmers who have had to solve similar problems over
and over, and created a pattern to capture this experience and suggest
good solutions for common problems.  

One common misconception about patterns is that they are
implementations.  They're not: they are designs that can be implemented
in several different ways.  Some implementations depend on the
language of choice, while others depend on your own specific needs. 
The problems that the patterns are designed to solve are usually quite
general.

Design Patterns are important because they are well thought out
designs that have stood the test of time.  In other words, you don't
have to worry that you're "doing it wrong" - in general, if you have a
problem similar to one the design pattern is designed to solve, you can
be pretty sure you're choosing a good solution by implementing the
design pattern.  

They're also important because, even if you never use a pattern,
understanding a pattern can help you learn and understand good
programming practices.  For instance, many of the so-called "Gang of
Four" patterns, which are the ones we cover in our book, are about
creating loosely coupled designs that can easily adapt to change. 
That's why we also included several key principles in the book, because
they go hand in hand with patterns.
  

    
Beyond the technical details of design patterns there's another really
important aspect: design patterns give us a shared vocabulary for
talking about designs.  To see what this is all about (and using a
"Head First" approach, something I'm sure we'll talk more about) we
start in the book by overhearing two conversations in the local diner:

http://www.cs.yale.edu/homes/freeman/diner.jpg

What’s the difference between these two orders?  Not a thing! They’re
both the same order, except Alice is using twice the number of words
and trying the patience of a grumpy short order cook.   What’s Flo got
that Alice doesn’t?  A shared vocabulary with the short order cook. Not
only is it easier to communicate with the cook, but it gives the cook
less to remember because he’s got all the diner patterns in his head. 
If you think about it, a lot of occupations develop shared
vocabularies.

But, what does this have to do with software?  Well, let's observe
another conversation (also from the book):

http://www.cs.yale.edu/homes/freeman/observer1.jpg

http://www.cs.yale.edu/homes/freeman/observer2.jpg

In the first conversation the developer's description is incomplete,
confusing and time consuming.  If he'd just said "the observer pattern"
(which is a design pattern), he would have been complete, precise and
succinct - the other developers would have known exactly what he was
talking about.

So,  Design Patterns give us a shared vocabulary with other
developers.  Once you’ve got the vocabulary you can more easily
communicate with other developers and inspire those who don’t know
patterns to start learning them.  It also elevates your thinking about
architectures by letting you think at the pattern level, not the nitty
gritty object level.
  

    
Compared to other books on patterns, yours certainly stands out, starting
with the cover itself:

http://www.oreilly.com/catalog/hfdesignpat/

I think I speak for the entire object-oriented design community when I ask,
"Is she seeing anyone?"

Beyond the cover, the inside of the book looks _very_ different from most
computer books.  There are lots of little pictures of people, hands-on
exercises, and "dialogs" between different design patterns.  Could you
describe how the book came to be designed this way, and what it is you're
trying to achieve with the design?
  

    
Yes, Head First books definitely look different!  In fact, it was the
different look of Head First Java, the first book in the series, that
caught our eye, and when we looked inside, we realized just how
different it is.

Some people take a quick look at a Head First book and think, "oh,
they just added some clip art to make it look fun."  In fact, all the
graphics inside Head First are very well thought out and are designed
to contribute to the story we're telling in some way.  The "story" is
really the key; we want reading a Head First book to be interesting,
surprising, fun, even shocking - just like a novel with a real story -
and the reason is that your brain learns much better when you are
feeling some emotion.

Kathy Sierra and Bert Bates designed the Head First format based on
learning theory that shows how important emotion is to learning.  Most
technical books evoke little or no emotion in the reader.  So, when you
are reading a dry technical book, your brain is saying "This is NOT
important!"  It's only when you are feeling an emotion that your brain
really pays attention.

So the idea behind Head First is to make learning easier by getting
you feeling something - surprise, shock, happiness, etc.

Another way that story is important is that your brain pays more
attention when it thinks it's in a conversation.  And that works, even
when you're reading a conversation in a book.  So we include people -
characters - who recur throughout the book, and hopefully you care
about what happens to those characters, and you participate in their
conversations and their story by helping to solve their problems.

The format is also designed to be so varied and interesting so that we
can present material multiple times in different ways to 1) help it
sink in through repetition and 2) address different learning styles. 
Not everyone responds to the same things, so by having different ways
to present the material, it provides more opportunities for learning to
happen.

There's so much to say about the format, I could go on for pages and
pages.  But I'll stop here for now... except to say we are very happy
with our eye-catching cover girl - a group of programmers at
javaranch.com helped pick her for the cover and we think it was a good
choice.  It's hard not to want to see what's inside a technical book
with that kind of cover :-)
  

    
(NOTE: Offsite readers who have questions or comments can send them to
<inkwell-hosts@well.com> to have them added to the conversational thread)
  

    

I've read several chapters so far -- the first 3, in order, and then
I started jumping around to other chapters.  I think this is a great book!

(Some background: I've got several years' experience in Java and now C#,
but this is the first time I ever really delved into design patterns.
For what it's worth, my Java is very rusty -- I haven't looked at Java
in a couple of years -- but my Java rustiness has not made it difficult
to follow the code in the book.  C# is so similar I feel right at home.)

My first question has to do with first impressions.  As in:  What sort
of first impressions do folks tend to have with the Head First
look & feel?  Do folks tend to see the book and go, "Cool, this looks
different,"   or do they tend to see it and go, "What the...?!  Clip art
and beautiful blondes?  This book doesn't look like something I can
take seriously..."  ?  It'd be a shame if some folks just passed the
book by because they didn't get the whole Head First idea, and they
thought the style was just pure frivolity.
  

    
Dave - we've had the entire range of reactions from readers.  Some
people just can't get past the clip art.  There's a review on amazon
that is very negative about this aspect of the book, characterizing it
as "jokes" essentially (although they do say they like the serious
content of the book :-).  Other people love it and respond well to it
and say it helps them learn the material.

Same with the cover.  A reader just emailed me yesterday and asked
about the story behind the cover.  He said that he noticed the book on
the bookshelf and thought "oh no, someone is making some cheesy 'design
patterns for dummys' book and putting a girl on the cover to cater to
the lonely male programmers."  But it was interesting enough to catch
his eye and make him want to look inside, and once he did that he was
hooked.

So, yes, I think we've definitely lost a few readers because they just
don't get the format, but I think we've gained many more who do like
it and end up learning from it.  And the word of mouth seems terrific;
we hear from many readers who end up recommending the book to their
whole team.  
  

    

I remember that when I first got the book and just started skimming,
I was sort of nonplussed by the pictures of random people.   But when
I started reading the book for real, those graphics worked just fine
for me.   So, my impression was that skimming the book was actually
a little counter-productive.   I mean, when I skim a book, I'm trying
to get a quick impression of what the book is like; but I'd never read
anything like a Head First book before, so I had no frame of reference.

A couple of chapters in, I finally realized the thing that had been
semi-bugging me:  I was wondering, subconsciously I think,
"Is this just 'chartjunk'?"  I don't know how well-known that term
is, but basically, chartjunk is a word that graphics expert
Edward Tufte created to describe graphical decorations that have
no real information and no substance.  Like, for example, taking a
pie chart and adding 3-d drop shadows.

So at this point I feel like I'm sitting on a fence.  On the one
hand, I like Tufte's work and I think he's right about a lot of things,
but on the other hand, I've found that the Head First book design
does work, and it works very well, even though Tufte might look at
a lot of the graphics and say "That doesn't add any information"!'

I guess I"m just curious whether the Head First philosophy takes
Tufte's school of thought into account.  Do you think Tufte is just
wrong about chartjunk being bad?  Or do you think the way the Head
First books use graphics is not actually an example of chartjunk?
  

    

p.s.  I should probably add: it's been a long time since I actually
read Tufte's books, so I could easily be taking some of his ideas
out of context...
  

    
Very interesting questions.  My opinion is that the Head First
graphics are not an example of chartjunk.  Here's why.

First, we're not trying to necessarily fit in as much information on a
page as possible.  Tufte's approach is to give someone an entire
picture about some fact or feature in the most clutter-free,
information-rich way, at both the macro and micro level.  Our approach
is to take a page and say, what's the ONE most important thing I'm
trying to say on this page?  We purposely include lots of whitespace to
make the page easier on the eyes (although we don't always succeed). 
And we may even present that idea twice on one page; say, through a
paragraph of text AND through a picture.  It's the SAME idea presented
TWICE.  The reasoning here is that you need reinforcement of the idea,
and you need to see it presented in different ways.

Second, the reason we include people in particular is because the
brain responds SO well to people.  In fact, there is an entire section
of your brain devoted simply to recognizing faces of people and
processing their expressions.  So the reaction of a character, or the
way a character is presenting something hopefully helps your brain
relate to that character because it's a person and not text or not a
chart or not some other kind of graphic.  However, people don't provide
a lot of information, right?  Your brain is relating to the character
on the page, but really that character is not contributing to the
detail of an idea or the data that's on the page.  He or she is simply
there to help you relate to the story.

Of course, we aren't the best designers in the world, so I'm sure our
graphics leave a lot to be desired.  However, they are all there for a
reason... they're not there just to make the page look pretty or to
provide variety.  And they don't accomplish what Tufte likes to
accomplish with his graphis - that is they're not there to provide as
much possible information in one page. 

They're there because the brain responds to visuals, often better than
it does to text (not true for all people, but for many).  As they say,
a picture is worth 1000 words.  So true.  They're there because they
support the story, or because they provide a different perspective on
understanding an idea or a problem, or they help you relate to the
story or to the character, or they help you ask a question that you
were thinking but didn't quite know how to put into words.

I think the big difference between Head First and Tufte is the purpose
of the graphics.  I think we have a quite different purpose in mind.

Hope this answers your question ;-)
  

    
 It's interesting that the books are perceived as gimmicky or trivial.

 I wrote a few computer books myself, and the first thing I thought
when I saw books from the Head First series was that they must be
awfully expensivve and time consuming to produce.  Writing a computer
book (or any book) is hard, period, but probably the easiest approach
has to be coming up with programming examples and writing up how they
work.

 Coming up with a book that explains so much by way of graphics and
indeed uses as little text as these books do is an amazing challenge. 

 I had been wanting to read a Head First book to judge how well they
teach, but the first couple were already on topics I know well, so I
didn't bother.  I had been meaning to read the original Design
Patterns book for some time, and when the opportunity came to read
this book I was really excited -- it's on a topic I was very intersted
in and I was also interested in assessing how well these books worked.

 I'm extremely impressed.  I don't learn really well by reading books,
generally I'm better served by hacking around with examples and going
to the documentation as needed.  This book has been very effective for
me though, and entertaining as well.

 I don't have any questions yet, but I wanted to check in and say how
much I appreciate your work.  
  

    

Speaking of the challenges of writing a Head First book, I was
wondering:   Is this book going to be translated into other languages,
and if so, then does the Head First design make it more difficult
to translate?  Something tells me that the humor and the artwork
would give translators fits.
  

    
I wanted to chime in and say that I haven't gotten far in the book (rusty 
java and things take time for me to work out), but I love the way that 
concepts are approached from several directions at once (my description of 
the head first approach), which really helps my conceptualization. I'm 
very tempted to pick up head first java as a refresher and to work both 
together.
  

    
Rafe - thanks! and I'm glad to hear the book is working for you.

Dave - other Head First titles have been translated into other
languages, so I'm assuming that Head First Design Patterns will be too.
 Unfortunately (or fortunately?) we don't have anything to do with
that so we don't really know what the process is.  I imagine that it is
tricky to get right!  I wish I was fluent in another language so I
could "get" the humor on both sides and see if it translated well.
Kathy and Bert have had good feedback from readers around the world;
they expected the whole 50's thing to be lost on a lot of non-US
readers, but in fact, non-US readers love that!

Ari - your description of the Head First approach is great :-)  That's
exactly our intention.   I think Head First Java would be a great
companion to Head First Design Patterns.
  

    

I have a question about design patterns which hasn't been answered
by the book (at least not yet, but I've been jumping around...):
Just how closely does an implementation have to follow the recipe
for it to be considered to "follow" that pattern?  I mean, if my
code basically implements what I think of as MVC, but in some ways
my implementation is a little non-standard, then is it appropriate
for me to say "my app uses MVC to associate the GUI elements with
their business logic" ?

The book isn't right in front of me, so this is from memory, but:
In the MVC section, I think the example had the View object having
a reference to the object that represented business logic.
In an app that I'm working on, I didn't code things that way;
my GUI objects are totally generic (i.e. toolbar buttons, menu items,
etc.).   My controller object knows about the the "model" class
that has the business logic, but my GUI object does not.
So in that regard my implementation is different than the
implementation example in the book.  So, would my implementation
still be considered an MVC implementation?   And more generally,
just how closely do you have to follow a design pattern's details
to say that you're using that pattern?

(I think that in the Q&A part of the MVC section you actually address
this question, a little bit; if memory serves, you talk about how
a scenario like mine, where the GUI doesn't know about the business
logic/model, the controller is actually a mediator.  But I'm still
unclear on whether that means my design is or isn't really "MVC".)

If this kind of question isn't appropriate for this forum, just
let me know -- I could understand if folks want to keep the focus
on the book and/or on Head First!
  

    
>Just how closely does an implementation have to follow the recipe
>for it to be considered to "follow" that pattern?

In the domain of practical software development, this is one of the
infinite number of wrong questions to ask yourself or your team.
  

    

Whether it's a "wrong question" depends entirely on one's reason
for asking the question.  I'm not suggesting that I will change my
implementation if it turns out that what I have is not "standard MVC"
or what not.   I'm asking because of documentation issues, really.
In documentation and training materials, it might be nice to
mention to the reader that this part of the public API is implemented
using the MVC pattern;  but if my implementation isn't really MVC
then I would refrain from saying that in my API docs.
  

    
I was just walking through the local computer bookstore and counted a 
handful of new design patterns books for Java. It's like something that 
has been bubbling for years has suddenly reached some odd and welcome 
critical mass. I do remember (and think I still have somewhere) the 
Software Design Patterns books that Coplien and others did for 
Addison-Wesley a decade ago - yes Pattern Languages of Program Design, by 
Coplien and Schmidt, soon followed by several other volumes. Still over my 
head, but also one of the reasons I stay fascinated by programming.
  

    
 In the book, there are several "in the wild" examples of
implementations that follow the pattern in spirit and still count, I'm
thinking specifically of the way Java's Arrays.sort() is considered an
implementation of Template Method, but does not follow it to the
letter.
  

    
Dave - I think it's an excellent question because you're right - you
may not want to document your solution as being a certain pattern if
you deviate from the design in a big way.  It might give other people
trying to understand your design the wrong impression about how you
implemented it.  However, that said, I also think that there are a
number of varieties and ways to implement most patterns, so if your
design follows the "spirit" of the pattern, then I think you're safe in
documenting it that way.  Rafe brings up a perfect example of where we
suggest that a solution is implemented in the spirit of a pattern (the
Arrays.sort() method) but doesn't follow the pattern exactly (and in
the case, is actually quite different).

Obviously, as Uncle Jax points out, you don't want to follow a pattern
to the letter just for the sake of following the pattern.  Use the
pattern as a guideline to your design and then tweak for your needs. 
Use the pattern name to document your design only if it will help you
discuss your application design with your teammates and other people
trying to understand it.


 
  

    
As that great pioneer of systems design, Jesus of Nazareth, pointed
out, "The Law was made for man, and not man for the Law." :-)
  

    

It's excellent timing, me getting this book recently, as I've been
wanting to learn about design patterns.  Actually, for a couple of
years now I've been telling myself I should learn design patterns,
so that's nothing new.  But lately it has seemed more urgent.
These days it's not unusual to see design patterns referenced
in specs that I see from other developers.

So basically, it seems like a familiarity with design patterns
is no longer something you might learn if you have time; it seems
like something every serious developer needs to be familiar with.
At least that's the feeling I get at my office.  So I'm curious:
is that the sentiment throughout the industry?  Does every CS
grad these days already know design patterns?  (I'm just curious
about how far behind the curve I am!)
  

    
 I worked with some guys on a contract a few months ago who did
nothing but make fun of design patterns.  I wasn't sure exactly where
the animosity came from.
  

    
Dave - I don't think you're behind the curve at all.  From what we
have seen, Universities are only just now starting to teach serious OO
design and design patterns.  Most people right out of school still
don't know design patterns; many still don't even know the basic OO
principles.  But I think it's starting to change slowly.  We have heard
from a few teachers who want to use Head First Design Patterns in the
classroom.

I think it certainly helps to know design patterns, especially if
members of your team know design patterns - then you can understand the
references!  But again, I think primarily design patterns are good as
part of an overall understanding of OO design.  

I can see where people might make "fun" of design patterns if their
experience has been with someone who perhaps forced design patterns
into designs, rather than looking to design patterns for guidance
regarding certain problems and solutions.  Some people have gone
overboard in their love for design patterns!  Our philosophy is
definitely "Keep It Simple".  Added complexity is a tradeoff with some
design patterns, and we don't advocate using a pattern unless the
tradeoff is worth it.