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.

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

7

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.
–
PemdasApr 12 '11 at 23:28

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).
–
jwentingMay 31 '14 at 0:45

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.

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

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

6

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.
–
DespertarJul 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 DigullaJul 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.
–
DespertarJul 9 '13 at 3:14

1

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.
–
DespertarJul 9 '13 at 3:40

@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"
–
KeesDijkApr 14 '11 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).

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?