views:

164

answers:

6

Already tried:
dofactory
Sourcemaking+their video
"GOF" book
"Head First Design Patterns" book
But still have problems with implementation scenarios on practice. Maybe i have too little experience? (almost 2 years using C#)
Or maybe there are other resources or some methods to learn to see them?

+2  A: 

No resources can substitute real project experience. Try harder to integrate what you've learned so far in your own work (whenever appropriate of course) and things will get clearer over time.

Bozhidar Batsov
I hope so..When ive opened the GOF book for the first time it was almost impossible to read for me. For now i can use their diagrams and understand what the pattern means and does from its code+UML. Hope the time helps. Thank you for the answer.
nihi_l_ist
+5  A: 

I think you need to switch your mindset from "let me look at the problems I have to solve and figure out how to apply design patterns", to "let me at the problem I'm solving and come up with an appropriate design and see if any patterns emerge".

Design patterns emerge based on a problem that needs to be solved. You have done the necessary homework to understand some of the classic patterns that have been identified, and now you will recognize them (with time - experience helps of course) when they make sense for a problem you are solving.

jkohlhepp
I agree. The design patterns have been named so that you can easily communicate them, not necessarily to be the only tools in your toolbox. I suggest that you focus on best practices and see what design patterns emerge.
Marcus Adams
+1  A: 

You learn design patterns by using them in practice. :) As Bozhidar said, as you try to apply them you will find it easier to see where a design pattern might suit your needs as your experience grows. Soon the "basic" patterns will feel familiar and you become even more comfortable applying them in your code.

daft
3 people already said that i've seen enough resources to know what they are and i need just time+code to recognize them :) Think this is the answer. Thank you guys, i'll practice more!
nihi_l_ist
+4  A: 

First, don't set out to use design patterns just to use them. Learn to recognize situations where a particular pattern would be useful. The key to this is to understand the problems that each pattern is intended to solve, then recognize when you have that problem.

Second, don't get hung up on using patterns to solve your problems. If a pattern exists that solves or can be adapted to solve your problem, then use it. If you have a better way, then use that. The most important issue is whether you are using good coding practices (including, but not limited to patterns) to solve your problems. One problem with a shiny, new tool is that you start looking for ways to use it even on problems that it wasn't meant to solve. Here's a hint: if you start seeing applications for Singleton everywhere, you're too caught up in using patterns and not enough in producing good code.

Third, spend some time trying to recognize patterns in code you already write. Because patterns are simply encapsulations of good ways to solve particular problems, it's possible that you are already using some and simply don't recognize it because your names are different than those used in the pattern. Once you recognize the patterns in your own code, you'll be able to see situations where they can be used in your future code.

Lastly, try using test-driven development. Test-driven development will drive you towards good code, including some excellent design patterns and techniques, like factories, dependency injection, decorators, etc.

tvanfosson
Thank you for such expanded answer! I've already tried to start test-driven development, but, after some time, switched to previous model :( because it seemed to be very slow for me to write small tests for almost every method(tho i know that this is important and it helps in refactorings and project changes(which SURE will happen)). I'll try to follow your suggestions, thank you again for sharing experience!
nihi_l_ist
@nihi - TDD is slower initially, but your tests will allow you to continue to develop at or near the same pace as your application gets more complex. Without sufficient tests, eventually you start spending more time in break/fix mode as you add new features. In my experience writing tests first is faster than writing tests after (unless you never write them) and tests are the key to maintaining productivity.
tvanfosson
+2  A: 

From my personal experience it is good to know Design patterns, but not to fit them every where. Learn as much patterns as you can Start writing your own design pattern for practice, not necessary that it is perfect you can modify it later to make it better, doing this you will get even better understanding of Design Patterns.

As you have mentioned Head First Design Pattern there is good description of how to write your own pattern.

Vinay Pandey
+1  A: 

Just to be concrete, read this document from JUnit's authors. It's a pleasant description of JUnit Design based on Design Pattern. You can read how Design Pattern have been used in JUnit and how they have been implemented.

pierocampanelli