I'm a university student and I've just started learning about design patterns and im struggling to understand the purpose of them. I have tried researching them but all the resources I have found seem to talk about them in an academic, not professional, way.

What is their purpose and are they important to learn?

  • 7
    They are good to know for job interviews!
    – wim
    Commented Dec 19, 2011 at 2:17
  • 5
    A design pattern is just a named, commonly recurring way of solving problems. Usually they arise from deficiencies in languages.
    – Jon Purdy
    Commented Dec 19, 2011 at 4:04
  • 7
    Understanding the purpose of design patterns requires understanding the problems that they solve. Understanding these problems requires experience of doing it the hard way :)
    – MattDavey
    Commented Dec 19, 2011 at 9:47

9 Answers 9


Design patterns are great for communicating your intent very quickly- everyone knows what a Factory is.

What's a really, really, really bad thing to do is start trying to fit your code to patterns, or separate responsibilities according to patterns, or something like that. It's one thing to say "This object is a Factory" and another to say "This object should be exclusively a Factory".

  • 1
    So you are all for patterns but they are not really for your code. Yes they are good to communicate idea, but they are even better when you can see the pattern in the actual code.
    – Newtopian
    Commented Dec 18, 2011 at 14:02
  • 3
    Why down-votes? This is actually the best answer IMHO. Coding is common sense, and sometimes you can quickly use a patterns which are a good fit to solve the problem. But once people start abusing them everywhere, it turns into one hell of a mess.
    – Coder
    Commented Dec 18, 2011 at 15:00
  • 1
    Every code contains some pattern, even if you are not aware of it. The Design Patterns you are talking about just regroup and name a set of widely used and useful patterns. When you know them, you can think about them in a more conscious way. If you call one of your classes "ControlDispenser", probably nobody will know what it is supposed to do. However, if you know the factory pattern, then you will call it "ControlFactory" and others will immediately understand. Commented Dec 18, 2011 at 15:09
  • 4
    If it serves another purpose, it should be another class... separation of concerns.
    – Nate
    Commented Dec 18, 2011 at 23:47
  • 2
    @Nate: One purpose may be several patterns. There's no reason that one class should involve only one pattern. Patterns are not "atomic" responsibilities. A single responsibility may require several patterns.
    – DeadMG
    Commented Dec 19, 2011 at 2:35

From the wikipedia article on Design Patterns:

The usefulness of speaking of patterns is to have a common terminology for discussing the situations designers already see over and over.

For a very long time we have had a serious problem in software engineering: you hire a newcomer to a project, and no matter how well they know the programming language, it takes them months to get up to date with how things are done in your project before they can be productive. In hardware engineering, they solved this problem a very long time ago: they have a common terminology called 'schematic diagrams'. You hire a hardware engineer, give them the schematics of your hardware project in the morning, let them study them, and by evening before it is time to call it a day they can pick up the soldering gun and become productive. We have been trying to come up with ways to become better at that; standardization of programming languages was one way; standard libraries (class libraries nowadays) have been another way; but one of the most important ways has perhaps been design patterns. So, are they important? You bet!

  • 3
    Comparing software development to electrical engineering is about as accurate as comparing the a saturn rocket with a bicycle. Both methods of transportation (getting from point A to point B) but go about it entirely different, and non-compatible ways.
    – jer
    Commented Dec 18, 2011 at 17:52
  • 3
    @jer Hmmm, your analogy is poor. Both of them are engineering disciplines. Even if their similarities ended there, they would still, by definition, have an awful lot in common. We are not hoping to ever equate them, but one has a lot to learn from the other.
    – Mike Nakis
    Commented Dec 18, 2011 at 17:57
  • 6
    @Mike: there is a fundamental difference: electrical circuits are constrained by hard physical limits. Software systems are constrained by the fuzzy limits of human intellect. Commented Dec 18, 2011 at 18:10
  • 3
    First of all, I did not say there are no big differences. Secondly, your statement is not correct, either. Software does obey hard constraints, those set by the syntax of a language. And the number of permutations in which human intellect can interconnect electronic components is also limitless. But again, I am not trying to equate the two, or even to say that there is an awful lot of similarity. I am just saying that one has a lot to learn from the other.
    – Mike Nakis
    Commented Dec 18, 2011 at 18:16
  • 3
    Since software is all about design, a similar electrical engineering analogy would be the discussion of "current mirror" and "negative feedback" in an amplifier circuit. These are not discrete components on a schematic, but rather an arrangement of several components that fulfills a certain purpose. Knowing how to connect the components without knowing their purposes will not allow a new person to make a new design. (i.e. it is a step forward in understanding.)
    – rwong
    Commented Dec 18, 2011 at 19:51

There are really two different, substantial reasons for the existence of patterns.

The first has already been explained pretty well: the use of patterns lubricates communication between developers. If you and I both understand that when I say 'Observer' I am talking about a very specific structure of code, then I can very quickly describe how a bit of code which uses that pattern works. The alternative is to fully describe the solution, which is time consuming and error prone. ("Well, I created this pure virtual class which describes and interface for consumer objects, and then I created a class which maintains a list of active consumers, which ...")

The second benefit of patterns is that they are off-the-shelf solution-forms for common problem-forms. If you know your patterns, and, for example, you encounter a problem where you need to find a good way to get information from (possibly multiple) producer objects to multiple consumer objects, without introducing unnecessary coupling between classes, you will recognize "this is a job for an Observer!" and you will immediately know how to solve your problem.

These benefits also really reinforce each other. They allow you to quickly solve certain common classes of problem, and then when you're done, you can very quickly communicate how you solved the problem.

Contrast this with a world where patterns "don't exist". You run into one of these classes of problems, which are generally not trivial design problems, and you spend a fair bit of time coming up with a good solution (which, incidentally, will very likely look a lot like the appropriate pattern). Then, your co-worker comes up and wantx to know how you solved it, and you spend an hour discussing the how and the why.

This is all associated with a caveat which should seem pretty obvious: don't try to force problems into patterns that don't fit. If the pattern doesn't fit the problem, then the solution will end up being convoluted and you will lose the effort reduction benefit of patterns. Additionally, since your work will no longer fit with your co-workers' understanding of the meaning of the pattern, you will lose the cost of communication benefit. In fact, you will likely increase the cost of communication beyond the no-patterns cost, because the misuse of the pattern will give your co-workers a false understanding of the solution, which is worse than no understanding at all.

  • 2
    It's a misconception that design patterns are an off the shelf solution. They are "PATTERNS" this does not always translate into code. Commented Dec 18, 2011 at 18:43
  • Erm, a pattern does always translate into code, that's pretty much a given - what is an issue is that they may not always fit into the code you have or the architecture you have or the constraints you're working under. i.e. just because a pattern may fit that doesn't necessarily mean you can use it. One might assume that's what you meant (but I don't like making assumptions).
    – Murph
    Commented Dec 18, 2011 at 22:33

Patterns are about re-use of ideas and concepts and about establishing a common/consistent platform for communication of same.

We're all agreed (!) that in theory code-reuse is a good thing - but it turns out to be harder than we'd like to do so practically (in some respects this is changing, but it will always be a challenge). But in reality a lot of what we want to reuse is a way of doing things, to use a sort of template for constructing a solution to a particular problem - these are Patterns. So you get to a case where you say that a good approach to solving problem X is to use Pattern Y and we know that the elements of pattern Y are a,b and c and off we go. Because the patterns are widely understood you don't have to explain in depth which is the communications benefit.

What's entertaining about patterns is that languages and frameworks are evolving to provide better support for common patterns with the net effect that we're getting more and better code reuse (more and better lego bricks!) because the way we build applications (by implementing patterns) facilitates reuse.


Design patterns are just known bricks any software solution is built upon. They are important due to the following reasons:

  1. They are language agnostic. Once you know what design pattern is appropriate for given problem/architecture/task you can implement it in any multi-paradigm language -- let is be C#, Java or Python -- the solution will be in most cases the same, you just have to adapt the syntax. This means that you can transfer your experience from programming in one language to other languages as long as you stay within the same problem domain (and maybe even across domains).

  2. Despite the fact that design patterns do have binding to programming paradigm, meaning that design patterns for object-oriented programming (the most famous ones, also known as "Gang of Four" patterns). Patterns allow you to understand what the paradigm is best for and help you to go beyond just syntax. For example I have seen a lot of implementations in C# and Java where people just programmed the way they did it in Basic or Fortran -- they have a perfect imperative mind for solving problems and they use OOP just to render this solution -- no inheritance, no polymorphism, all methods are public etc. Design patterns help you to look behind these concepts and see how they work in real life. Same applies to design pattern in other paradigms, like functional programming.

  3. Patterns are generally a handy way to represent ideas and came to Computer Science from architecture. Once you understand the idea behind a certain "pattern" you can easily recognize this pattern in some other problem and solve it using this pattern (probably slightly modified to better address your problem). There are tons of different patterns: in Enterprise Software Integration, in Source Code Testing etc. Just look for patterns in books for Computer Science.

  4. Aside from acquiring good practices by learning patterns you can easily learn how to avoid silly mistakes in your code by studying anti-patterns. There are plenty of books featuring common mistakes in different domains in form of anti-patterns that are very entertaining and same time educative. I love the names of these anti-patterns, by the way!


You can think of a pattern as a proven way to solve a problem that you and other developers understand. Eg, the problem is to create a sorted list of data, then you can choose to use a linked list, or put data into a vector and sort. You probably understand the both these options because you may already know the linked list pattern or the load and sort vector pattern. You may know the pros and cons of each and do not need to see the implementation to understand what is going on.


I think you are a starter for programming, I do not suggest you learn design pattern early. Learning and Understanding design pattern need to base on the experience of software development. You should be more practice to code and found which code style is bad and then to learn design pattern to improve design.


A usefulness of a design pattern depends of which language you choose. The more powerful language you choose the less you will need to understand and implement design patters. A design pattern may be a signal that your language sucks is missing a built-in feature.

Joe Gregorio made a great talk about the lack of design patterns in Python

  • Thanks for the link about the lack of design patterns in Python. Edit: Oops!! The video has been removed from that location!! :( Commented Nov 10, 2014 at 0:05

Design patterns are solutions to common encountered problems in software development. There is always more than one solution to some problems, and design patterns help you to decide which solution is the best by providing you a set of good solutions to these common problems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.