Um dos princípios básico da Orientação a Objetos é a reutilização. Um dos mecanismo existentes nas linguagens OO para alcançar tal reutilização é o uso de herança. Em qualquer livro de programação orientada a objetos que você pegar para ler terá um definição de herança mais ou menos como essa “Herança é o mecanismo para estender as classes existentes adicionando novos métodos e campos”, em outras palavras, a herança é um mecanismo para aprimorar classes já existentes.
A herança é utilizada quando você tem a necessidade de implementar uma nova classe que reutiliza um conceito mais geral de uma classe já existente estiver disponível .
Entender bem o funcionamento das técnicas de OO é necessário para desenvolver aplicações escaláveis, modulares, com baixo acoplamento e alta coesão, bem como para compreender os padrões de projeto (Design Patterns), utilizado comumente no mercado.
Neste post, no entanto, o objetivo é abordar as condições para uso de herança que nos livros é falado, mas de forma “implícita”.
Antes de entrar no assunto, vale apena ressaltar o que os objetos podem representar. os objetos podem representar um papel, uma transação, ou um dispositivo, entidade ou coisa:
- Um Papel: um objeto pode representar um papel. Exemplo, Aluno, Pessoa, Funcionário, ect.
- Uma Transação: é um objeto que representa uma atividade que pode ocorrer em um determinado intervalo de tempo. Exemplo, Reserva, Venda, etc.
- Um Dispositivo, uma Entidade ou uma Coisa: o objeto pode representar uma entidade, um dispositivo ou uma coisa que tem estrutura permanente. Exemplo. Caminhão, Veículo, ect.
Para usar herança, alguns critérios devem ser satisfeitos:
- CRITÉRIO 1: A subclasse deve expressar uma relação “é um tipo especial de” e não “pode exercer o papel de”, em outras palavras, a herança NUNCA deve mudar a função da superclasse.
- CRITÉRIO 2: A subclasse deve especializar uma papel, uma transação ou um dispositivo, sem NUNCA mudar a função da superclasse.
- CRITÉRIO 3: A subclasse deve estender, e NUNCA redefinir e NUNCA anular o contrato (responsabilidade) da superclasse.
- CRITÉRIO 4: A subclasse NUNCA deve estender funcionalidades de classes utilitárias.
Read the rest of this entry »