Can somebody explain the obsession with patterns and anti-patterns in programming? I ask because I have absolutely no idea what any of the patterns mean. When faced with a programming task I think about the problem for a little bit, write down some data structures that I think will be relevant, prototype a solution, separate out some modules and iterate. Nowhere in the process do I think "Oh, I need FunkyLookyTastic pattern here".

  • 12
    Obsession with patterns is in one way an anti-pattern
    – Anto
    Commented Apr 19, 2011 at 4:26
  • 1
    On the last point, I partly agree. There are some patterns I will name, but some textbook patterns seem like minor variants of each other, and the interesting bit is usually how you adapt the pattern to fit the specific case anyway, so you certainly shouldn't be dogmatic about the things.
    – user8709
    Commented Apr 19, 2011 at 4:33
  • 1
    Are you programming in a dynamic language? Many of the patterns people refer to are ways of getting around limitations in Java.
    – johncip
    Commented Jun 29, 2017 at 1:19
  • Also, treating each problem separately doesn't scale with team size. For instance, with an MVC framework, models are often normalized but views might deal with derived data. There are a few ways to handle that, but people shouldn't be solving that problem (potentially differently) each time it's encountered. And others reading the code shouldn't have to figure out how problem X was solved in this instance, as opposed to all the others.
    – johncip
    Commented Jun 29, 2017 at 1:48

4 Answers 4


A pattern is a common approach to solving a common type of problem; nothing more, and nothing less. By knowing and understanding them, you can make use of other people's experiences to guide you towards the kind of solution that's been shown to work well, avoid pitfalls that have been encountered in the past, and discuss the solution using terminology that's familiar to others who know that pattern.

Of course, you can come up with a fine solution without explicitly using a pattern, and equally well come up with a bad solution by trying to apply a pattern that doesn't really fit your particular problem. I think the "obsession" you observe generally comes from people who have just discovered the concept, and think that it is rather more powerful than it actually is. Most people will quickly recognise them for what they are: a useful tool, not a magic bullet.

Anti-patterns, on the other hand, are commonly observed behaviours that tend to reduce code quality. Again, it is useful to know and understand some of these so that you can avoid such behaviour, and try to correct it (with reasoned arguments) when you observe it in others. Some would describe the overuse of patterns as an anti-pattern.

  • 1
    For example, the famous gang-of-four object oriented patterns were compiled from the experience of the authors and people they were in contact with. The reason some patterns have several names - they were independently reinvented and named several times. Most programmers will naturally reinvent a few patterns left to their own devices - and a few antipatterns, of course.
    – user8709
    Commented Apr 19, 2011 at 4:28
  • 3
    the "obsession" you observe generally comes from people who have just discovered the concept - mostly true, IMHO. there are those, I believe, who feel you must approach a problem with patterns ready ...and if your solution doesn't include obvious patterns, then your solution is wrong ...we should take the time to learn patterns, how they're used, and when and when not to use them - they are part of our tool box
    – IAbstract
    Commented Jul 18, 2011 at 21:41

Patterns are both the distilled knowlege of programmers in a cookbook, and a useful way for programnmers to communicate.

As other answers suggest, patterns really are common solutions to common problems. The benefit is that you can often get better solutions by using an existing pattern or discover probable pitfalls before you start coding.

The other benefit is when you're talking to someone about your code. Patterns are another type of jargon that condense lengthy descriptions into a few words. Try explaining "then we have an observer added by the factory" without referring to patterns. You can do it, but it takes a long time.

  • 2
    +1 for communication. Day to day routine goes much smoother when everyone is on the same page and has a common lexicon.
    – Ampt
    Commented Jul 1, 2013 at 13:15

Most developers will cringe at any new paradigm or methodology that comes in. I did to when I first heard about design patterns. Design patterns are just what the name suggest: a design or template for creating classes and modelling their behaviour and interaction in a predictable way

Take a look at houses. They have some similarities. Every house has a living room, kitchen, bedroom , bathroom, toilet for a minimum. No one will build a house without a bathroom, right? Apartments have a pattern that is different from bunglows. Castles have a different pattern altogether. Clothes too have patterns. A Jacket and a formal shirt both have the same basic design, yet they have different behaviours: you won’t wear a cowboy jacket for an interview. Similarly classes and their actions can be grouped according to their behavior and design. Looking at the common elements in their behaviours gives you design patterns for classes.

Design patterns in my understand are only important if reusability and expandability are primary concerns. If you create small apps (say less than 10 classes), you may not need them at all. But large projects, especially those which have large teams working on them and have a long maintenance and feature addition cycles, will definitely need patterns. It isn’t even an option in large projects.

Take a look at some online tutorials on patterns. Wikipedia has a good set of articles. This site is good too: http://sourcemaking.com/. If you are an experienced programmer, you will find that you have come across a few patterns, maybe even implemented something similar yourself without knowing it by a particular name.

Don't ignore them altogether! You may find them useful in the future if not now. The key to approaching Design Patterns with an open mind is to ask: "What will happen if I don’t use design patters?" Patterns aren't meant as "cures" (although you can use them as a cure for a problem); rather, they embody the dictum "prevention is better than cure".

All the same, I would caution against an obsession with implementing patterns wherever and whenever you see a small pretext to use it. I faced this problem in one project where the architect was convinced that without DP the project would be a complete disaster. We had a group meeting where the engineers shifted through the design and pointed that many patterns that he recommended would have no use at all other than showing "wow look at the beautiful patterns". It took a lot of convincing and some bargaining to reduce the number of places where patterns were used to a need-only basis.

  • 1
    Your house pattern example is so appropriate, because the idea of patterns comes from housing and urban planning. See Christopher Alexander, "A Pattern Language: Towns, Buildings, Construction"
    – Florian F
    Commented Dec 26, 2020 at 22:15

The people who answered are correct in terms of "pattern-based programming" as its normally thought of. I have a slightly different definition that I find more relevant to what I'm doing and I tend to use "pattern-based programming" to describe a plugin approach rather than a planning approach.

Since I program jQuery plugins, a CMS cloud plugin and eCommerce plugins, "pattern-based programming" from that perspective means to look at the core technology and what use cases exist and hit the most statistically relevant ones. Plugins in particular have to be very pattern-based so they fit within the programming context well.

However, it is best to apply a pattern AFTER you see valid use cases on multiple projects so it is statistically valid for reuse.

Your Answer

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