Take the 2-minute tour ×

I have only heard the term "design pattern" being used for object oriented code, and the GoF patterns include only OOP design patterns, but design patterns are elegant solutions for commonly occuring programming problems, right? There is nothing in there saying that they must be limited to OOP, is there?

I would like to see some examples of design patterns outside the realm of object oriented programming. Do you have any? Do such even exist (no book, like the GoF book, must necessarily have been written, they should just be used; that is enough)?

They can be specific to some programming language(s), but general (paradigm-level) patterns are preferred, of other paradigms than the object oriented one.

share|improve this question

closed as too broad by MichaelT, GlenH7, jwenting, Bart van Ingen Schenau, gnat Jun 1 at 9:46


I think the biggest disservice the popular design pattern books did was create a whole slew of people that believed the patterns only apply to object oriented languages. Creational patterns are debatable, but pretty much all of the others can and are implemented in none object orient languages all the time. I am sure this side effect was not the author's intention, it a side effect none the less. –  Pemdas Apr 12 '11 at 23:28
Well, objects are a design pattern in non-OO languages :) –  back2dos Apr 13 '11 at 10:44
even worse, pattern books created an entire class of people who believe any and every problem should be solved by applying a specific pattern (usually the last one they were taught by some school teacher who himself believes the same). –  jwenting May 31 at 0:45
add comment

10 Answers

"Design pattern" is actually an euphemism for "workaround". The design patterns were invented to work around shortcomings and flaws in OO languages. For example take the iterator pattern which eventually led to the introduction of the collections in Java. Groovy got rid of many more patterns by converting them into language features: You no longer need the decorator pattern because you can add methods to existing classes in Groovy.

This means you can find design patterns everywhere. In fact every "best practice" can be considered a simple form of a design pattern.

share|improve this answer
Agreed! From Paul Graham: "For example, in the OO world you hear a good deal about "patterns". [...] When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write." –  Andres F. Mar 2 '12 at 14:33
I disagree with a design pattern being a workaround. The two are opposites. A workaround is a short-term patch put together to bypass a specific obstacle. Design patterns are long-term re-usable solutions. The decorator pattern's purpose is to add functionally 'without' modifying the class. You can put different decorators on an object without the object knowing about it. –  Despertar Jul 8 '13 at 5:41
The reason why patterns are considered a "workaround" is because decorating an object should be a feature of the language. Instead, we have to write many, many lines of code to implement this. As an example, the iterator pattern has become part of many modern language. For older OO languages, you need to jump through a couple of hoops to simulate them. –  Aaron Digulla Jul 8 '13 at 8:34
@AaronDigulla I don't see why you think a pattern like the decorator is such a heavy-weight implementation; you're talking about a few lines of code. A class contains another class and forwards requests to it with some added functionality. It uses inheritance and composition in a way that makes calling a decorated object equivalent to calling the object itself. I consider this transparency to be a strength. This allows you to swap out decorators at runtime. When you say that groovy doesn't need decorator because it can add methods TO a class it sounds like you are missing the point. –  Despertar Jul 9 '13 at 3:14
The Iterator pattern has not been replaced by any new language feature in modern languages. It just comes with a default implementation for common collections. Just because it has a default implementation does not mean the pattern is not being used. If you write your own collection you would have to implement it yourself. –  Despertar Jul 9 '13 at 3:40
show 1 more comment

LtU mentions that Jeremy Gibbons is writing a book on patterns in functional programming. Check out Mr. Gibbon's Patterns in Functional Programming blog for a few teasers. Note he recommends reading his posts from oldest-to-newest.

His paper Design Patterns as Higher-Order Datatype-Generic Programs (pdf) functionally models the Gang of Four patterns: Composite, Iterator, Visitor, and Builder. He describes the patterns of programming with recursive equations in Origami Programming (folds and unfolds).

share|improve this answer
add comment

Actually it is paradox - one of most popular Non-OO patterns is... "Class".

Because OO was invented in non-OO languages, developers had to simulate it (and they're doing it even right now) - so the pattern was born. LISP and C are examples of this.

But take my advice: Don't do common mistake - don't use patterns only because it is cool, you need serious reasons to justify use of pattern (at least OO ones).

Take Command pattern for example - although it's nice & it decouples caller from receiver, it shouldn't be used unless you actually need that - because operations should be expressed using verbs - which means methods. And using commands all the place you would end up with a bunch of completely-decentralized OO-lambdas -> same would be true for a lot of Strategies.

share|improve this answer
add comment

There are SQL design patterns.

And some functional design patterns exist as well - see here for scala.

share|improve this answer
add comment

Instead of naming non-oo design patterns I would like to give you a few examples of books that have many design patterns (in them some patterns will still be OO specific):

Hope this helps

share|improve this answer
These are the ones I would recommend also, plus Hohpe & Woolf's Enterprise Integration Patterns. –  TMN Apr 13 '11 at 12:33
Fowler's patterns are highly OO :) –  David Conde Apr 14 '11 at 15:54
@David Conde :) Most of them are pure OO, All of them are written down in an OO way, but some of them also apply to non OO : look at "Web presentation patterns" , "Session state patterns" , "Distribution patterns" –  KeesDijk Apr 14 '11 at 17:52
add comment

In functional programming (especially Haskell), there are a lot of patterns and idioms that don't map very well to OOP. Phantom types are a well-known example, and you can find lots more on the haskell wiki page on Idioms.

share|improve this answer
add comment

Modular programming is quite popular for numerical libraries and math-heavy applications (numerical software is notoriously hard to model using the Object Oriented patterns, mostly because there is very little you can encapsulate).

share|improve this answer
Used in J.S. & "pure C": en.wikipedia.org/wiki/Module_pattern –  umlcat May 1 '12 at 20:28
add comment

A good example of non-OOP patterns is my absolute favourite pattern catalog: Organizational Patterns of Agile Software Development, by James O. Coplien. This book isn´t about software patterns, is about people, a catalog for creating successful teams. Every manager should read this book!

share|improve this answer
add comment

I like to think of Data Strucutres such as Queues, linked Lists, Trees, graphs, etc as patterns. They define certain patterns to store data and process them. They may seem primitive as compared to Gang of Four's more high end patters but they are patterns nevvertheless. I mean, what would happen if someone implemented a stack as a FIFO instead of a LIFO and vice versa for a queue and named them otherwise?

share|improve this answer
add comment
