Non-OOP Design Patterns?

Question

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.

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
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 '14 at 00:45

score 27 · Accepted Answer · answered Apr 12 '11 at 22:27

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. – user6039980 Nov 28 '18 at 12:30 — user6039980, Nov 28 '18 at 12:30

score 11 · Answer 2 · edited May 30 '22 at 16:27

11

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

edited May 30 '22 at 16:27

ljrk

103
4

answered Nov 09 '11 at 08:15

Aaron Digulla

2,865
21
22

10

Agreed! From [Paul Graham](http://www.paulgraham.com/icad.html): _"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 02 '12 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 Jul 08 '13 at 05: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](http://en.wikipedia.org/wiki/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 08 '13 at 08: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 09 '13 at 03:14
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 Jul 09 '13 at 03:40
@Despertar: Please read the article from IBM's Developer Works that I link to in my post. It explains what I'm talking about in much more detail than I can in a comment. – Aaron Digulla Jul 09 '13 at 14:19
OOP can be applied also in C language. – user6039980 Nov 28 '18 at 12:33
This answer is IMHO way too single edged - just because *some* design patterns are replaced by language features in some modern languages, they are **all** workarounds? That line of argumentation is as wrong as the argument in the linked article about the strategy pattern - just because you can implement strategies sometimes without using classes by utilizing higher order functions, "strategy pattern" has not become superfluous. – Doc Brown Dec 24 '18 at 17:15
@DocBrown See https://en.wikipedia.org/wiki/Design_Patterns#Criticism – Aaron Digulla Jan 25 '19 at 12:31
@AaronDigulla: IMHO that Wikipedia passage is clearly marked as opinionated, not as a generally accepted consensus. Moveover, it does not say "all design patterns are workarounds", it says "~2/3 of them have been interpreted that way by some experts", which is IMHO a way more careful wording. – Doc Brown Jan 25 '19 at 12:59
@DocBrown Why do you need a design pattern? Because there is no simpler / more obvious way in this language to achieve the desired effect. Hence is must be shortcoming / design flaw of the language. It's a flaw because a lot of people need this effect - otherwise, no one would bother to design a pattern for it. QED. – Aaron Digulla Jan 28 '19 at 16:08
@AaronDigulla: your "proof" is flawed. There are gazillions of problems for which there is no "in-built command" in any programming language, and it makes not much sense to have a special "language element" for each of these problems. In fact, lots of problems are simply not to be solved best at the language level directly. – Doc Brown Jan 28 '19 at 21:05
@AaronDigulla: your link is broken, sadly. – haylem Oct 22 '21 at 17:40
1

@haylem Try this one: https://web.archive.org/web/20140307182640/http://www.ibm.com/developerworks/java/library/j-eaed7/index.html -- I've also proposed an edit to the original post. – ljrk May 23 '22 at 14:59
See also: https://stackoverflow.com/questions/1579162/are-design-patterns-really-language-weaknesses – Aaron Digulla May 30 '22 at 16:31

score 11 · Answer 3 · answered Apr 14 '11 at 14:47

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

score 11 · Answer 4 · edited Oct 22 '21 at 13:58

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.

score 10 · Answer 5 · answered Apr 12 '11 at 20:36

10

There are SQL design patterns.

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

answered Apr 12 '11 at 20:36

Oded

53,326
19
166
181

1

The scala link is broken – corvus_192 Apr 20 '17 at 17:16

KeesDijk · Answer 6 · 2011-04-12T20:57:44.490

8

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

Look at the POSA Books for examples in software architecture
- Distributed computing
- Patterns for Concurrent and Networked Objects
- Patterns for Resource Management
Fowlers patterns of enterprise architecture with on-line catalog
xUnit Test patterns with website
And of course where patterns originated : Christopher Alexander's timeless way of building

Hope this helps

edited Apr 12 '11 at 20:57

answered Apr 12 '11 at 20:51

KeesDijk

8,918
4
35
41

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

score 2 · Answer 7 · answered Apr 13 '11 at 10:29

2

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.

answered Apr 13 '11 at 10:29

yatima2975

216
1
3

score 1 · Answer 8 · answered Mar 02 '12 at 14:11

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!

score 1 · Answer 9 · answered Apr 15 '11 at 05:59

1

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

answered Apr 15 '11 at 05:59

quant_dev

5,117
2
22
26

Used in J.S. & "pure C": http://en.wikipedia.org/wiki/Module_pattern – umlcat May 01 '12 at 20:28

DPD · Answer 10 · 2011-04-13T12:38:38.713

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?

Non-OOP Design Patterns?

10 Answers10

Linked