views:

427

answers:

13

If I have limited time, but I want to start learning a few design patterns, which ones should I learn first?

+2  A: 

Singleton 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.

McWafflestix
Singleton is basically deprecated, mainly because anything which the singleton can't be tested without the singleton. Eg: You could test a DAO with out a database using stubs except for that dang DB.conn() method. But yes, you will see a lot of it in existing code, and it is still too commonly used. ConnectionFactory.getInstance() could return the same connection each time, without locking you into an implimentation.
corlettk
+4  A: 

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.

Joel Hooks
+7  A: 

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.

ChrisW
+19  A: 

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.

tvanfosson
PLUS PLUS ON: "I would focus on learning which patterns are useful in different situations rather than focusing on learning how to implement a particular pattern." The biggest problem with design patterns is that fools use them inappropriately, because they read the book, and believe the book says this is "right" when in fact it says no such thing... GOF is explicitly "a box of tools". It is NOT a proscriptive meta-recipe.
corlettk
+1 for the second paragraph of your answer. It's far more useful to view design patterns as a vocabulary for describing common solutions to common problems. Asking which design patterns to learn first is like asking what medical words you should memorize first in order to become doctor.
Jeromy Irvine
+3  A: 

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.

Peter Gfader
+7  A: 

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.

PandaWood
+1 Great book to start learning Design Patters with
Andreas Grech
+2  A: 

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.

Andy White
+4  A: 

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.

rp
"Knowing what not to use is as important as knowing what to use." Amen brother.
corlettk
Can I sort-of paraphrase that: GOF is "ok" if your an experienced programmer, in either OO (preferable) or procedural (like myself) who was/is learning OO... experiences gives you the prerequisite comprehension of the "higher order motivations" of really good software design. Let's just says that GOF ain't for noobs.
corlettk
I agree, corlettk. I'm a procedure refugee myself.
rp
I suggest the for loop, if you don't have much time to learn C#.
Nosredna
+1  A: 

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.

Curt Sampson
+1  A: 

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.

Dave W. Smith
+1  A: 

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:

  1. Abstract Factory
  2. Adapter
  3. Composite
  4. Decorator
  5. Factory Method
  6. Observer
  7. Strategy
  8. Template Method
動靜能量
+1  A: 

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.

Josh Einstein
+1  A: 

Throw away your crutches. Learn Functional Programming.

Apocalisp