2

There are claims that OOP design patterns are irrelevant in functional languages. Are there code demos how each pattern can be implemented in Haskell? In particular, complete demo would also have to show how to represent objects, OO polymorphism etc.

Rumca
  • 1,809
  • 12
  • 17
  • 2
    You could certainly represent OO-style objects, covariant polymorphism etc. in Haskell, but it would basically amount to making an OO [eDSL](http://en.wikipedia.org/wiki/Embedded_domain-specific_language#Usage_patterns) within Haskell's syntax. It's just [a bad idea to even start with thinking about OO design patterns](http://stackoverflow.com/questions/20184286/object-oriented-programming-in-haskell), you should instead start with thinking about a specific _problem_ and what solutions it might have. In OO, a design pattern might pop out, in Haskell it will be something completely different. – leftaroundabout Feb 02 '14 at 00:11
  • 3
    They are *irrelevant*. Why would you want to represent the irrelevant things? – SK-logic Feb 02 '14 at 01:01

2 Answers2

5

I think part of the claim of 'irrelevance' is more due to the incompatibility of pure object-oriented concepts with pure functional programming.

In some ways, they are both concepts designed to solve the same problem - that of code management, for programmers, and keeping 'state' organised somehow.

OOP solves this by trying to isolate each kind of state into a separate object, and then having smart objects talk to one another (through methods, interfaces, etc).

Pure functional languages solve this by breaking the problems down into very very minimal functions, and having the data fairly dumb. A function cannot access, edit or change anything which is is not specifically given as an argument, and what it does with those things can only be seen in what it returns.

Take the singleton pattern, for example.

In OOP, to solve the problem of a global variable, say a database connection, the singleton pattern says that you store all database connection information in that one object, and then only allow it to be initialised once, then whenever it is initialised, all over the codebase, that same object 'appears' and uses the same variables.

In haskell/functional programming, the whole structure of the program will be different. You instead isolate the database connection functions to only happen in one part of the code.

You could apply the same thing in an OOP type language, but it's a lot more awkward, and the language design doesn't encourage it.

Daniel Fairhead
  • 1,103
  • 9
  • 9
0

FP and OOP try to solve the same problems with different approaches. The GoF simply don't apply, as they are OOP patterns. You would be better served by reading something like "The Craft of Functional Programming" or "Learn You a Haskell For Great Good" in order to see how problems are solved functionally.

I personally think that the two approaches both contribute useful things, and am a very big fan of Haskell's type classes and completely polymorphic functions...the simplicity and ability to by DRY can be simply amazing. That said, Scala does a great job of joining the two approaches into a single language, so that you can use either approach, depending on which seems to suit the problem better.

Tony K.
  • 5,535
  • 23
  • 27