Heran�a versus Composi��o: qual utilizar?

Introduç�o

Primeiramente � necess�rio entender o que � Composiç�o e o que � Herança. Composiç�o e Herança s�o dois mecanismos para reutilizar funcionalidades.

A herança sempre foi considerada uma ferramenta b�sica de extens�o e reuso de funcionalidade e se d� estendendo atributos e m�todos de uma classe.

Segue abaixo um diagrama de classe exemplificando o uso de Herança.

Figura 1: Exemplo de Herança

O diagrama de classe acima seria implementado em Java conforme o c�digo na listagem abaixo:

Listagem 1: Exemplo de herança de classes em Java.

public class Animal {

}

public class Cachorro extends Animal {

}

public class Gato extends Animal {
	
}

Acima tem-se a definiç�o de Animal que � a superclasse e das classes Cachorro e Gato que herdam tudo da classe Animal. Neste exemplo na classe Animal n�o tem nada, por�m se tivesse atributos ou m�todos eles seriam Herdados pelas suas subclasses Cachorro e Gato. Vale salientar que devemos atentar para a visibilidade dos atributos e m�todos no caso da Herança, lembre-se que tudo que � privado n�o � herdado, pois pertence unicamente � classe detentora.

Na herança temos o conceito de uma Classe Pai, Classe Base ou Superclasse (todas essas nomenclaturas denotam a mesma coisa) que � a classe que foi herdada pelas subclasses. A Classe Filha ou Subclasse � a classe que herda da classe Pai. Outros dois conceitos que temos na Herança � a Generalizaç�o onde se obt�m similaridades entre classes e dessa forma define-se novas classes. As classes mais gen�ricas s�o as classes Pai. E a Especializaç�o � onde Identifica-se atributos e m�todos n�o correspondentes entre classes distintas colocando-os na classe filha. Ou seja, quando se tem similaridades entre as classes procura-se generaliz�-las levando suas similaridades para a classe pai onde as classes filhas ir�o herdar essa similaridade. Por outro lado quando temos atributos e m�todos n�o correspondentes nas classes filhas colocamos essas n�o correspond�ncias nas classes filhas mais espec�ficas que ir�o usar esses atributos e m�todos. Normalmente na Herança usamos o termo "� um". Por exemplo, podemos dizer que um carro � UM autom�vel, portanto temos que um carro herda os atributos e m�todos de um autom�vel, assim como um caminh�o tamb�m � UM autom�vel. Neste exemplo temos uma hierarquia de herança onde um Carro e um Caminh�o herdam atributos e m�todos comuns entre eles que est�o definidos numa superclasse Automovel. Para o exemplo acima a herança tamb�m � v�lida pois Cachorro � UM Animal e Gato tamb�m � UM Animal.

A composiç�o por sua vez estende uma classe pela delegaç�o de trabalho para outro objeto. Na composiç�o ao inv�s de codificarmos um comportamento estaticamente, como � feito com o uso de herança, definimos pequenos comportamentos padr�o e usamos composiç�o para definir comportamentos mais complexos. Na composiç�o agora podemos mudar a associaç�o entre classes em tempo de execuç�o, assim um objeto pode assumir mais de um comportamento.

O Diagrama de classe abaixo mostra um exemplo de composiç�o onde um Sistema � composto de uma Pessoa.

Figura 2: Exemplo de composiç�o

O diagrama de classe acima seria implementado em Java conforme o c�digo na listagem abaixo:

Listagem 2: Exemplo de composiç�o em Java.

public class Sistema {

	Pessoa pessoa = new Pessoa();
	
}

public class Pessoa {
	
}

Na composiç�o temos uma inst�ncia da classe existente sendo usada como componente da outra classe. A composiç�o usa o termo TEM UM. Por exemplo, podemos dizer que um carro TEM UM pneu, neste exemplo temos a definiç�o de uma composiç�o.

Benef�cios e Problemas da Herança

Um dos benef�cios da Herança � que ela captura o que � comum e o isola daquilo que � diferente, al�m disso, a herança � vista diretamente no c�digo at� mesmo devido a sua natureza est�tica.

Entre os problemas da Herança est� o fraco encapsulamento entre classes e subclasses e o forte acoplamento entre elas onde ao mudar uma superclasse pode afetar todas as subclasses al�m de violar o princ�pio b�sico de projeto OO em que devemos ter sempre um baixo acoplamento entre as classes. Al�m disso, algumas vezes um objeto precisa ser de uma classe diferente em momentos diferentes o que n�o � poss�vel com a herança, pois o c�digo n�o pode sofrer alteraç�es facilmente em tempo de execuç�o, portanto tem-se que a herança � um relacionamento est�tico.

Benef�cios e Problemas da Composiç�o

A grande vantagem da Composiç�o � que o comportamento pode ser escolhido em tempo de execuç�o em vez de estar amarrado em tempo de compilaç�o. Al�m disso, os objetos que foram instanciados e est�o contidos na classe que os instanciou s�o acessados somente atrav�s de sua interface seguindo assim o princ�pio de programar para uma interface e n�o para uma implementaç�o. A composiç�o tamb�m apresenta uma menor depend�ncia de implementaç�es e temos cada classe focada em apenas uma tarefa seguindo outro principio da responsabilidade �nica. Por fim, a composiç�o tamb�m tem um bom encapsulamento onde os detalhes internos dos objetos instanciados n�o s�o vis�veis.

A grande desvantagem � que um software muito din�mico e parametrizado � mais dif�cil de entender do que software mais est�tico.

Quando usar Composiç�o ou Herança

De forma geral prefira utilizar sempre a Composiç�o em relaç�o � Herança, no entanto pode-se definir algumas regras para identificar quando podemos usar a Herança de forma que n�o tenhamos os problemas que ela acarreta. Utiliza-se a herança se uma inst�ncia de uma classe Filha nunca precisar tornar-se um objeto de outra classe, se a hierarquia de herança representar um relacionamento "� um" e n�o um relacionamento "Tem um", se deseja-se ou precisa-se realizar alteraç�es globais para as suas classes filhas alterando uma classe Pai, ou ent�o quando a classe filha estender ao inv�s de substituir total ou parcialmente as responsabilidades da classe Pai.

Conclus�o

De forma geral a herança deve ser pouco utilizada. Atualmente a composiç�o � considerada muito superior � herança na maioria dos casos pois entre as suas principais vantagens a composiç�o permite mudar a associaç�o entre classes em tempo de execuç�o, os objetos podem assumir mais de um comportamento, os projetos s�o mais simples e reutiliz�veis, al�m de descartar os problemas envolvendo a herança como o acoplamento entre as classes e outros problemas discutidos. A composiç�o � utilizada em diversos Padr�es de Projetos comprovando assim a sua grande utilidade e uso no desenvolvimento de projetos melhores.

Bibliografia

Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra. Head First Design Patterns. O'Reilly Media, 2004.