Rule of thumb for designing data classes

[John Ryan]

Hi guys,

I was wondering if there are any well known OO principles or refactorings that indicate when you should subclass when creating a Class which is primarily a data holder. The following (poor) example illustrates my question:

Person
{
 String firstName
 String lastName
 Person[] children
 String driversLicenseNum 
}    

Typically a Person will always have a first name and last Name. However the children and driversLicenseNum fields may not always be populated. The children field will have only have values if the person is a parent. They will only have a driversLicenseNum if they have a drivers license. Does this situation where some of the attribute of Person are only populated when certain conditions are true indicate that I should subclass Person so that we have two new subclasses "Parent" and "Driver"?

Any tips you could give me on this would be much appreciated.

Thanks,
John

[Stevi Deter]

John,

As always, the answer is...it depends. What do you need the class to do?

It's generally safe to include in your base class attributes that are likely to be common to any subclasses. In your example, it's true that many people are not parents, but it's fairly standard that a person can be a parent. In uses of the class where it matters, you simply check if the person has any children or not and go from there.

You want to be careful not to make your class differentiation too limiting in its distinctiveness. For example, if you create a base Person, and subclasses Parent and Driver...can a Parent ever be a Driver?

Always go back to your problem domain and figure out what level best captures what you're trying to do. And there's not always fast and hard answers, which is why sometimes OOAD sometimes feels more like an art than a science.

As an aside, in your sample class, you'll probably want to use a Collections class rather than an array for your children. You get a lot more flexibility out of the right Collection.

[Pat Farrell]

'stevi is right, it depends on your domain, and details.

There have been arguments about the 'right way' to do this since DBMS were invented, it predates OO by decades.

Whatever you do, plan on changing it. Make the user code access through business objects specific to the domain, and hide all the details there.

[Ilja Preuss]

Depending on how much flexibility you need, you might also want to take a look at the Role Object design pattern. Using that pattern, a Person could have different roles, two of them being the ParentRole and the DriverRole.

Also keep in mind that pure data classes are a code smell. That is, sometimes they make sense, but the way to bet is that you would be better of with objects that are defined by their behavior instead. Be prepared to move operations to the Person class - watch out for Feature Envy. http://c2.com/cgi/wiki?FeatureEnvySmell