Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

OO programming literature is full of design patterns. Most books on object oriented programming dedicate a chapter or two to design patterns like factories and decorators. So what are the equivalent patterns in functional languages and why hasn't anyone written a book about them yet? Is there something special about functional languages that obviates the need for design patterns?

share|improve this question
There are definitely functional design patterns - take memoisation or monads for example - I'm also wondering if anyone has gathered them in one place though... –  FinnNk Jul 3 '11 at 7:58
FinnNk Monad is more of a type class than a design pattern ^_^ –  alternative Jul 4 '11 at 13:14
For haskell, Gabriel Gonzalez has some blog posts, for example haskellforall.com/2012/08/the-category-design-pattern.html –  bennofs Apr 16 at 12:51

5 Answers 5

up vote 18 down vote accepted

OO and functional programming are two very different programming paradigms, and design patterns (DP) is a significant part of OO design and programing. DP do not have such role in functional programming.

One could even say, that DP are not needed in functional programming -- there is no itch which DP is cure for.

share|improve this answer
I'm not sure I would agree that design patterns don't apply to FP. FP still presents common problems that get solved in particular, common ways. Different problems to those solved in OO, but still problems nevertheless. I think it's probably just something that's been given a lot less attention than in OO, since FP is less common in the commercial world at the moment. –  d11wtq Mar 23 '13 at 10:21
To claim that design pattern doesn't exist in functional programming is misinformation. Easiest counter-example is the monad. You do not need to use monad in functional programming, but it is a very common pattern people follow to facilitate application of pure function programming. That in essence is the definition of design pattern. –  voidvector Jul 7 at 4:22

Jeremy Gibbons is writing the book. Until it's finished, you can read his blog, Patterns in Functional Programming. He recommends reading his posts from oldest to newest.

Browse his publications as well. He covers Gang of Four patterns in Design Patterns as Higher-Order Datatype-Generic Programs and describes the patterns of programming with recursive equations in Origami Programming (folds and unfolds).

share|improve this answer

The simple fact is that many OO Patterns would be considered Idioms in functional languages (especially the original GoF patterns). For instance the Iterator pattern (built-in to languages like C# now) just isn't necessary in a Lisp or ML which has sequence operators.

A lot of the patterns we use in O-O systems are there to help us get the "non essentials" out of the way so we can focus on coding objects. In other words, the patterns are solutions to the non-interesting parts of the application. We should leverage patterns to address common needs that have been solved before (like the patterns in Fowlers Patterns of Enterprise Application Architecture for dealing with things like database transmission, or xUnit Patterns for boosting your unit testing) so that we can focus on adding business value for the application.

I'm sure that beyond the specifics of the GoF patterns, there are design patterns that will be applicable to functional programming as well. The thing is that O-O is the dominant paradigm. Writing a pattern book that targets functional developers...well frankly won't get a greenlight from a publisher. That's what it boils down to. There isn't enough of a market for Functional Patterns to have a significant number of books dedicated to the topic.

share|improve this answer

FP offers a mental model for dealing with problems that is simpler than OOP's. Classes and objects are inherently more sophisticated than functions. There are a thousand ways to design a class interface.

A function, on the other hand, is on the surface always just a function. What varies from an interface perspective are its arguments and output. This model is blissfully simple. Even your tools are nothing more than functions that allow us to curry, compose and construct new functions. And from these simple building blocks, we build applications. More sophisticated approaches and patterns are unnecessary.

Granted: problems all start looking like nails, but the hammer is amazing. Its the hardly ever needing something other than your hammer that makes the paradigm so charming.

share|improve this answer

Insofar as the design methodology for FP is to design your types to accurately reflect the problem space and the implementation should follow automatically, the FP equivalent of a book on design patterns is something like Chris Okasaki's Purely Functional Data Structures.

share|improve this answer
Okasaki's book is the equivalent of the data structure part of numerous data structure and algorithms books which usually consider only mutable data structure. –  AProgrammer Jul 3 '11 at 7:47
I don't think equating data structures to design patterns fits the bill. It's not like OO programmers just flail their arms until the proper class definitions pop up. –  davidk01 Jul 3 '11 at 7:53
Yes, Okasaki's book is at a lower level than design patterns. –  FinnNk Jul 3 '11 at 7:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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