Your economics professor is absolutely correct.

Software Design Patterns are primarily a way for experienced software developers to communicate with each other. They are a shorthand for established solutions to known problems.

But they should only be used by people who understand how to solve the problem without the pattern, or have come up with a similar pattern on their own. Otherwise, they will have the same problem as the copy/paste coder; they will have code, but they won’t understand how it works, and therefore will be unable to troubleshoot it.

Also, many of the design patterns are enterprise patterns, patterns that are intended to be used in large, corporate software systems. If you learn the wonders of the Inversion of Control container, you will want to use it in every program you write, even though most programs don’t actually need it (there are better ways to inject your dependencies in smaller programs, way that don’t require an IoC container).

Learn the patterns. Understand the patterns, and their appropriate use. Know how to solve the same problem without the pattern (all software patterns are abstractions over fundamental algorithms). Then you will be able to use software patterns with confidence, when it makes sense to do so.

The way Design Patterns people want you to look at Design Patterns is as a set of solutions that you can apply if similar problems come up. They do not want you to think of them as the only possible solutions, given by God to Moses carved in stone tablets upon the mountain.

Unfortunately, some people take them as something closer to holy writ than to a bunch of example designs that could be learned from. That does kill creativity, and sets up a cargo cult.

Your economics professor mentioned presenting students with the problem and having them try to solve it first, which is a good educational technique, but he did have a solution to show them. Having a bunch of solutions to lots of different problems in your head a good thing, and it’s something Design Patterns tries to be. I think it fails in some ways (Singleton encouraging bad approaches, a myopic focus on imperative OO, etc.), but it could be used well with intelligence and taste. However, it is a mistake to think that every possible example solution in software Must Be An Official Design Pattern.

If you look at a problem and ask yourself “What is the Design Pattern for this?”, then you’re doing it wrong, and you’ll be less likely to see a solution that’s staring you in the face.

If you look at a problem and ask yourself “How can I solve this?”, then if there’s a non-pattern solution, you’ll see it, and if there’s a pattern that fits, you’ll see that too.

I also think your economics professor is correct and that’s a way to learn anything in the first place; However let’s look at like this: Would you keep the Wheel secret and let everyone reinvent it, for the sake of Creativity? I expect you to say No, because not all the people are made/capable of inventing their wheels — and if they’re, they will do it at some point, doesn’t matter if they are aware of existence of the wheel or not.

Let’s go back to programmers; I am a web-developer by day, so MVC is one of those things that I interact with on a daily basis. Several times I tried to build my own structures, I learned a lot but all of them were basically unsuccessful. I tried my best but what would happen if there were no MVC out there? Well, simple, my source code sucks — in terms of reliability, maintainability and extendability.

I think that’s the same for most of us. If nobody tells you about DI — as a good practice, then how many enterprise applications should struggle or fail until their developers learn the lesson?

The second point is Industry Standards. If you won’t teach MVC to web-developers then are you ready to face all of those non-standard structures that you need to spend some time to learn their way of doing things first, and then you realize that some of those structures might have a nice idea, but most of them will have serious design-flaws that might have serious consequences for your software project — even well-known frameworks still struggle with design-flaws time to time.

But what would happen if we do have all of those nice ideas and put them all together and those smart developers take the good things from all of those experiments and make a really cool structure that works best for that specific problem? Then you have just created the Design Patterns. If you’re a living creature, then there is no other way around; Even animals follow best-practices and design-patterns in their day-to-day life.

Don’t reinvent a hammer, but don’t treat every problem like a nail

Programming patterns are a great time-saver, because they give you ready-to-use solutions, good documented and tested with mean cases you could easily forget about. But you need to learn (and think) when to use them.

Paraphrasing your question: would learning to drive make me move faster, or just walk slower?

Learning how to use programming pattern doesn’t mean you shouldn’t exercise finding own solutions. There will still be enough problems to exercise your creativity upon. Knowing programming patterns will only let you get quick with well-known problems and concentrate on those, which are less trivial.

Returning to the second part of your question – is your proffesor right?

Yes, he is right. The primary goal of studies is to learn students to think. They need to try to find their own solutions to the problem, and then confront them with the existing solutions. Only in that way they can really understand them. If you learn them the patterns first, you risk they will only learn mechanically to apply them, and not to understand, what is behind.

This is the reason you first teach students to program, and the patterns are introduced in further semesters.

I would absolutely advise against teaching programming by teaching design patterns. You cannot apply them well without understanding the principles behind them, so teaching those principles are far more important.

I tend to think that design patterns aren’t really all that valuable to working programmers either, anyway. If you fully understand the principles involved in a given design pattern, then in a situation where it’s a good solution you’ll naturally tend to construct it (or something similar) anyway just as a matter of course, even if you didn’t know that it was a pattern with a name. Whatever time you’d spend learning patterns could be better spent learning how to think about code in general. If your “problem solving in general” skills aren’t up to scratch, then you can’t write good code no matter how good you are at applying some set of patterns. And if your “problem solving in general” skills are good, then you can solve problems even if you don’t know a single pattern.

I also think that in an ideal world there wouldn’t be any design patterns, because ideas common enough to be called a pattern would all be well-implemented in libraries and we’d actually be reusing code instead of constantly rewriting it. Imagine if there was a “regular expression design pattern”, that required you to implement a small regex engine every time you wanted to use it. Design patterns are just libraries that can’t be written because the language doesn’t provide the right abstraction facilities.

That’s actually another reason to not care terribly much about them; they’re not anywhere near as universal as is sometimes claimed, but are in fact tied very strongly to the particular ways of structuring programs that a particular language allows/encourages. A design patterns book written for Python would be completely different than one written for Java, and even more different than one written for a non-imperative language like Haskell. Better to understand at a deeper level, and you’ll be able to discover design patterns yourself in any language you gain familiarity with.

Commerce and education have different goals. If I were teaching students design patterns, I would take the same approach. But in a production environment, time and efficiency are everything.

Moreover, (macro) economics outside the classroom is a different thing. Do you see governments saying, “Whoa! Now we are super bored with doing the taxes and all the same way, so let’s try something super wacky this time”? No, you don’t, because such wild experiments can shatter the economy beyond repair. Instead, they tend to stick to tried-and-tested approaches: increase interest rate, announce tax holidays, etc. In other words, they are relying on design patterns.

The answer is, of course: Yes.

Design patterns are a wonderful learning tool in themselves, as long as one takes the time to figure out how they work and why they bring the value they bring.

They can also be great productivity boosters by fast-tracking a design process, because they provide familiar solutions to problems that pop up all the time.

However, if they short-circuit design too much, or people become dogmatic and over-precise about their use, then they have the opposite effect.

Design patterns are of course less creative. That’s the whole idea. Creativity is a scarce resource. You shouldn’t waste it on problems that don’t need creativity. It is much easier, quicker, and more likely to work, if you solve a problem in the same way as hundreds of developers before you. Boring, unexciting code that does its job is actually good.