21

Many years ago, I was talking with an Economics professor about design patterns, how they were establishing a common language for programmers and how they were solving well known problems in a nice manner, etc etc.

Then he talked back to me that this is exactly the opposite approach he would use to his Economics students. He usually presented a problem and asked them to find a solution first, so they could think about it first and try to find ways to solve the problem first, and only after that, he presented the "classical" solution.

So I was thinking if the "design pattern" approach is really something that makes programmers smarter or dumber, since they're many times just getting the "right solution for this problem" instead maybe of using creativity and imagination to solve some problem in a new and innovative way.

What do you think?

Michael Brown
  • 21,684
  • 3
  • 46
  • 83
Leo
  • 413
  • 2
  • 7
  • 5
    I would suggest reading [A Pattern Language](http://en.wikipedia.org/wiki/A_Pattern_Language) (the book, not the wikipedia article) upon which the Software architecture concepts of patterns is founded. They are not building blocks or jigsaw puzzle pieces to be fit together just so. –  Mar 18 '14 at 03:33
  • 11
    Leaning/Teaching is different from doing. So a really good CS course might have you writing a compiler -- if you suggested to your employer that you needed to write a compiler for his order processing system you would/should be fired. – James Anderson Mar 18 '14 at 05:08
  • 2
    I don't think the two are necessarily comparable -- design patterns are not the classical solution, they are an approach to a multitude of solutions. – jmoreno Mar 18 '14 at 05:46
  • 1
    possible duplicate of [Design patterns - do you use them?](http://programmers.stackexchange.com/questions/141854/design-patterns-do-you-use-them) - the question may sound different, but the answers to that question fit well for this case. – Doc Brown Mar 18 '14 at 10:22
  • IMO the creativity is in finding an implementation of the pattern that exactly suits your particular problem, plus, on an application-level scale, gluing all those patterns together in a way that's maintainable and somewhat legible. – Amy Blankenship Mar 18 '14 at 20:16
  • 2
    I don't know about creativity, but the multitude of "What pattern is this?" or "Is there a pattern for this?" questions gives the impression that some devs think there is a pattern for everything. – JeffO Mar 19 '14 at 17:06
  • Sometimes I think the quality of code is inversely proportional to the number of design patterns used. This makes no sense, unless design patterns represent a social problem, probably described as "copy and paste design," similar to copy and paste coding. – Frank Hileman Mar 19 '14 at 18:46

8 Answers8

43

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 3
    I'm pretty sure there are so many developers that without using design patterns they will write such a low-quality code that nobody wants to look at it even. I disagree that it should be used ONLY by people who understand how to solve the problem without the pattern ... To me that's a whole point of a design pattern; If I knew how to do it why should I go for a design pattern? Also what those other developers should do if we force them not to use a design pattern? They should make real software with their ideas and let it fail and then learn something new? – Mahdi Mar 18 '14 at 06:32
  • 18
    @Mahdi when lots of people find the same solution, that solution is called a pattern. It's not the other way around - you don't look at patterns and use them as solutions, you look at solutions and find patterns. – user253751 Mar 18 '14 at 07:23
  • 13
    @Mahdi I see far more beginners who think that if only they use pattern XXX they will create perfect software every time (where XXX is whatever they've read about last of course) and then go out of their way to torture every project into fitting that pattern. – jwenting Mar 18 '14 at 08:10
  • 5
    @Mahdi: don't take the sentence "by people who understand how to solve the problem without the pattern" too literally. Robert surely means "by people who have understood the problem in stake well enough to make a reasonable decision about when to use a pattern, and when not". – Doc Brown Mar 18 '14 at 08:38
  • 1
    Guys, thanks for the comments, they're useful indeed and I see your points as well. – Mahdi Mar 18 '14 at 10:33
  • 1
    @Mahdi:I think you might be overly critical. Design Patterns are a process. If the only tool you have is a hammer then everything looks like a nail. Same goes with patterns. As people learn other tools they'll start seeing where patterns have their role. As for low quality code, I don't think that has anything to do with design patterns, pin that on the developers, not the patterns. Actually, I'll bet far worse code would be written if they were just hacking together a random attempt at a solution. At least if they try to follow a pattern you might have a clue what they are trying to code. – Dunk Mar 18 '14 at 20:52
  • @Dunk I see your point and I'm agree with it. What I'm trying to say is that if you let me try my creative solution before knowing any well-known pattern, then you might not be very happy with the end result; However after 4-5 years of using design patterns practically, then I'm pretty sure I will have a better understanding of the problem itself and the possible solutions. – Mahdi Mar 19 '14 at 05:47
  • 2
    @Dunk I can try something creative on the top of a well known pattern or I can make it from scratch, but after trying bunch of other things and after understanding what are the exact pros and cons of each pattern. If you ask me to go and build a house for the first time and just tell me to be creative then I'm not gonna get that far to build anything solid, simply because that's too complicated in the first place. If you want to be creative instead of using a pattern, you should already have a solid understanding of the problem itself, and you will gain it only after years of experience ... – Mahdi Mar 19 '14 at 05:52
  • @Dunk And by that time you probably have already tried couple of patterns. Basically what I'm saying is that it's nearly impossible to come up with a solid solution for a real-world software just by trusting someone's creativity, simply because it's too complicated. Also again I see your points here -- all of you guys and I'm totally agree with it, I just wanted to make my point a little bit more clear. – Mahdi Mar 19 '14 at 05:58
21

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.

Michael Shaw
  • 5,116
  • 1
  • 21
  • 27
10

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.

Mahdi
  • 1,983
  • 2
  • 15
  • 25
  • 3
    "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" -- words of solid gold! – ankush981 Mar 18 '14 at 06:47
5

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.

5

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.

Ben
  • 1,017
  • 6
  • 10
  • Hmm, interesting answer. But I hear that programming interviews are heavy on design patterns. Why would that be if there was little value in them? – ankush981 Mar 18 '14 at 15:42
  • @dotslash For the same reason that IQ tests are heavy on maths/logic: they have *some* value and they're easy to test. That said, in my jobseeking as a programmer I didn't encounter them in interviews all that much; I'm Australian though, so maybe there's a difference in fashion. – Ben Mar 18 '14 at 19:36
  • But isn't learning about design patterns a great way to see concrete examples of how to think about code? What things would you look at to learn how to think about code if not problems + general solutions that solve the problems and example code that implements the solution? – Amy Blankenship Mar 18 '14 at 20:14
  • @Amy Yes, but there's a big difference between "here's a problem, here's a solution, here's how I came up with it" and "here's a pattern, memorize it so you can apply it to these problems in future". You want to teach the ability to *generate* solutions, because patterns can only ever apply some of the time, so they'll need that ability no matter how many patterns they know. If I were teaching a course including patterns, I'd probably do it by setting exercises designed to make the students notice *by themselves* that there were common concepts in the solutions to the exercises. – Ben Mar 18 '14 at 21:00
  • Excellent answer. The best programming environment would encapsulate most interesting patterns in libraries or languages, freeing developers to work at a higher level. I also like the point about language dependencies; many common design patterns are actually obsolete now. – Frank Hileman Mar 19 '14 at 18:50
3

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.

ankush981
  • 227
  • 2
  • 10
1

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.

sea-rob
  • 6,841
  • 1
  • 24
  • 47
  • 3
    they're terrible teaching tools for teaching programming (rather than design). They lead to the oh so common question on internet forums of "how can I implement XXX using the YYY pattern", which is the wrong question to ask, the question should be (when you want to force patterns) "what patterns would be appropriate for implementing XXX". – jwenting Mar 18 '14 at 08:14
  • 1
    lol I said learning tool, not teaching tool -- if one wants to learn ;) – sea-rob Mar 18 '14 at 08:54
-2

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.

gnasher729
  • 42,090
  • 4
  • 59
  • 119