Edgard Davidson

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 »

Se você é programador ou já programou utilizando OO muito provavelmente você já deve ter se perguntado qual estratégia seria a mais adequada para relacionar um objeto com outro. Pois bem, na programação orientado por objetos existem cinco formas com que os objetos podem se relacionar. São elas: herança,  agregação,  composição, associação simples ou dependência.

O objetivo deste post é descrever cada um dos tipos de relacionamento e demonstrar em quais situações você deveria usar cada um deles.

Read the rest of this entry »