Why is an anemic domain model considered bad in C#/OOP, but very important in F#/FP?
- by Danny Tuppeny
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).
