Inkwell Host (jonl) Wed 9 Feb 05 06:57
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.
John Brewer (jbrewer) Wed 9 Feb 05 10:23
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?
Elisabeth Freeman (bethfreeman) Wed 9 Feb 05 11:02
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.
Eric Freeman (eric-freeman) Thu 10 Feb 05 08:59
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 Whats the difference between these two orders? Not a thing! Theyre both the same order, except Alice is using twice the number of words and trying the patience of a grumpy short order cook. Whats Flo got that Alice doesnt? 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 hes 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 youve got the vocabulary you can more easily communicate with other developers and inspire those who dont 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.
John Brewer (jbrewer) Thu 10 Feb 05 16:47
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?
Elisabeth Freeman (bethfreeman) Thu 10 Feb 05 20:44
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 :-)
Cynthia Dyer-Bennet (cdb) Fri 11 Feb 05 14:28
(NOTE: Offsite readers who have questions or comments can send them to <email@example.com> to have them added to the conversational thread)
Dave (drsmith) Fri 11 Feb 05 14:51
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.
Elisabeth Freeman (bethfreeman) Fri 11 Feb 05 15:19
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.
Dave (drsmith) Sat 12 Feb 05 12:34
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?
Dave (drsmith) Sat 12 Feb 05 12:38
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...
Elisabeth Freeman (bethfreeman) Sat 12 Feb 05 14:28
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 ;-)
Rafe Colburn (rafeco) Sat 12 Feb 05 18:08
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.
Dave (drsmith) Sun 13 Feb 05 10:57
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.
Ari Davidow (ari) Sun 13 Feb 05 19:49
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.
Elisabeth Freeman (bethfreeman) Mon 14 Feb 05 06:41
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.
Dave (drsmith) Mon 14 Feb 05 08:30
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!
Uncle Jax (jax) Mon 14 Feb 05 09:19
>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.
Dave (drsmith) Mon 14 Feb 05 10:46
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.
Ari Davidow (ari) Mon 14 Feb 05 10:52
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.
Rafe Colburn (rafeco) Mon 14 Feb 05 11:46
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.
Elisabeth Freeman (bethfreeman) Mon 14 Feb 05 12:22
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.
Uncle Jax (jax) Mon 14 Feb 05 13:19
As that great pioneer of systems design, Jesus of Nazareth, pointed out, "The Law was made for man, and not man for the Law." :-)
Dave (drsmith) Tue 15 Feb 05 09:31
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!)
Rafe Colburn (rafeco) Tue 15 Feb 05 12:47
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.
Elisabeth Freeman (bethfreeman) Tue 15 Feb 05 14:23
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.
Members: Enter the conference to participate