Is this a known pattern?

Question

I am trying to separate behaviour from data completely in my classes and came up with this simple solution:

class ClassAData
{
    public int Property1;
    public string Property2;
    public bool Property3;
}

class ClassA : SomeInterface
{
    public ClassAData Data;

    //behaviour
    public int CalculateSomething(int value)
    {
        ...
        return result;
    }
    public string SomeOtherMethod(){...}           
}

(proper encapsulation would of course be applied...)

I was wondering if this is known by something or used in a common pattern? Also what are the shortcomings if there are any?

Edit: Perhaps I should have been clearer about where I intend to use this. I do not advocate using this for every class in every situation. I plan to use this in a service-oriented application where ClassA is the actual domain object and ClassAData would be a DTO that is transferred between the service and presentation layers. This approach avoids a fair bit of code duplication especially if there are many classes with lots of properties.

Answer 1

its a known anti-pattern - the anemic domain model see http://martinfowler.com/bliki/AnemicDomainModel.html and http://en.wikipedia.org/wiki/Anemic%5FDomain%5FModel to see what problems it can cause

Answer 2

I'm not sure why you would want to separate behavior from data. Object oriented programming specifically joins data with the behaviors associated with that data. I've personally never seen data entirely separated from behavior in the manner you are doing.

Answer 3

Strategy Pattern (or possibly the Template Pattern). Any chance you have the Head First Design Patterns book - it explains the Strategy Pattern so very well in the first chapter.

Answer 4

It's in a way a common pattern espacially if the "data" part is being generated from outer source.

I would recommend using a partial class for this approach

Answer 5

This actually kind of sounds like you're trying to separate your model from your controller, a la MVC.

Answer 6

Your object then has no methods that act on or for the object. Therefore it defeats the purpose as being object orientated. True object orientation involves properties and methods that work with the object. Otherwise you are just going to design a class that has gets() and sets().

Answer 7

What you are doing is to separate behavior from data. It is similar to the strategy pattern, with the difference that it's reversed. I would not say it's a bad idea (could be useful if your data has different storage techniques but the same behavior). As some pointed out, it has also strong connotations of MVC. I would not say, instead, that is an anemic antipattern. You do have behavior, you are just not storing data on the same class instance.

Summing up I would not condemn it, and it is similar to strategy and MVC

Answer 8

If you would change the member in ClassA to a ClassAData*, then it would be useful for keeping binary compability, or implementing shared data between objects (with e.g refcounts and copy-on-write).

As the code is written in your question, I really see no upside to it, that could not also be provided by godd code formatting and comments.