I'll take a shot at answering, but you should know that people disagree about this. The GoF patterns predate Java. They came out of a "software patterns" movem

I'll take a shot at answering, but you should know that people disagree about this. The GoF patterns predate Java. They came out of a "software patterns" movement, inspired by Christopher Alexander's beautiful A Pattern Language about how to make great buildings, to capture various problems that come up frequently in software design and formulate standard solutions to them. The hope was that this would lead to a body of engineering knowledge that people could learn software design from, instead of everyone having to figure this stuff out on their own or (at best) from oral tradition. Also, the idea was to provide a standard vocabulary for common constructs, so for example instead of me saying "wrap" and you saying "delegate to" we would both say "decorate". But it didn't work. Software patterns turned out to be at just the wrong level of abstraction: too generic to be applied directly to real problems and too specific to be good as principles. They confuse inexperienced programmers who are told that good code makes use of patterns and so try to find ways to organize their programs around them. That is disastrous: you get a bunch of abstractions in your code that are not there because of the problem you're trying to solve, but because of preconceived ideas about what good code looks like. What's particularly bad is that the patterns are seductive: they seem to make sense when you read them, but as soon as you get to your concrete problem, it's hard to see how to apply them. If you're inexperienced, you blame yourself and think you're doing it wrong, when what you ought to do is reject the abstraction as not fitting. People who like software patterns will say that of course you're supposed to apply the patterns appropriately, not mechanically. But this leaves you trapped in a circle. If learning the patterns themselves doesn't teach you how to make good code with them, what's the point of learning them, and how do you get good at software design? People who dislike software patterns add that in many cases, the patterns amount to mere code repetition, caused by the fact that a given programming language isn't powerful enough to get rid of the repetition, and that the solution is not (in PG's memorable phrase) to be a human compiler but rather to just use a more powerful language. In my opinion, you'd be much better off just writing real programs to solve interesting problems. No one has a good general theory of programming. What you want is practice. Learning patterns will fill your head with a lot of abstract gobbledygook without telling you which bits are useful in specific cases. Don't start with a solution or a set of solutions in mind; always start from and return to the problem itself. It will tell you what to do, or at least what to try. Your job is to try those things and see which ones fit - they are the ones that solve part of the problem without adding extrinsic complexity. Learn your language well. Learn more than one language. Read other people's code, especially by anyone you think is particularly good. Finally, when you write a program, think hard about whether you could do it more simply: that, over time, is the royal road to good software design. And if you want to get stronger in CS, avoid software patterns and software process and most of what's called software engineering, and just learn more about the classics, like algorithms, data structures, operating systems, compilers.