1

I'm currently reading 'Head first design patterns' and I already have a few questions on the first chapter of the book. This chapter introduces the 'prefer composition over inheritance' design principle, by explaining the 'Strategy-Pattern'. My question isn't about the pattern, but rather about a more basic design decision in one of the examples:

There is an abstract Duck class, from which a hand full of other duck classes (like e.g. 'Rubber-' or 'Redhead-Duck') inherit. All of these ducks have a display and quack method. The display method is what should be differernt in every special duck class (because every duck looks different, as the book says).

abstract class Duck
{
    public void display();
    public void quack()
    {
        //Quack here
    }
}

class RubberDuck extends Duck
{
    @Override
    public void display()
    {
        //Display a 'Rubber-Duck'
    }
}

class RedheadDuck extends Duck
{
    @Override
    public void display()
    {
        //Display a 'Redhead-Duck'
    }
}

But my question is: Wouldn't it make much more sense to have a field inside a (non-abstract) Duck class, which contains the displaying information (a picture or a 3D-model for example) rather than inheriting from an abstract duck class?

class Duck
{
    private String duckName;
    private Picture duckPicture;

    public Duck(String name, Picture picture)
    {
        this.duckName = name;
        this.duckPicture = picture;
    }

    public void quack()
    {
        //Quack here
    }
    public void display()
    {
        //Show duck here, according to the 'duckPicture' field
    }

    //More methods here, maybe a getter for the 'duckName' field
}

What's your opinion on this? Does it make sense to have an abstract duck class and inherit from it or do you prefer the second solution?

Improve this question
2
  • 2
    looks like you are arguing duck-typing vs. inheritance... – ratchet freak Apr 6 '14 at 12:38
  • Good assumption, but in fact every duck (maybe that what reminds to duck-typing too ;) ) has a 'name' and 'model' field. It's not specified by if it has that field (or method), but moreover what value that field has. – user108376 Apr 6 '14 at 13:57
3

You have to understand that examples are almost always oversimplified to such an extent that techniques like inheritance look like overkill.

If the real-world code were of a similar complexity as the Duck hierarchy, with each class only differing in which picture/text they show, then you would have a case.

But in reality, the real-world code is much more complex, usually with at least a handful of methods that have radically different implementations across the classes. In that case, it doesn't work anymore to catch the variation in a few fields.

Improve this answer
5
  • Yeah, your're absolutrely right. Of course there are cases, where inheritance is needed and there are cases where composition is better. But in this special example: Would you go by inheritance or composition? I would choose the second approach. I would use inheritance for e.g. a 'DataReader'. It has a method that returns a data object, but the way how it get's the data differs from subclass to subclass. – user108376 Apr 6 '14 at 14:01
  • @Benjamin: The Duck hierarchy is so clearly example code that inheritance is suitable here. It might help if you mentally replace each Duck with a DataReader – Bart van Ingen Schenau Apr 6 '14 at 15:12
  • Oh, yeah I think, now I get what you mean. But at least in the book, they didn't make subclasses to kinda visualize how displaying behaviour changes from subclass to subclass (e.g. one displays the duck via DirectX and another via OpenGL), but really that another duck would just use another image. The methods would internally be complete the same. Only the picture name would be differernt. Maybe I missunderstood you again, but in fact I don't see how inheritance would be useful if only the picture name in a method would change... – user108376 Apr 6 '14 at 16:55
  • @Benjamin: Inheritance would indeed not be all that useful if the implementations are all the same, but example code is not always meant to be a good example of technique A if it is supposed to show technique B. – Bart van Ingen Schenau Apr 6 '14 at 16:58
  • Yeah I completely agree. Nevertheless I was a bit confused about it, and wanted to ask. Think all oscurities are cleared. Thanks! – user108376 Apr 6 '14 at 18:05
1

If you assume that display operation will only send rasterized image to display device, then you are right - one implementation of display method would suffice.

But, if you have an abstract method for display operation, this method can also do some implementation-specific stuff like:

  • create the image of a duck using openGL API,
  • update other fields of a duck (e.g. isDisplayed),
  • call Display on sub-objects (e.g. DuckWing),
  • etc.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy