Yes, you should learn them.

It makes even more sense to revisit them after you've gained some experience, so that you can compare them with what you know. For some patterns it will turn out that this is something you've discovered yourself, but you'll get to learn something more general about its usage, tradeoffs, variants and so on. Others may appear to directly address the problems you coped with and show you an elegant solution that you didn't know.

Great majority of the patterns is very useful and common. Others may not be as popular, but still have some narrow usage where they are perfect fit.

There's one more reason why it's worth reading: It will teach you how to think. Sure, it's not a silver bullet, but still an invaluable inspiration.

Last but not least, never, ever, under any circumstances try and make a problem fit a pattern or tool. That's very bad and dangerous thinking! Understand how the tool works and use it wisely to deal with the problem, never the other way round.

The more tools you know well, the better. Sometimes a tool can inspire your thinking (rather than solve a problem directly), another time you'll combine a few of them for a great solution.

The GOF book is a great source of many useful tools that we use daily.

The most important benefit from knowing just a little about Design Patters, is that you know what the terms mean. In other words you know the common vocabulary.

This is, to me, the most important achievement of all the Design Patterns turmoil, that a common vocabulary has arisen where you can just use the names of the specific patterns, and others immediately know what you are talking about without you having to explain it. The things the patterns describe are well known to most programmers, but it takes time to explain what you mean to others, so it makes communication easier to know the pattern names.

Examples are Visitor, Singleton, and Decorators.

So in other words, I suggest you get at least familiar with the names and what they do.

YES but with cautious!

The YES part:

Sometimes, we encountered problems in our designs. Sometimes those problems are very common, so a design patterns give you well tested solutions for those problems. The main benefits of learning design patterns is that you can come up with a design solution a lot quicker and if your co-workers are aware of the design pattern lingo, you can explain a solution a lot quicker as well.

The with cautious part:

Design patterns should not be the holy grail of your solutions. The simplest (KISS) solution is more desired and many times design patterns will make things more complex. If you are learning design patterns, also learn about anti-patterns. I know some old folks that are against design patterns and I do agree into some extent with them because when you don't have too much coding experience but load of design pattern theory, you might end up making thins a lot harder for you and your team.

Lastly, Don't think that you have to fit/change your solution just to comply with a design pattern. On the contrary, you can bend a design pattern so it can fit into your solution. Is okay if your are not using every ingredient of a design pattern recipe as long you have a better solution for your particular problem.Think of design patterns as a suggestion and not as the rule for your solution.

I've found the Net Objectives' method of thinking about patters as most beneficial. People reading the GoF book too often begin to assume that the structures they show, in design notation and in code, are the patterns and that this is always how they look. There's a different, arguably better way of looking at it.

Patterns are sets of similar problems that can all be solved with certain, abstract formulas, not sets of formulas that can be used to solve various problems. What this means is that the pattern is already there before you even begin trying to make a design, the object then of the designer is to find it, not to impose it.

Further, a lot of people look at patterns and say, "Oh, I just solved that by .... I didn't use no silly patterns." The thing is that "...." almost inevitably describes AN implementation of a given pattern solution. For instance, an array of function pointers could serve as a Chain of Responsibility even though this is not what the traditional recipe looks like.

With this in mind, the focus in your study of patterns should be on the problems, not on the patterns. Learn the motivating factors of patterns and how they address those factors. Doing this will allow you to see the patterns in the problem and then simply point them out. This, along with the language that patterns gives us for speaking about design, allows you to expose a design well suited to answer the various difficulties you're currently facing.

YES, in short, learning patterns is not only well worth it...you limit yourself by NOT learning them. I don't want to have to describe all the motivating principles and general shape of solution when I say, "Looks like a visitor to me."

Here's their website: http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page

The Design Patterns described by GoF are sort of a natural extension of the OO paradigm. If you don't thoroughly understand the goals of OOP (encapsulation, separation of concerns, the DRY principle, modularity, etc.), then trying to apply Design Patterns successfully doesn't make much sense.

If, however, you get your feet wet in real-world OOP, and try to be faithful to OOP values, you will inevitably get into situations as those described by the GoF, and chances are you'll invent solutions similar to theirs. Having solved lots of similar problems, you may begin to see patterns emerge; at this point, it makes sense to read the book; ideally, you'll have a sense of recognition, and you'll immediately appreciate the elegance and cleanliness of the proposed patterns. Chances are you'll also consider some of these patterns no-brainers (which, once you know them, many of them are). You'll also be able to judge well whether or not a certain pattern is applicable in a given situation.

And here's another warning: Just because you know all these patterns doesn't mean you have to apply them everywhere. Some of them are pretty clever, and people are tempted to use them even when they are horribly inappropriate, the Singleton pattern being the most famous example (much of the Singleton controversy comes from inappropriate use, e.g. when there is no benefit in having a one-instance-only constraint).

Design patterns try to solve problems of desing.

• They were made AFAIK primarily for OOP languages.
• Some of the problems does not exist in functional programming (Command Pattern is how to make first-class functions, Strategy Pattern approximates higher order function ...). These patterns are for languages (mainly OOP) which don't have needed functionality.
• They are sorted alphabetically. Several patterns are composition of others or the ideas are composed of those which were there before.

I learned patterns later, after I knew some functional programming, UML, database desing, data structures and algorithms. I actually just went trought the list of design these patterns on cheatsheet and nodded that I already know most of them. Some were really nice like singleton or "communication" patterns (visitor, mediator) ...

I agree with points made in several other answers about how it can be dangerous to apply design patterns with little experience.

Still, I highly recommend reading at least the first chapter of the GoF book. The first section will introduce you to design patterns, but is really more about principles of OO design, and this should be beneficial to read and understand even with relatively little experience. (Some key ideas I remember include "encapsulate the concepts that vary", "inheritance hierarchies should be broad but not deep".) It's almost a shame that the work is known mostly for its 23 patterns -- its discussion of the OO design principles that informed those patterns is also extremely valuable.

My question is, is it worth learning the patterns in the GoF book?

Absolutely! You should learn not only software design patterns, but design techniques in general. Learning common solutions to common problems is a fantastic start. Especially once you start digging into the patterns and their tradeoffs.

Do they show up enough that I should be learning them?

The original Gang of Four book was developed by examining many software projects and seeing techniques that a number of developers have used to solve problems. The authors noticed a few really good techniques, as well as a number that were applied in very disjoint projects and worked toward abstracting them even more to be of use regardless of domain.

it's always seemed counter-intuitive to try and make a problem fit a classic pattern

This is a major problem. You don't make a problem fit the solution. Instead, the Gang of Four design patterns book has a "problem" section for each pattern, and other pattern catalogues have similar sections, that describes when you should apply each pattern. It also describes the "consequences" of using the pattern - if you are trying to avoid a consequence, then using the pattern isn't the best idea.