Many small classes vs. logical (but) intricate inheritance

Question

I'm wondering what is better in terms of good OOP desing, clean code, flexibility and avoiding code smells in the future. Image situation, where you have a lot of very similar objects you need to represent as classes. These classes are without any specific functionality, just data classes and are different just by name (and context) Example:

Class A
{
  String name;
  string description;
}

Class B
{
  String name;
  String count;
  String description;
}

Class C
{
  String name;
  String count;
  String description;
  String imageUrl;
}

Class D
{
  String name;
  String count;
}

Class E
{
  String name;
  String count;
  String imageUrl;
  String age;
}

Would it be better to keep them in separate classes, to get "better" readability, but wit many code repetitions, or would it be better to use inheritance to be more DRY?

By using inheritance, you will end up with something like this, but class names will lost it contextual meaning (because of the is-a, not has-a):

Class A
{
  String name;
  String description;
}

Class B : A
{
  String count;
}

Class C : B
{
  String imageUrl;
}

Class D : C
{
  String age;
}

I know inheritance is not and should not be used for code reuse, but I don't see any other possible way how to reduce code repetition in such case.

Answer 1

The general rule reads "Prefer delegation over inheritance", not "avoid all inheritance". If the objects have a logical relationship and a B can be used wherever an A is expected, it is good practice to use inheritance. However, if the objects just happen to have fields with the same name, and have no domain relationship, do not use inheritance.

Quite often, it pays off to ask the question of "reason of change" in the design process: If class A gets an extra field, would you expect that class B gets it as well? If that's true, the objects share a relationship, and inheritance is a good idea. If not, suffer the little repetition to keep distinct concepts in distinct code.

Answer 2

By using inheritance, you will end up with something like this, but class names will lost it contextual meaning (because of the is-a, not has-a):

Exactly. Look at this, out of context:

Class D : C
{
    String age;
}

What properties does a D have? Can you remember? What if you complicate the hierarchy further:

Class E : B
{
    int numberOfWheels;
}

Class F : E
{
    String favouriteColour;
}

And then what if, horror upon horrors, you want to add an imageUrl field to F but not E? You cannot derive it from C and E.

I've seen an actual situation where a lot of different Component types all had a name, an ID and a Description. But this wasn't by the nature of their being components, it was just a coincidence. Each had an ID because they were stored in a database. The name and description were for display.

Products also had an ID, Name and Description, for similar reasons. But they weren't components, nor were components products. You would never see the two things together.

But, some developer had read about DRY and decided he'd remove every hint of duplication from the code. So he called everything a product and did away with the need to define those fields. They were defined in Product and everything that needed those fields could derive from Product.

I cannot say this strongly enough: This is not a good idea.

DRY is not about removing the need for common properties. If an object is not a Product, don't call it a Product. If a Product doesn't REQUIRE a Description, by the very nature of its being a Product, do not define Description as a Property of Product.

It happened, eventually, that we had Components without descriptions. So we started having null Descriptions in those objects. Not nullable. Null. Always. For any Product of type X ... or later Y ... and N.

This is an egregious breach of Liskov Substitution Principle.

DRY is about never putting yourself in a position where you might fix a bug in one place and forget to do it somewhere else. This isn't going to happen because you have two objects with the same property. Never. So don't worry about it.

If the context of the classes makes it obvious that you should, which will be very rare, then and only then should you consider a common parent class. But, if it's properties, consider why you're not using an interface instead.

Answer 3

Inheritance is way to achieve polymorphic behavior. If your classes don't have any behavior, then inheritance is useless. In this case, I would not even consider them objects/classes, but structures instead.

If you want to be able to put different structures in different parts of your behavior, then consider interfaces with get/set methods or properties, like IHasName, IHasAge, etc.. This will make the design much more cleaner and allow better composition of these kind of hiearchies.

Answer 4

Isn't this what interfaces are for? Unrelated classes with different functions but with a similar property.

IName = Interface(IInterface)
  function Getname : String;
  property Name : String read Getname
end;

Class Dog(InterfacedObject, IName)
private
  FName : String;
  Function GetName : String;
Public
  Name : Read Getname;
end;

Class Movie(InterfacedObject, IName)
private
  FCount;
  FName : String;
  Function GetName : String;
Public
  Name : String Read Getname;
  Count : read FCount; 
end;

Answer 5

You question seems to be framed in the context of a language that does not support multiple inheritance but does not specifically specify this. If you are working with a language that supports multiple inheritance, this becomes trivially easy to solve with only a single level of inheritance.

Here is an example of how this can be solved using multiple inheritance.

trait Nameable { String name; }
trait Describable { String description; }
trait Countable { Integer count; }
trait HasImageUrl { String imageUrl; }
trait Living { String age; }

class A : Nameable, Describable;
class B : Nameable, Describable, Countable;
class C : Nameable, Describable, Countable, HasImageUrl;
class D : Nameable, Countable;
class E : Nameable, Countable, HasImageUrl, Living;