Is it correct to give greater preference to composition than inheritance?

TL; DR - only use inheritance if the subtype can perfectly replace the base type. Also, reduce the responsibilities of your classes. Use composition to join multiple isolated responsibilities into a single object (i.e. add functionality ).

The rest of the answer is based on practical examples. For a more conceptual (and shorter) answer, including theoretical underpinning, see utluiz . And carlosrafaelgn's answer presents a rather interesting counterpoint.

When not to use inheritance?

The decision between using inheritance or not should be guided by the Liskov Substitution Principle , which says: "where an object of the base class can be used an object of the subclass should also be used". Maintaining this principle becomes complicated in complex inheritance relationships, as in the example below:

class Animal { }
class Cachorro extends Animal { }
class Gato extends Animal { }

class AbrigoAnimais {
    Animal obterAnimal() { }
    void adicionarAnimal(Animal a) { }
}
class AbrigoCachorros extends AbrigoAnimais {
    Cachorro obterAnimal() { } // OK
    void adicionarAnimal(Cachorro c) { } // É overload, não overrride
}

AbrigoAnimais canil = new AbrigoCachorros();
canil.adicionarAnimal(new Gato()); // Deveria ser válido, pelo princípio da substituição

The same it is observed in cases where the subclass is more restricted than the superclass:

class Retangulo {
    void atribuirLados(int altura, int largura) { }
}
class Quadrado extends Retangulo { }

new Quadrado().atribuirLados(10, 20); // Deveria ser válido, pelo princípio da substituição

In addition - not related to this principle, but also relevant - there is the problem of what to do in the presence of multiple inheritance:

interface Voador { }

class Veiculo { }

class Aviao extends Veiculo implements Voador { }
class Passaro extends Animal implements Voador { }

// Como reaproveitar a funcionalidade de Voador?

Or in cases where the interface is conflicting:

interface Foo {
    String metodo();
}
interface Bar {
    int metodo();
}

class Baz implements Foo, Bar {
    // Não é possivel, pois o que "metodo" vai retornar?
}

If your model doesn't have any of these problems, then go ahead and use inheritance! But most often (in my experience) at least one of these problems is present. In addition, the the programmer's motivation is often simply to "reuse code" - he doesn't have a clear taxonomy where the inheritance relationship is justified, he only uses it because he thinks he has to use it. It is in such cases that the composition becomes a preferable alternative.

How to solve using composition?

In the first case, one can do this by placing in the base type Only those methods that meet the substitution principle:

interface AbrigoAnimais {
    Animal obterAnimal();
}
class ImplAbrigoAnimais<T extends Animal> implements AbrigoAnimais {
    T obterAnimal() { } // OK, tipo de retorno covariante
    void adicionarAnimal(T animal) { } // Não está presente na interface
}
class AbrigoCachorros implements AbrigoAnimais {
    ImplAbrigoAnimais<Cachorro> abrigo = new ImplAbrigoAnimais<Cachorro>();

    Cachorro obterAnimal() { return abrigo.obterAnimal() }
    void adicionarAnimal(Cachorro cachorro) { abrigo.adicionarAnimal(cachorro); }
}

AbrigoAnimais canil = new AbrigoCachorros();
canil.obterAnimal(); // OK

Same thing in the second (note that it is can support both reading and writing):

interface Retangular {
    void atribuirLargura(int largura);
    void atribuirAltura(int altura);
}
class Retangulo implements Retangular {
    void atribuirLargura(int largura) { }
    void atribuirAltura(int altura) { }
    void atribuirLados(int largura, int altura) { } // Não está na interface
}
class Quadrado implements Retangular {
    Retangulo quadrado = new Retangulo();
    void atribuirLargura(int largura) { 
        atribuirLados(largura);
    }
    void atribuirAltura(int altura) { 
        atribuirLados(altura);
    }
    void atribuirLados(int valor) {  // Não está na interface
        quadrado.atribuirLargura(valor);
        quadrado.atribuirAltura(valor);
    }
}

Separation of responsibilities

Finally, I will demonstrate how separation of responsibilities can greatly help to model a complex set of entities:

interface ObjetoPosicionado { }
interface Animal extends ObjetoPosicionado { }
interface Veiculo extends ObjetoPosicionado { }

class ImplObjetoPosicionado implements ObjetoPosicionado {
    int x;
    int y;
    int z;
}
class ImplAnimal implements Animal {
    ObjetoPosicionado impl;
    int fome;
}
class ImplVeiculo implements Veiculo {
    ObjetoPosicionado impl;
    List<Pessoa> passageiros;
}

Here each class takes care of a specific aspect: one controls where the object is in space, another controls the specific attributes of the animal making use of the previous object (since a Animal is a ObjetoPosicionado), and another controls the attributes vehicle specifics (Ditto). With responsibilities in isolation, one can reuse them in a particular class taking advantage of only what is needed, and not wasting space:

class Cavalo implements Animal, Veiculo {
    ImplAnimal ia;
    ImplVeiculo iv;

    public Cavalo() {
        ObjetoPosicionado op = new ObjetoPosicionado(); // Uma única cópia...
        ia = new ImplAnimal(op);  // ...é utilizada aqui...
        iv = new ImplVeiculo(op); // ...e aqui.
    }

    // Realiza a interface de ObjetoPosicionado
    void deslocar(int x, int y, int z) {
        ia.deslocar(x,y,z); // Ou iv - dá no mesmo, pois ambos têm a mesma "impl"
    }

    // Realiza a interface de Animal
    void comer() {
        ia.comer();
    }

    // Realiza a interface de Veiculo
    void adicionarPassageiro(Pessoa p) {
        iv.adicionarPassageiro(p);
    }
}

But isn't that much code to write?

Yes! If the syntax of the language does not help, you would have to do a gymnastics baita to create models of this type, and the effort "pays off" afterwards (a clean API and efficient code). And what would be the solution? Leave "purity" aside and end inheritance at once :

class Cavalo {
    Animal comoAnimal() { return ia; }
    Veiculo comoVeiculo() { return iv; }
}

Cavalo c = new Cavalo();

//Animal a = c;
Animal a = c.comoAnimal();

I.e.: returns the "strangeness" of the original question, but you gain all the benefits of using composition minus the overhead of the extra code to make this possible. At the end of the day, it's still inheritance that you're doing - but without using its syntax/semantics, rather than composition.

Is that ideal?

No. The ideal would be for the computer to deal well with the "confusion" that is the way the human brain categorizes things ("birds fly. Ostriches are birds, only they do not fly. Planes also fly, but do not flap their wings. Rockets fly, and they don't even have wings! Ducks are birds, and they also swim. Boats do not swim, but that's almost it... Airplanes, rockets and boats are vehicles. Missiles look like rockets, but they do not carry passengers.").

In the absence of this, it remains only to create models with desirable characteristics, such as type safety. It aims to ensure that "like-minded" entities can be treated as a single type - by substitution according to the principle cited at the beginning of the answer. If you don't have that security, what's the point of having an object that can or can't fulfill the class contract?

In the end, what matters to the programmer is that a certain object has a certain desirable functionality. That is, conceptually um carro é um veículo, but pragmatically um objeto carro possui a funcionalidade de um objeto veículo.