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.

  • 8
    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
    Commented Apr 12, 2011 at 23:28
  • 15
    Well, objects are a design pattern in non-OO languages :)
    – back2dos
    Commented Apr 13, 2011 at 10:44
  • 2
    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
    Commented May 31, 2014 at 0:45

10 Answers 10


Take a look in the Linux Kernel Design Patterns series. The articles are related with a non object oriented language (C) and I believe that they are well written:

  • They are using object-oriented approach though. Commented Nov 28, 2018 at 12:30

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).


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

Because OO was not 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 everywhere, you would end up with a bunch of completely decentralized OO-lambdas -> same would be true for a lot of Strategies.


"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.

  • 10
    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.
    Commented Mar 2, 2012 at 14:33
  • 7
    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
    Commented Jul 8, 2013 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. Commented Jul 8, 2013 at 8:34
  • 2
    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
    Commented Jul 9, 2013 at 3:40
  • 1
    @haylem Try this one: web.archive.org/web/20140307182640/http://www.ibm.com/… -- I've also proposed an edit to the original post.
    – ljrk
    Commented May 23, 2022 at 14:59

There are SQL design patterns.

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

  • 1
    The scala link is broken
    – corvus_192
    Commented Apr 20, 2017 at 17:16

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

  • These are the ones I would recommend also, plus Hohpe & Woolf's Enterprise Integration Patterns.
    – TMN
    Commented Apr 13, 2011 at 12:33
  • Fowler's patterns are highly OO :) Commented Apr 14, 2011 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
    Commented Apr 14, 2011 at 17:52

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.


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).


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!


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?

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