Why is an anemic domain model considered bad in C#/OOP, but very important in F#/FP?
Posted
by
Danny Tuppeny
on Programmers
See other posts from Programmers
or by Danny Tuppeny
Published on 2013-06-28T17:02:06Z
Indexed on
2013/06/28
22:28 UTC
Read the original article
Hit count: 304
In a blog post on F# for fun and profit, it says:
In a functional design, it is very important to separate behavior from data. The data types are simple and "dumb". And then separately, you have a number of functions that act on those data types.
This is the exact opposite of an object-oriented design, where behavior and data are meant to be combined. After all, that's exactly what a class is. In a truly object-oriented design in fact, you should have nothing but behavior -- the data is private and can only be accessed via methods.
In fact, in OOD, not having enough behavior around a data type is considered a Bad Thing, and even has a name: the "anemic domain model".
Given that in C# we seem to keep borrowing from F#, and trying to write more functional-style code; how come we're not borrowing the idea of separating data/behavior, and even consider it bad? Is it simply that the definition doesn't with with OOP, or is there a concrete reason that it's bad in C# that for some reason doesn't apply in F# (and in fact, is reversed)?
(Note: I'm specifically interested in the differences in C#/F# that could change the opinion of what is good/bad, rather than individuals that may disagree with either opinion in the blog post).
© Programmers or respective owner