Orientação a Objetos - Parte l

Orientação a Objetos - Parte l

Resumo

Este artigo vai abordar os pontos que com certeza será cobrado de você durante o exame referente a orientação a objetos, não de uma maneira geral, mas sim em especifico para a linguagem Java.

Poderíamos iniciar sobre a teoria sobre orientação a objetos, mas presumimos que você já tenha este conhecimento. 

Sabemos que Java é quase 100% orientada a objetos, exceto pelos seus tipos primitivos, Java suporta herança, mas não aceita herança múltipla. A ausência da herança múltipla pode ser compensada pelo usa da herança e interfaces, onde uma classe herda o comportamento da sua superclasse, alem de oferecer implementação para uma ou mais interface e permite a criação de classes abstratas. Calma gente! Já iremos explicar cada item citado, não se assuste.

Herança

Primeiramente você precisa saber que toda classe em Java é uma subclasse de Object. Olhe a Figura 01

Figura 01

Pontos importantes para ser abordado nesse simples exemplo:

• Método equals da variável de referencia h1, de onde ele veio?
• O operador instanceof (falaremos dele em breve), verifica se h1 é uma instancia de Object.

Resumindo a classe Herança do nosso exemplo é uma subclasse de Object, conseqüentemente ela herda seus métodos: equals, clone, notify, wait, finalize, toString.

Mas porque usar Herança? As razoes mais comuns do usa da herança é a reutilização de código e o uso do polimorfismo.

Um simples exemplo da reutilização de código. Veja na Figura 02

Figura 02.

Note que a classe Skate não tem o método adrenalina, porem ele herda da sua superclasse. A reutilização de código através da herança significa que os métodos mais genéricos (como adrenalina()), que poderia se aplicar a diferentes tipos de esportes radicais, não precisa ser reimplementado, ou seja você não precisaria reescrever o método.

Relacionamento “É UM” e “TEM UM”

Quando falamos de herança, você terá que ser capaz de determinar se ele mostra um relacionamento “É UM”, ou “TEM UM”. Examine o código a seguir da Figura 03.

Figura 03

O termo “É UM”, é uma forma de dizer cada objeto de uma subclasse também é um objeto da superclasse, ou seja, o objeto de um tipo de subclasse também pode ser tratada como objeto de uma superclasse. Como você pode ver no exemplo anterior, podemos dizer que:

• Carro é um Veículo
• Fusca é um Carro
• Fusca é um Veículo

Também é comum ver a seguinte conotação:

• Carro é uma subclasse de Veículo
• Carro é uma superclasse de Fusca
• Fusca é uma subclasse de Veículo

O termo “TEM UM” podemos dizer que o objeto da classe tem um ou mais objetos de outras classes como membro. Imagine a classe direção; podemos dizer então que um carro “TEM UMA” direção.

Agora preste atenção no código a seguir da Figura 04, caso tenha alguma dúvida recomendo mais estudos neste assunto que acabamos de falar.

Figura 04

Caso você tenha compreendido o relacionamento entre essas classes e chegou a seguinte definição:

• Zhar “É UM” Zoof
• Zoof “TEM UM” Choop
• Choop “TEM UM” Zhar

Parabéns, sinal que estamos indo bem.

Construtores

Definimos que todas as classes é subclasse de Object, e conseqüentemente herdará seus métodos, mas em relação aos seus construtores? Como será que funciona? Construtores são chamados em tempo de execução quando você digitar new em algum tipo de classe, ou seja, como vemos abaixo:

Cavalo c = new Cavalo( );

Veja que o objeto Cavalo passado a variável de referencia c chamou seu construtor.

Mas o que é um construtor? Você terá que estar apto identificar um construtor.

Então lembre-se disso:

• Construtor não tem retorno e seu nome deve coincidir exatamente com o nome da classe.
• Eles podem ter um dos 4 modificadores de acesso, porem os construtores marcados com o modificador de acesso private não poderá ter subclasse, ou seja impede a herança
• Você poderá encontrar métodos com o mesmo nome da classe, mas isso não é construtor, lembre-se, se houver o mesmo nome da classe e tiver retorno é MÉTODO.

Observe o código da Figura 05.

Figura 05

Quando uma classe não tiver um construtor declarado explicitamente a JVM criará um construtor default. Construtor default é construtor criado JVM e não necessariamente um construtor sem argumentos.

Então no código da Figura 05 não compilará, pois será criado um construtor default na classe B. A classe A não tem um construtor defaut declarado, lembre-se a JVM somente criará um construtor se você não criar nenhum, então a classe B irá lançar um erro de compilação, pois ela irá invocar o construtor da classe A que recebe um int como parâmetro.

O código correto seria assim, veja na Figura 06.

Figura 06.

Veja que no código da Figura 06 na classe B houve uma chamada explicita com a chamada a super( )  passando o argumento corretamente. Como você viu podemos invocar o construtor da superclasse com a chamada a super( ). Podemos também chamar o construtor da mesma classe a chamada a this( ).

Uma regra importante. A primeira linha de um construtor deve ser a chamada a super( ) ou a this( ), nunca os dois juntos. O construtor que tiver a chamada a this() a JVM não chamará a super( ).

Veja como se comporta a pilha de construtores.

Resumo da pilha de construtores é o seguinte.

Todo construtor chama o construtor da sua superclasse com a chamada implícita a super( ), na não ser que o construtor chame um construtor sobrecarregado. Construtores sobrecarregado é usado para fornecer várias maneiras de instanciarem objetos de uma classe.

Mais um detalhe importe é que classes abstratas têm construtores, e eles são chamados quando uma subclasse concreta é instanciada.

Interface não tem construtores.

Um construtor só pode ser chamado a partir de outro construtor, ou seja, você não pode chamar um construtor diretamente de um método.

Obrigado a todos, na próxima parte deste artigo continuaremos falando sobre polimorfismo, varáveis de referencia, sobrescrita e sobrecarga de métodos e os demais detalhes que é abordado na prova sobre Orientação a Objetos.

Até mais

Fabiano Fernandes