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.
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.
its a known anti-pattern - the anemic domain model see http://martinfowler.com/bliki/AnemicDomainModel.html and http://en.wikipedia.org/wiki/Anemic_Domain_Model to see what problems it can cause
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With