Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
add comment

5 Answers 5

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.

share|improve this answer
    
Sure, reason of change is good point, but what in situation, where these classes are and always will be constant? –  user969153 Feb 14 '13 at 20:42
20  
@user969153: When the classes will truly be constant, it doesn't matter. All good software engineering is for the future maintainer, who needs to do changes. If there will be no future changes, everything goes, but trust me, you will always have changes unless you program for the trashpile. –  thiton Feb 14 '13 at 20:45
    
@user969153: That being said, the "reason of change" is a heuristic. It helps you to decide, nothing more. –  thiton Feb 14 '13 at 20:47
2  
Good answer. Reasons to change is S in uncle bob's S-O-L-I-D acronym which will help in designing good software. –  Klee Feb 14 '13 at 21:22
4  
@user969153, In my experience, "where these classes are and always will be constant?" is not a valid use case :) I have yet to work on a meaningfully sized application that did not experience totally unexpected change. –  cdkMoose Feb 14 '13 at 21:57
add comment

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.

share|improve this answer
    
Great answer, thanks! –  user969153 Feb 14 '13 at 21:24
add comment

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.

share|improve this answer
add comment

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;
share|improve this answer
add comment

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;
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.