I very much enjoy the functional programming paradigm, but I am still not sure how to go about designing a small/medium project with it.
When using OO, I have a set of labelled entities (classes) with clearly defined boundaries. I can reason about stuff like:
- what is this class doing?
- should I put this code inside or outside a class?
- should I split this class in two?
- how would a client like to use this class?
So one big benefit of classes is that they provide boundaries for a piece of functionality. I find that this helps a lot when designing an application.
In functional programming, everything seems to be about composing and abstracting functions and data structures. Type classes in haskell are mainly there to offer polymorphism. Same for prototypes in clojure.
When designing an application written in a functional style, what is a good “unit of feature” one can define, label, and reason about?
2
Actually, it doesn’t have to be that different.
You need to identify the core data structures you need to work with. (That’s what classes are in OOP). You write functions that deal with various aspects of that data structure, and group it in a module, or compilation unit.
Finally, you use the functions and data you have in other parts of your program.
Of course, the questions you’re asking sound a bit different in FP:
- What is this data structure doing? Nothing, it just is. Since you (hopefully) write code as pure as possible, only minimal parts of your code are actually doing something.
- Should I put this code inside or outside the data structure? This is merely a syntactical question. In languages like Haskell, you have no choice: outside.
- Should I split this class in two? This is a hard question, and it is independent of programming paradigm. Yet, in FP, you tend naturally to do things “bottom up”, so you start out with easy, almost trivial data and combine that into more complex.
- How would a client like to use this? Through the functions provided (same as OOP).
2