Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What I have done

  1. Identified important patterns to learn
  2. Read the books
  3. Implemented the patterns using favorite programming language
  4. Identified pros/cons
  5. Practiced some design patterns in real world projects
  6. Found some example in Framework libraries

Having done that I still struggle to

  1. Explain them to seasoned interviewers
  2. Clearly differentiate between structural and behavior design patterns.

I believe my communication skill is not that bad, but somewhere I have not understood the concepts clearly.

How to learn the design pattern concepts to become capable of what I miss now?

(If that matters, I am talking about popular GOF design patterns like Strategy, Decorator, Observer, Command, etc)

share|improve this question

closed as not constructive by Oded, Caleb, Yusubov, GlenH7, Walter Jan 8 '13 at 14:24

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Read a more accessible book than the GoF book. Head First Design Patterns is not a bad one for that. –  Oded Jan 8 '13 at 13:55
I have done that. Problem is that while reading, I convince myself that i have learned with help of some QA (what/why) in my mind. Once book is off, i fumble on every second word while explaining to others –  Tilak Jan 8 '13 at 13:57
Which is an indication that you have not fully grasped and understood the pattern and its use. –  Oded Jan 8 '13 at 13:58
For pretty much any pattern you can think of, you can bet that there are at least a dozen questions here or on StackOverflow about what it is, how to use it, why to use it, etc. Why not pick two or three to start, search for them here, read the answers, and if something still seems confusing ask for help? –  Caleb Jan 8 '13 at 14:10
add comment

2 Answers

First of all you need to understand why design patterns are necessary at all. You need to see the problem first, and then look for the solution. And the best is when you yourself find the solution, and then compare it with the one that the book suggests.

As Oded said in his comment, Head First Design Patterns is a nice book. And it is perfect for this purpose: it offers a problem, suggest a wrong but obvious solution, demonstrates its disadvantages, and only then introduces the pattern that is perfect for the problem.

The rest about design patterns is mostly technical details.

Don't wait for another interview for telling about the patterns you're familiar with. Try the rubber duck method _ explain the pattern to someone/something. It will help you see what you didn't understand or remember.

Don't try to understand all "popular" patterns at once. Study them one by one and thoroughly.

And again, the best way to understand/remember something is to come up to it by yourself. I'm sure that many programmers used patterns without even knowing about it _ after all design patterns are best practices for certain problems that were introduced by some developers and approved by others.

share|improve this answer
add comment

To be honest no book in the world will make you fully grasp design patterns until you've written an application or a system from top to bottom, hitting the problems and changes that are hard to fix, and then use a pattern to accomodate for these problems and changes successfully.

I'm saying this even though I whole heartedly recommend the Heads First into Design Patterns book.

For a complete novice or a beginner it is difficult to describe design patterns because you probably haven't "lived through" the problems they're trying to solve and even reject implementing patterns that would make life harder for other programmers.

Implementing a pattern is one thing, doing so successfully in something that is already in production and your boss/comrades is yelling at you is another. Being able to fix legacy systems with refactorings (Refactor to Patterns is an excellent resource) is a skill that takes time to master.

You'll learn. Just be patient, it'll take time to let it sink in. I'm pretty sure you're like me when I started learning them, there is a lot of head scratching involved. It will take several years of programming practice to get it right and get the actual a-ha moments. At least it did for me.

But until then just make stuff up during the interview... or be honest about it, just mentioning that you've read them and trying to grasp is enough for most. Just don't mention the Singleton pattern and how much you love it in a TDD shop.

share|improve this answer
+1 There are things you can't learn in 1 day. Its the experience of so many programmers –  superM Jan 8 '13 at 14:18
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.