This week's book giveaway is in the Design and Architecture forum.
We're giving away four copies of Communication Patterns: A Guide for Developers and Architects and have Jacqui Read on-line!
See this thread for details.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin
Bartenders:
  • Lou Hamers
  • Piet Souris
  • Frits Walraven

HF Design Patterns: Recognizing the Patterns

 
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks -
 
author
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greg -

�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.
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not to discourage people from buying HFDP, but I think "Refactoring to Patterns" by Joshua Kerievsky would be more suitable for the bottom-up approach.

I think HFDP and R-to-P are complementary. The first is needed to understand the patterns so that you can use the second more effectively.
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!)
 
author
Posts: 200
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.



Hi Greg,

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.

Hope this helps!

Elisabeth
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my experience, the best way to learn patterns (including recognizing them in the wild) is to join/establish a Study Group. Of course a good book still will be vital...

See http://www.industriallogic.com/papers/learning.html
 
Elisabeth Robson
author
Posts: 200
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree, I think study groups are a really great way to learn and understand patterns.
 
Sathya Srinivasan
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Greg Ostravich
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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:
 
If we don't do the shopping, we won't have anything for dinner. And I've invited this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic