88

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?

6 Answers6

77

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

Corbin March
  • 8,114
63

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.

Maglob
  • 3,849
17

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.

Michael Brown
  • 21,822
15

A good talk (~45 min) on this topic by Stuart Sierra:

http://www.infoq.com/presentations/Clojure-Design-Patterns

Not necessarily binding and authoritative, but I recognized a number of his examples from my own experience using FP for data analysis.

Examples written in Clojure, but likely applicable to any FP language. The names he gives to the patterns he covers are:

  • State/Event
  • Consequences
  • Accumulator
  • Reduce/Combine
  • Recursive Expansion
  • Pipeline
  • Wrapper
  • Token
  • Observer
  • Strategy
Aaron Johnson
  • 251
8

If you're genuinely interested in learning the design patterns look no further than Haskell. If you take the time to learn the language the hard way you'll run into and get cozy with most of the foundational patterns -- they're baked into the language.

Don't skip over monads. There are a bunch of long-winded explanations out there and it takes some doing to have the ideas sink in, but if you keep plugging away, eventually it'll dawn on you and you'll be amazed at how many design patterns can be build on top of this one abstraction/interface.

Once you grok Haskell, you'll have enough of the FP arsenal at your disposal to be dangerous. Point is, keep at it until you get it. There are no shortcuts.

M. Lanza
  • 1,738
-3

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.

geekosaur
  • 731