Você não deveria estar reescrevendo um atributo já existente. Mas já que o fez, o método getN1() pega o n1 da classe 2.
J2Alex
Certo, não deveria. Mas imagine a hipotética situação em que estou extendendo uma classe de terceiro e não conheço sua implementação (tudo bem, vou ter acesso ao atributo protected… mas, desconsidere isso ).
Realmente pensei que fosse dar algum erro de compilação já que um é int e o outro é String.
A questão é que o método getN1() NÃO pega o n1 da classe 2. Mesmo porque o retorno do método é um int e não um String. O método retorna 0.
Mas se eu definir um método public String getN2() … na Classe2, aí sim, ele me retorna null.
Sei que não se trata de um procedimento normal, mas o que coloco é se esse modelo não é “frágil”?
danieldestro
Ops, realmente falei besteira. Não me atentei aos tipos e etc.
Acho que ele pega o n1 da Classe1 porque como o método não foi reescrito e pertendo à Classe1, ele só sabe da existência do atributo da própria classe ou das classes mães.
Luca
Olá
O único método getN1() que eu estou vendo nesta hierarquia de classes retorna um inteiro. Seria Mandrake se retornasse uma String ou um picolé de morango.
Mas se eu fizesse outro método para retornar uma String ele retornaria direitinho o valor que a String foi inicializada, isto é, null.
O que tem de frágil nisto?
[]s
Luca
J2Alex
Olá Luca,
Estou me referindo ao fato de ter um atributo n1 do tipo int na Classe1 e n1 do tipo String na Classe2.
Como vou garantir qual deles estará sendo usado, já que os dois parecem coexistir “pacificamente” na Classe2. O estranho é que posso ter na Classe2 um método public int getN1() (da Classe1) que retorna n1 igual a 0 e um método public String getN1String() que retorna n1 igual a null.
O frágil a que me refiro é que isso pode gerar confusão… não seria mais lógico dar erro de compilação??? Ou estou errado??? :roll:
Luca
Olá
Nem consigo imaginar como poderia haver confusão só porque os nomes são iguais. Lá dentro da memória os bits são completamente diferentes portanto o compilador em nenhuma hipótese faria confusão.
E fora da memória também não vejo nenhum problema em coisas diferentes com mesmo nome pois afinal tenho um amigo de nome Mike e conheço também um cachorro de nome Mike.
Seria mais dificil de saber exatamente qual o método seria chamado se tanto na classe pai como na classe filho os métodos tivessem a mesma assinatura. Mas isto é dúvida que a gente tira logo nas primeiras páginas de estudo de OO. Fica tranqüilo e avança mais um tiquinho nos estudos.
[]s
Luca
danieldestro
Uma classe não pode conter dois métodos com a mesma assinatura, mesmo que o tipo de retorno os diferencie.
J2Alex
Caro Luca,
Acho que não entendeu bem o que eu quis dizer.
Não é confusão para o compilador, mas para que está utilizando a classe, já que na Classe2 eu tenho n1 me retornando tanto 0 (int) quanto null (String).
Ao meu entender, se crio uma Classe2 a partir da Classe1 e redefino o atributo n1 na Classe2 com tipo diferente do tipo n1 da Classe1, este deveria passar a prevalecer na Classe2. Sendo assim, seu eu instanciar a Classe2 e chamar o método getN(), compreendo que deveria gerar erro - pois o método retorna int e o atributo n1 da Classe2 é String. Melhor dizendo: acho que nem deveria ser possível redefinir um atributo com mesmo nome e tipos diferentes.
Daniel, o que você disse faz sentido.
O código abaixo estaria então correto (instanciando-se Classe2)?
...this.n1;// String...super.n1;// int...
danieldestro
J2Alex:
O código abaixo estaria então correto (instanciando-se Classe2)?
...
this.n1; // String
...
super.n1; // int
...
Sim.
Luca
Olá
O que tem uma coisa a ver com a outra?
Entendi sim. A sua dúvida é bem básica e como disse pode ser tirada logo no início do estudo de OO e de Java. Fiz questão de dizer que internamente são diferentes para que ficasse claro que neste caso nem era necessário nenhum critério de desempate para saber quem é quem. Já no caso do exemplo que dei do Mike, se ao invés do cachorro tivesse citado o filho do Mike então precisaria usar uma convenção para saber quem era o pai e quem era o filho. Tipo um sufixo Jr.