Prefira a composição à herança

Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.

A herança

No livro o primeiro ponto abordado no item que vamos falar nesse resumo é sobre o perigo do uso de Herança em Classes concretas, o autor deixa claro que não é relacionado a herança aplicada a interfaces e sim a quando uma classe estende outra, isso porque quando a herança ocorre em um contexto de pacotes controlado pode ser uma boa, porém, quando a herança passa além do pacote onde foi implementada, pode ser fácil de gerarmos problemas em nossa aplicação.

Pensando Bem...

Poucos sistemas que atuei utilizam herança e talvez você também já tenha percebido algo semelhante. No geral é mais comum usarmos apenas herança em interfaces e polimorfismo. Há discussões sobre se a herança deveria ser algo a se manter, mas ainda é uma abordagem que muitos aprendem e ficam se perguntando o porque de aprender e não utilizar tanto.

Problemas...

Um dos pontos é que ao utilizar herança violamos o princípio do encapsulamento visto que a subclasse depende dos detalhes da super classe para seu funcionamento e em caso de mudanças nessas implementações o impacto seria diretamente nas classes filhas. Lembrando que há situações que são exceções e que você pode projetar uma classe pensando nessas situações, mas a questão é que é possível ocorrer isso é um ponto de atenção em projetos que certamente diversas pessoas atuarão.

Composição

Como esse é um resumo do tópico vale ressaltar que no livro ele cita exemplos e mais problemas que podem decorrer do uso de Herança. Mas existe uma abordagem alternativa a herança que possivelmente você já viu em projetos Java!
O uso de composição de objetos, que é quando adicionamos um atributo privado que referencia a instância de outro objeto, o termo é usado dessa forma pois esse objeto será utilizado como um componente dentro da classe que esta sendo referenciado.
Isso porque na maioria dos casos, nossas classes necessitam de outras classes para realizar operações e não porque elas são subtipos de outra classe.
Além disso conseguimos projetar interfaces e comunicação especificas por classe e tratar problemas que podem ocorrer de maneira mais especifica.
Por exemplo, a Classe GerarRelatorio pode utilizar classes de uma biblioteca que gera arquivos de Excel, a nossa classe de relatório tem objetivo diferente e deseja tratar como criar o arquivo e resolver problemas que podem ocorrer de maneira específica.

Vantagens

• Permite reutilização de código;
• Permite compor um objeto com múltiplos objetos o que não é possível através de herança no Java;
• Facilidade em executar e dividir os testes;
• Flexibilidade para futuras implementações;

Atenção

Sempre é importante entender que a composição se tornará uma dependência a ser gerenciada e que é necessário garantir a consistência das dependências ao instanciar o objeto, ou seja, se sua classe A depende da classe B para fazer um processo garanta que ao instanciar a classe A seja obrigatório receber a instância da classe B.

Resumo do Resumo

Entendermos que apesar da herança ser uma abordagem muito famosa é também muito perigosa para o design de software.
O tópico do livro se concentra muito mais em falar do problemas da herança do que de fato da composição de objetos.
É aconselhado que dê preferência para composição de objetos em seus projetos Java.