How to study design patterns? [closed]

Answer 1

Lot of good examples have been given. I'd like to add one:

Misapply them. You don't need to do that intentionally, it will happen when you try to apply them in your initial Design-Pattern-fit. During that time every single problem that you'll see will seem to fit exactly one design pattern. Often the problems all seem to fit the same design pattern for some reason (Singelton is a primary candidate for that).

And you'll apply the pattern and it will be good. And some months later you will need to change something in the code and see that using that particular pattern wasn't that smart, because you coded yourself into a corner and you need to refactor again.

Granted, that's not really a do-that-and-you'll-learn-it-in-21-days answer, but in my experience it's the most likely to give you a good insight into the matter.

Answer 2

The best way is to begin coding with them. Design patterns are a great concept that are hard to apply from just reading about them. Take some sample implementations that you find online and build up around them.

A great resource is the Data & Object Factory page. They go over the patterns, and give you both conceptual and real world examples. Their reference material is great, too.

Answer 3

I have found that it is a bit hard to comprehend or understand the benefits of some patterns until one understands the problems they solve and the other (worse) ways the problems have been implemented.

Other than the GOF and POSA books I have not really read any so I can't give you other recommendations. Really you just have to have an understanding of the problems domains and I think that many less experienced developers may not be able to appreciate the benefits of patterns. This is no slight against them. It is a lot easier to embrace, understand and appreciate good solutions when one has to struggle with poor alternatives first.

Good luck

Answer 4

I think you need to examine some of the issues you have encountered as a developer where you pulled your hair out after you had to revise your code for the 10th time because of a yet another design change. You probably have a list of projects where you felt that there was a lot of rework and pain.

From that list you can derive the scenarios that the Design Patterns intend to solve. Has there been a time where you needed to perform the same series of actions on different sets of data? Will you need to be able to future capability to an application but want to avoid reworking all your logic for existing classes? Start with those scenarios and return to the catalog of patterns and their respective problems they are supposed to solve. You are likely to see some matches between the GoF and your library of projects.