Java com café: sobrecarga
Mostrando postagens com marcador sobrecarga. Mostrar todas as postagens
Mostrando postagens com marcador sobrecarga. Mostrar todas as postagens

Sobrescrita / Sobercarga (Overriding / Overloading) - Java

O assunto de hoje é sobre o objetivo 1.5 e 5.4 do exame SCJP. Os objetivos são basicamente determinar se um método esta corretamente sendo sobrescrito ou sobrecarregado e sobre os tipos de retorno válidos para o método.
Também fala sobre desenvolver código que declare e chame métodos sobrescritos ou sobrecarregados, e códigos que chamem construtores da superclasse sendo eles sobrescritos ou sobrecarregados.

Métodos sobrescritos

Sempre que herdamos um método da superclasse, podemos sobrescrevê-lo. Fazendo isto temos a oportunidade de determinar um comportamento específico do método para a subclasse. Então estamos dizendo "Sei que existe um método genérico herdado da superclasse para fazer isto, mas este método não me serve e quero que esta subclasse tenha o seu próprio". Tudo bem, mas não esqueça que métodos marcados como final, private ou static não são herdados e por este motivo não podem ser sobrescritos.
Para demonstrar como os métodos são sobrescritos vou usar o mesmo código que usei no tópico sobre casting:
//Superclasse
public class Animal {

void comer(){
 System.out.println("Animal comendo...");
}

}
//Subclasse
class Dog extends Animal{

void rolar(){
 System.out.println("Dog rolando...");
}
//Dog sobrescreveu o método comer
void comer(){
 System.out.println("Dog comendo...");
}
}

Dog herdou o método comer de animal mas por algum motivo teve que escrever seu próprio método comer. Então se num determinado momento quisermos chamar:
new Dog().comer();

Teremos o resultado Dog comendo.... Sem problemas.
Vamos analisar alguns casos agora. Se você herdou métodos abstratos de uma classe abstrata, então é obrigatório sobrescrevê-los (na prática você estaria implementando porque não tem nada pra sobrescrever). Mas se sua classe também for abstrata não precisa, você pode simplente "passar a vez" para a última classe concreta da árvore. Só não esqueça que em algum momento você será obrigado a sobrescrever os métodos abstract.
Uma questão interessante que também foi abordada no post sobre casting é a seguinte: Quando sobrescrevemos um método e depois fazemos o upcast, qual método será chamado? Seguindo o mesmo exemplo do código acima, se fizermos a seguinte chamada:
Animal a = new Dog();
a.comer();

Qual versão do método será executada? Sabemos que quando convertemos pra cima da árvore de herança, os métodos do subtipo são perdidos mas neste caso a versão executada será a do subtipo. Porque? O compilador só verifica o tipo da variável e não da da instância. A referência é do tipo Animal? Então só métodos de Animal poderão ser executados. Mas em tempo de execução, o objeto real que está sendo executado é Dog, então o método de Dog será chamado.
Parece confuso mas pense: Estamos criando uma referência Animal para Dog. O que o compilador vai fazer? Ele vai pensar "Vou criar um objeto tipo Dog na memória e uma variável x tipo Animal que aponte pra este objeto." A variável sendo do tipo Animal não tem conhecimento dos métodos em Dog. Acontece que quando o programa for executado a JVM vai pensar "A variável x está chamando o método em Animal, mas o objeto sobrescreveu? Então execute o método do objeto!".

Outro ponto importante é que os métodos sobrescritos não podem declarar um modificador de acesso mais restritivo do que o que foi sobrescrito. Por exemplo:
//Superclasse
public class Animal {

protected void comer(){
 System.out.println("Animal comendo...");
}

}
//Subclasse
class Dog extends Animal{

void comer(){ //Problema!!!
 System.out.println("Dog comendo...");
}
}

Declaramos o método como protected mas depois tentamos deixá-lo default. Isto não compila porque default é mais restritivo que protected. Como expliquei antes, em tempo de execução, a JVM chama a versão do método sobrescrito, e o modificador de acesso ficou mais restrito. Se ele estivesse em um pacote diferente não poderia ser chamado.
Vamos ver agora umas regras importantes:
A lista de argumentos deve se manter a mesma!. Se ela mudar o método não será mais sobrescrito e sim sobrecarregado. Lembre-se que sobrescrever não é nada mais que usar o mesmo nome do método herdado.
O modificador de acesso do novo método não pode ser mais restritivo (menos pode). Já falei sobre isto!
Métodos só podem ser sobrescritos se forem herdados. Ou seja, métodos final, private ou static não podem. E classes fora do pacote só podem sobrescrever métodos public ou protected (métodos protected são herdados).
O tipo de retorno deve ser o mesmo ou um subtipo do método original. Isto chama-se retornos covariantes ou covariant returns. Este é um assunto a parte mas apenas lembre-se que o tipo de retorno pode ser o mesmo ou um subtipo. Não tem problema em retornar um subtipo porque com certeza ele "cabe" no supertipo.
O método que sobrescreveu pode lançar qualquer exceção de tempo de execução (não verificada / unchecked), mesmo que o método original não tenha lançado.
O método que sobrescreveu não pode lançar exceções verificadas (checked) novas ou mais abrangentes que as declaras pelo método original. Este é um assunto para outro post.
Pra finalizar a parte de sobrescrita vou fazer só mais duas observações importantes: Podemos chamar a versão da superclasse do método usando a palavra chave super:
//Superclasse
public class Animal {

void comer() {
 System.out.println("Animal comendo...");
}

public static void main(String[] args) {
 Dog g = new Dog();
 g.comer();
}
}

// Subclasse
class Dog extends Animal {

void rolar() {
 System.out.println("Dog rolando...");
}

// Dog sobrescreveu o método comer
void comer() {
 super.comer(); //Chamou a versão da superclasse
 System.out.println("Dog comendo...");
}

}

E outra, mesmo não tento falado sobre exceções vou insistir em colocar uma questão aqui que poderá cobrada no exame:
//Superclasse
public class Animal {

void comer() throws Exception {
 //Lança uma exceção
}
public static void main(String[] args) {
 Animal a = new Dog(); //Referência polimórfica
 a.comer();
}
}

// Subclasse
class Dog extends Animal {

void rolar() {
 System.out.println("Dog rolando...");
}

// Dog sobrescreveu o método comer
void comer() {
 System.out.println("Dog comendo...");
}
}

Um método foi sobrescrito, mas está sendo chamado através de uma referência polimórfica (do superclasse) para apontar para o objeto do subtipo. Como vimos o compilador vai pensar que você está chamando a versão da superclasse. Mas a JVM em tempo de execução vai chamar a versão da subclasse. A versão da superclasse declarou uma exceção, mas a do subtipo não. O código não compila devido a exceção declarada. Mesmo que a versão usada em tempo de execução seja a do subtipo.

Métodos Sobrecarregados

Metodos sobrecarregados tem uma diferença básica dos métodos sobrescritos: Sua lista de argumentos DEVE ser alterada. Por este motivo, os métodos sobrecarregados permitem que se utilize o mesmo nome do método numa mesma classe ou subclasse e isto pode ser usado para dar mais opções a quem for chamar o método. Por exemplo, podemos ter um método que receba uma variável int e outro que receba double, e a pessoa que for chamar não precisará se preocupar com fazer nenhuma conversão.
Diferente dos métodos sobrescritos, os sobrecarregados podem mudar o tipo de retorno e o modificador de acesso sem restrições. Eles também podem lançar exceções verificadas novas ou mais abrangentes.
Os métodos sobrecarregados podem ser declarados na mesma classe ou na subclasse. Saber diferenciar métodos sobrecarregados dos sobrescritos é importante pra não cair em pegadinhas como:
public class Animal {

public void comer(int x, String s) {
 System.out.println("Animal comendo...");
}
}

class Dog extends Animal {

protected void comer(int x, float s) {
 System.out.println("Dog comendo...");
}
}

O código acima pode parecer violar uma das regras de sobrescrita (modificador mais restritivo) porém ele está é sobrecarregando pois houve mudança na lista de argumentos.
Uma questão importante em métodos sorbrecarregados é: Qual método será chamado? Isso vai depender exclusivamente dos argumentos passados. Por exemplo, no caso anterior se você chamar:
new Dog().comer(2, "a");

Vai retornar Animal comendo.... Mas e se usarmos argumentos de objetos ao invés de tipos primitivos?
public class Animal {

void teste(Animal a) {
 System.out.println("Animal");
}


public static void main(String[] args) {
 new Dog().teste(new Dog()); //Chamou passando um Dog
 new Dog().teste(new Animal()); //Chamou passando um Animal
}
}

class Dog extends Animal {

void teste(Dog d) {
 System.out.println("Dog");
}
}

A saída será normal, executou o método de acordo com o tipo passado:
Dog
Animal


Mas e se a referência usada fosse polimórfica:
Animal a = new Dog();
a.teste(a);

Qual versão será executada? Você poderia pensar que seria a versão de Dog, porque estamos passando uma referência ao objeto Dog. Mas não é, a saída seria Animal pois mesmo sabendo que em tempo de execução o objeto utilizado será um Dog e não um Animal, quando o método é sobrecarregado isto não é decidido em tempo de execução. Então lembre-se: Quando o método é sobrecarregado, apenas o tipo da referência importa para saber qual método será chamado.
Resumindo, o método sobrescrito a ser chamado é definido em tempo de execução e o sobrecarregado no tempo de compilação.
Então pra fechar o tópico vou dar mais uma dica: Fique atento aos métodos que parecem ser sobrescritos mas estão sendo sobrecarregados:
public class Animal {

void teste() { }

}

class Dog extends Animal {

void teste(String s) {}

}

A classe Dog tem dois métodos: A versão teste sem argumentos que herdou de Animal e a versão sobrecarregada. Um código que faz referência a Animal pode chamar somente teste sem argumentos mas uma referência a Dog pode chamar qualquer um.

Dever de casa
Dado:
class Plant{

String getName() { return "plant"; }
Plant getType() { return this; }

}

class Flower extends Plant{

 //Insira o código aqui

}

class Tulip extends Flower { }

Quais instruções, inseridas na linha comentada, irão compilar? (Marque todas corretas)
A. Flower getType() { return this; }
B. String getType() { return "this"; }
C. Plant getType() { return this; }
D. Tulip getType() { return new Tulip(); }

Construtores - Java

Hoje vou falar sobre construtores:


Construtores são esses caras que constroem as coisas, ou melhor, objetos. Não estranhe a foto que usei para ilustrar esse post, é apenas uma homenagem ao homem trabalhador. Aquele que trabalha sob o sol, pegando no pesado, para construir nossos lares e etc. Bom, mas não vamos nos desviar do assunto.
Uma coisa é verdade: toda classe em java tem pelo menos um construtor(até abstratas, enums), exceto interfaces. Decore isto.
Mas é claro que interfaces não tem construtores, elas não fazem nada! Mas não subestime-as, elas são importantes para fornecer um acoplamento fraco entre as classes. Outro dia vou abordar este assunto.

Então mais uma vez: Todas as classes (até os enums) tem pelo menos um construtor, exceto as interfaces.
Mas o que são esses construtores? Um construtor é um "método" que é executado sempre que uma classe é instanciada. Toda vez que você digitar a palavra chave new o construtor será executado e inicializará o objeto. As vezes passamos algum parâmetro tipo new (2, 2, 2) .

Quando fazemos isto estamos inicializando a classe com os dados parâmetros. O construtor serve para inicializar as variáveis de instância da classe, como também executar códigos legais toda vez que inicializar uma classe. Entenda códigos legais como coisas que você gostaria que fossem executadas toda vez que criar um objeto, ficou claro?
Vamos ver o que é um construtor na prática:
class A {
 A(){
  super(); 
  System.out.println("Executou construtor A");
  //Códigos legais aqui
 }
}

Veja que o construtor é como um método mas ele não tem um tipo de retorno, nem void. Também tem o mesmo nome da classe e sempre terá. Ele pode ter modificador de acesso, até private (mas saiba das implicações disto). O compilador criará automaticamente um construtor igual o mostrado acima caso você não codifique nenhum. Porque ele faz isto? 

Todo construtor executa primeiramente uma chamada super() ou this() dependendo do caso, quando executado. Somente uma dessas chamadas é válida antes do resto. Mesmo que você não coloque explicitamente, o compilador irá colocar um super() pra você porque em algum momento ele vai ter que inicializar sua superclasse antes de inicializar a classe em si. 

Então você deve se perguntar se a classe A tem uma superclasse porque não está herdando de ninguém. Errado! Todas as classes herdam de Object implicitamente. Object é tipo uma classe "mãe" no Java (ela fornece métodos como equals por exemplo).
Se temos duas classes A e B, com B herdando A, quando criamos uma instância de B os construtores são executados em forma de pilha: B chama A e A chama Object. Object é executado, A é executado e por último B:

OBJECT
A
B

Mais adiante vou mostrar o resultado disto. Antes de continuar vamos rever alguns conceitos. Quando você digitar:

class A {
}

Seu compilador irá adicionar automaticamente o construtor:
class A {
 A(){
  super(); 
 }
}

O contrutor criado por ele sempre será sem argumentos. E se digitar só:
 
class A {
 A(){
 }
}

Não tem problema, o compilador adicionará o super();
O compilador só não vai fazer nada se for adicionado um construtor sobrecarregado:

class A {
 A(String s){
  super(); 
  System.out.println("Executou construtor A");
  //Códigos legais aqui
 }
}

Isso mesmo! Construtores podem ser sobrecarregados (mas não sobrescritos porque não são herdados), mas lembre-se:

Se houver um construtor sobrecarregado qualquer, o compilador não vai criar outro automaticamente
Sabendo disto você não cairá em pegadinhas do tipo:
class A {
 A(String s){
  super(); 
  System.out.println("Executou construtor A");
  //Códigos legais aqui
 }
}

public class B extends A{
 
 public static void main(String[] args) {
  new B();
 }
 
}

Acontece que a classe B possui aquele construtor automático que falei anteriomente. E na classe A, por ter definido um construtor sobrecarregado, não temos o construtor padrão sem argumentos, então código não compila:

Exception in thread "main" java.lang.Error: Unresolved compilation problem:
Implicit super constructor A() is undefined for default constructor. Must define an explicit constructor

at B.(B.java:10)
at B.main(B.java:13)

Sempre tente detectar isto quando uma questão abordar construtores e como funciona a pilha. Logicamente o código terá mais alguma lógica obscura tentando lhe desviar do problema e tentando esconder o obvio. Neste caso, para resolver o problema, você mesmo deve criar construtor em A sem argumentos ou em B passando o parametro como pede:
 B(String s) {
  super(s);
 }

E a chamada a B deverá ser:

  new B(null);

Veja que o construtor de B recebe o parâmetro e o passa para a superclasse, isto é perfeitamente possível.
Um ponto importante é que nada pode ser feito sem que o construtor seja executado. Nenhum acesso a variável de instância ou método antes que o super() final seja chamado e construa Object. Isto que dizer que um objeto não pode ser utilizado até ser inicializado, o que é obvio, mas também significa que você não pode tentar sabotar o construtor do objeto antes de chamar super():
class A {
 A(String s){
  System.out.println("Antes de executar o super de Object");
  super(); // Problema!!!
  System.out.println("Executou construtor A");
  //Códigos legais aqui
 }
}

Outra coisa é que um construtor pode chamar outro. Um construtor só pode ser chamado dentro de outro. Isto que dizer que ou você chama outro construtor da mesma classe que tenha sido sobrecarregado utilizando o this() ou chama o da superclasse utilizando super(). Como já foi dito, somente uma dessas chamadas poderá ser feita dentro do contrutor e deverá ser a primeira coisa a ser feita.
public class B{
 B() {
  super();
  System.out.println("Executou o construtor padrão.");
 }

 B(String s){
  this();
  System.out.println("Chamou o construtor padrão.");
 }
 
 public static void main(String[] args) {
  new B(null);
 }
}

Veja que o código produz a seguinte saída:

Executou o construtor padrão.
Chamou o construtor padrão.



A saída é "invertida" por causa da pilha. O main chamou o construtor B sobrecarregado, antes de qualquer coisa ele chamou B padrão que chamou super(). Então Object foi criado e volta pra B padrão, então é executado. Volta para o B sobrecarregado e mostra que "Chamou.." no final, ele ja tinha chamado mas estava esperando os outros.
Agora veja o seguinte exemplo:
class A {
 void A(){
  super();
  System.out.println("Executou construtor A");
  //Códigos legais aqui
 }
}

O que tem de errado com a classe? Não... aquilo não é um construtor, é apenas um método qualquer porque ele tem um tipo de retorno e construtores não tem. Tome cuidado.
Só pra finalizar o post porque já está ficando cansativo, analise este código:
class A {
 A(){
  System.out.println("A");
 }
}

class B extends A{
 B() {
  System.out.println("B");
 }
}

public class C extends B{
 C() {
  System.out.println("C");
 }
 
 public static void main(String[] args) {
  new C();
 }
}

Qual será a saída?? Não vou responder...
Bons estudos e até a próxima!