If I have limited time, but I want to start learning a few design patterns, which ones should I learn first?
views:
427answers:
13Singleton is used very very heavily in many places. The Adapter pattern is also very frequently used. Those two are among the most frequently used, and are relatively simple; understanding them can be helpful to understanding patterns, and can be useful for your development.
I think the usefulness of design patterns lies more in the added vocabulary that accompanies them, more-so than using a single (or a couple) of patterns. Having a working knowledge of the common patterns in the Gang of Four book is extremely useful when trying to communicate with other developers.
I would suggest reading the Table of Contents, then reading the summary of the patterns catalog. If you are limited for time, knowing in general what the patterns symbolize would be beneficial so that when you NEED to know the details of a pattern you would know where to look. This is as opposed to knowing the State or Singleton patterns on their own little islands.
Why not read a summary of them, this summary for example, and see whether some look like they might be useful to you, and worth investigating further.
I'd suggest Inversion of Control/Dependency Injection. This comes in very handy when unit testing as it enables you to supply mock dependencies for the class under test. Proxy is also very useful when wrapping a sealed class to make it more usable in testing scenarios.
If I make another suggestion, I would focus on learning which patterns are useful in different situations rather than focusing on learning how to implement a particular pattern. You can almost always find a reference implementation to use when implementing a pattern, but being able to discern when and which pattern to use will make the patterns more useful. If you start going about it the other way, you end up making your problem fit the patterns you know rather than applying the correct pattern that fits the problem.
Abstract Factory. Used in Dependency Injection (DI).
If you understand that, you know how DI works basically, and then you know what Inversion of Control is.
Design Patterns are not the sort of topic you quickly start reading and learning about. You will have to do many exercises and then apply what you've learned in real scenarios. If your time is really that limited then you might be wasting your time. I suggest the book Head First Design Patterns, which is excellent.
But your knowledge of OO should be at a fairly high standard to start with.
The "Command" pattern is a little more complex than Abstract Factory, but is commonly used, and powerful.
Another pattern that I've never really had a good chance to use is the "Composite" pattern. This one will give you good exposure to OO techniques, and might prove useful if you ever come across a need for it.
Your question is like asking, "I want to learn C# but only have time to learn a few keywords. Which ones should I learn?"
Any one design pattern doesn't live in a vacuum. They all define different aspects of how an application goes together. It's unlikely that any one app needs all of the known design patterns, but every app is different and you'll need a different combination of them for each app. Knowing what not to use is as important as knowing what to use. You need at least a conversational knowledge of all of the primary design patterns.
Start with this list and the Head First Design Patterns book previously mentioned here. Learn a little about all of them. And don't bellyache about not having the time--make the time! Stay outta FaceBook a couple of extra nights or skip a Star Trek rerun or two.
Also, avoid at first the GoF patterns book unless you are truly an OO guru. It is quite dense and immediately asssumes you understand the value and need for patterns. It's a great book, just not a great first book.
I thought that 'Flyweight' was a very cool pattern that really didn't have any relation to anything else. (I.e., you'd never decide to use another pattern in it's place.)
But if you're going to learn just one pattern, 'Visitor' is the one you want. It's a concept that extends far outside of OO programming; it will help you understand functional programming concepts such as map
and fold
. Or even OO methods such as collect
and inject
.
Strategy is on my shortlist. It's a great way to rid your code of conditional logic that's only there to support there being multiple ways of doing things, and it helps extract "policy" code so that it can be tested in isolation.
The GoF (Gang of Four) book recommends these as a start: (in "Guide to Readers" in the book)
Start with the simplest and most common patterns:
- Abstract Factory
- Adapter
- Composite
- Decorator
- Factory Method
- Observer
- Strategy
- Template Method
I've always personally felt that you don't "learn" design patterns... you learn to "recognize" them. In other words, when I first read Design Patterns, a lot of them seemed like solutions that just fell out naturally in applications I'd created before but perhaps I didn't do it exactly the same or as cleanly.
In my opinion, Design Patterns is more about standardizing the solutions that have materialized over and over again rather than teaching you how to solve a particular problem.