I'm currently reading 'Head first design patterns', and already the first chapter threw some questions towards me.This chapter introduces the 'prefer composition over inheritance' design principle, by explaining the 'Strategy-Pattern'. My question isn't about the pattern, but about a much more 'simple' thing.In the book there is an abstract Duck class, from which a hand full of other duck classes are (like e.g. 'Rubber-' or 'Redhead-Duck') inheriting.All of these ducks got 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 do you think about this? Does it make sense to have a abstract duck class and inherit from it or would you prefer my second attempt?
Inheritance vs 'specification' by fields
design patterns;inheritance;composition;strategy
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.