Chapter 1. Functional Patterns – the Building Blocks
Software design patterns were forged at a time when object oriented programming (OOP) reigned. This led to "design patterns" becoming somewhat synonymous with "OOP design patterns". But design patterns are solutions to problems, and "problems" are relative to the strengths and weaknesses of the context in which they occur. A design problem in OOP is not necessarily one in functional programming (FP), and vice versa.
From a Haskell perspective, many (but not all) of the well known "Gang of Four" patterns [Design patterns, Gamma et al.] become so easy to solve that it is not worth going to the trouble of treating them as patterns. However, design patterns remain relevant for Haskell.
"After al, as Erich Gamma said, "deja vu is language neutral" Modularity means more than modules. Our ability to de-compose a problem into parts depends directly on our ability to glue solutions together. To support modular programming, a language must provide good glue." | ||
| --Why Functional Programming Matters - John Hughes | ||
In order to have a meaningful conversation about Haskell design patterns, we'll begin our exploration by looking at the three primary kinds of "glue" in Haskell: first-class functions, the Haskell type system, and lazy evaluation. This chapter revisits the Haskell you already know through the lens of design patterns, and looks at:
- Higher-order functions
- Currying
- Recursion
- Types, pattern matching, polymorphism
- Lazy Evaluation
- Monads
