From Object Oriented Programming to Functional Programming

https://github.com/Dobiasd/articles/blob/master/from_oop_to_fp_-_inheritance_and_the_expression_problem.md

by vimes656 • 13 years ago

65 24 13 years ago

lelf2• 13 years ago

These exercises have nothing to do with expression problem.

The goal of expression problem is ability to add new cases in type and new operations on type without touching existing code (and without compromising static type safety)

seanmcdirmid4• 13 years ago

They also get the solution wrong: only OOP can define new variants and only FP can define new operations. Actually, there are plenty of language, FP and OOP, where it is easy to define new variants and new operations orthogonally without sacrificing separate compilation (e.g. any OO language with mixins like Scala). Mads published a paper [1] on some solutions back in 2004.

[1] http://lambda-the-ultimate.org/node/2232

tel9• 13 years ago

It's also easy enough to define new variants in Haskell if you package things as codata. I feel it's less to do with OOP/FP and more to do with whether you're using data or codata.

jokoon• 13 years ago

Any book that sounds like "functional programming in practice" for C++ programmers ?

tinco• 13 years ago

Perhaps the problem is that you're trying to build a class hierarchy in Haskell, when class hierarchies just don't really work in Haskell.

What about a component oriented design? This is the standard architecture for games anyway.

An enemy, actually every entity, would just be a map of components, which can be simple algebraic data types. The actions can be implemented as a system function with pattern matching or guards, like:

  -- The walking system
  walk :: Entity -> Entity
  walk e = update entity "position" $ walk' (lookup "position" entity)
  
  walk' (x,y) = (x+1,y)

In reality systems usually work on more than one component, so you'd have to make actions that work on tuples of components, but you'll figure it out :)

lelf2• 13 years ago

class hierarchies just don't really work in Haskell

They work beautifully in Haskell

  class Eq a => Ord a
  class (Num a, Ord a) => Real a

seanmcdirmid4• 13 years ago

Isn't that more a has-a than an is-a?

tel9• 13 years ago

It's more that classes just don't behave the same as `class` in an OOP sense. You can create a subtype hierarchy using typeclasses—Functor->Application->Monad->MonadPlus/Applicative is a great example and the `lens` hierarchy is an even more sophisticated one.

But these are subtype hierarchies, not subclass hierarchies. Furthermore, classes don't necessarily provide you with the full convenience of an object, though they can come close. Finally, people aren't used to working in codata and Haskell doesn't make it easy, so you have trouble there, too.

flohofwoe• 13 years ago

The proposed class hierarchy for different types of "game objects" is exactly the type of hierarchy which will bite you in the ass very soon when adding more features, an entity-component-system would be a better solution for this specific problem (composition instead of inheritance). Newbie programmers should never be taught this "animal - cat - dog" nonsense IMHO because this approach of modelling software after real-world objects doesn't work for anything slightly more complex. For instance, what if you have two different enemy types which both need to implement a common feature but differ in others? Please don't say 'multiple inheritance' ;) This doesn't mean that OOP is bad at all IMHO, just that it shouldn't be treated as a holy grail (applies to all design principles), and doesn't mean that you have to go all-functional. All IMHO of course.

From Object Oriented Programming to Functional Programming

Related Stories