Does the Head First book talk about recognizing patterns in the 'wild?'
I've discussed Design Patterns before in a special interest group and it helps immensely to see the real thing in an application, but I'm still not sure I can recognize a real pattern (other than Iterator, Singleton, Composition and a few others) in the wild when I see it. I also sometimes have a problem differentiating which pattern or group of patterns is at play in a particular solution. For example, in some instances I wasn't sure if I was looking at a Facade, an Adapter, or a Decorator.
Do you also talk about not over-applying patterns? It seems some people get carried away (the shiny new thing mode) and apply patterns where they don't apply and shouldn't apply. Maybe this is the same as the anti-Pattern question previously asked.
�Does the Head First book talk about recognizing patterns in the 'wild?'
We sure hope so
On the one hand, we don't review legacy code, and show you how to pick out patterns. On the other hand, we talk a lot about the how's and why's of the patterns, and the key class relationships that characterize each pattern. The goal is for you to understand why the pattern exists, when it should be used, and how it will look when it is applied.
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Sorry, Sathya, I completely disagree. HFDP is an EXCELLENT first book. I covered design patterns and GoF way back when in college, but it was extremely brief, and well over 8 years ago. I picked this up last night because (1) It was a Head First book and I collect them like Beanie Babies (2) It was a Head First book that I could immediately begin relating to, and I really needed a design pattern refresher course.
I'm on a new job here, some code needs to be refactored but even more code's going to be started completely from scratch. It's in the manufacturing industry. It's important for me to understand these design patterns and fast, I already know how to program. Yes I'll probably go through another DP book later, if I need to. But flipping through this book I already have everything I need to hit the ground running using these patterns in my day job. I work in the "real world", unlike my college days where theory was all the mattered, and rote memorization of facts.
These days I just need to know what I'm looking at, what pattern would work best, and how to fix it. If I can get that in a quick, *FUN*, easy read, then so be it, I'll pick that over anything else off the shelf any day.
Kudos to the "new Gang" on the great new HF book. PLEASE keep em comin! (And for risking being shot on sight here...please get some .NET HF books off the ground soon!)
Does the Head First book talk about recognizing patterns in the 'wild?' ... For example, in some instances I wasn't sure if I was looking at a Facade, an Adapter, or a Decorator.
Do you also talk about not over-applying patterns? It seems some people get carried away (the shiny new thing mode) and apply patterns where they don't apply and shouldn't apply.
You ask some excellent questions! We definitely talk about patterns "in the wild", and show a bunch of examples where you will find patterns in the JDK. Some of these uses match the "classical" use of the pattern quite closely, while others do not - they've been modified to fit the context, situation or purpose, or they implement the spirit of the pattern rather than the original design of the pattern. For example, in the Template Method chapter, you'll see that we show how the Arrays sort() method is an implementation of Template Method, even though it is significantly different from the classic definition of this pattern.
Your question about Decorator, Facade and Adapter is right on - these patterns are *very* similar, and we address this in detail in the book. Sometimes you'll find that the main difference in two patterns is in their *intent* rather than in their implementation. In those cases, having a big picture idea of what the code you're looking at is supposed to be doing will help immensely. For instance, if you know that a class is there to make some interface *easier* to use rather than to *change* it, then you'll know you're dealing with Facade, not Adapter. But if you don't know what it does and you're trying to figure that out, sometimes it might be hard to tell! Another good example of this is State and Strategy - on paper, the class diagrams look *exactly* the same, but you'll find the differences in intent and implementation.
We do address the newbie's tendency to over-apply patterns in the last chapter of the book. But that's ok - when you're first learning the patterns, you need to implement them, apply them, try them out - that's how you learn. As you gain experience with them, you'll learn how to see when you need one and when it's just overkill. We talk about when using a pattern might be overkill a lot in the Q&A ("No Dumb Questions") sections of each chapter.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: May 14, 2004
I agree, I think study groups are a really great way to learn and understand patterns.
Joined: Jan 29, 2002
Originally posted by Shari Griffin: Sorry, Sathya, I completely disagree. HFDP is an EXCELLENT first book.
I think it's a great book too. That's why I said it's a great complement to the other book. I believe both provide different viewpoints to the same topic.
Joined: Jul 11, 2002
Thanks for the great replies.
I look forward to checking out Head First Design Patterns.
I also want to say that I think Design Pattern User Groups are great.
I still don't feel I know the GOF Patterns as well as I should, but I do feel I got a better understanding of patterns from my Denver Java User Group's Patterns Special Interest Group. Each of us would take a couple of the GOF patterns and present it along with code examples. We met once a month and it took us a year to get through the Gang Of Four Patterns. The biggest advantage to the group was the discussion and debate about what each pattern was. The Singleton pattern generated the most debate and we thought it should have been the simplest pattern.
Other good resources besides the Head First Design Patterns book are Stephen Stelting's Applied Design Patterns in Java book - has lots of great code samples too and covers the GOF Patterns and Alan Shalloway's Design Patterns book. He doesn't cover all the GOF Patterns but it's a good primer to get you started. Maybe the Head First book will also serve as both a primer to get started and a reference.
Joined: Jul 11, 2001
Originally posted by Greg Ostravich: The Singleton pattern generated the most debate and we thought it should have been the simplest pattern.
That's my experience in general. We often decide to do two patterns in the next meeting, because they both look so simple - and then the first actually generates so much discussion that we don't find the time to do the second... :roll:
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: HF Design Patterns: Recognizing the Patterns