4

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?

Improve this question
2
  • 6
    Classes are nothing but poor man's modules. Take a look at, say, SML module system, or even OCaml. They're providing much more powerful approach to encapsulation than anything you'll find in the pure OO languages.
    – SK-logic
    May 2 '13 at 11:37
  • OOP isn't mutually exclusive with FP. Consider clojure or the Common Lisp Object System
    – user40980
    May 2 '13 at 18:21
8

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).
Improve this answer
2
  • +1 good answer, one thing to drive home is that instead of with a class having data and functions for dealing with that data in a type, with functional you have types and functions that deal with those types together in a module. This way the functions aren't trapped inside of a given type, and more functions for those types can be separated into other modules away from the initial types.
    – Jimmy Hoffa
    May 2 '13 at 17:15
  • accepting this answer, but part of what I was looking for is is SK-logic comment
    – Simon Bergot
    May 6 '13 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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