ae galera, estudando as pegadinhas do exame, aproveitei e vou postar um codigo e a galera que está estudando diz se compila ou nao compila… e se nao compilar pq nao compila…
class Camilo{
static void nome(){}
public static void main(String ar[]){
}
}
class Neto extends Camilo{
void nome(){}
}
agora esse tb tinha la
class Camilo{
void nome(){}
public static void main(String ar[]){
}
}
class Neto extends Camilo{
final void nome(){}
}
deixem a opniao de vocês depois colocar a minha para ver se estou no caminho certo :d
flw! rumo a scjp
[quote=diego2005]O primeiro código não compila, pois não podemos sobscrever métodos estáticos. O segundo compila sdem problemas…
T+[/quote]
certinho
pegadinha boa…
só pra frisar o assunto… no segundo exemplo, se fosse o inverso, ou seja, se o metodo nome() da classe Camilo fosse marcado com o modificador final, não compilaria… mas se fosse marcado como private, compilaria sem problemas, apenas não poderia ser subscrito.
pera ai galera houve um pouco de confusao, vamos la a questao… apesar de ser xuxu como falaram… mais tem muita dessa questao… no exame… infelizmente o “xuxu” deve ser estudado… Marcio_Nogueira - a segunda compila q tem o final… a com o static q n compila.
a questao é que os metodos static nao sao subscrito e sim redefindos… e por isso que o primeiro nao compila. pq é o mesmo de eu isso em uma classe:
class Tes{
static void nome(){}
void nome(){}
isso nao compila apenas pq mudei o modificador de nivel de acesso da classe… so se eu mudasse o tipo… entao nao o primeiro nao compila.
O segundo compila pq nao problema de eu dizer que na subclasse meu metodo vai ser final ou seja nao vai poder ser subscrito uma subclasse da subclasse que é sub da super.
cuidado com essa expressao, pq private nem herdado é… pertence a classe… entao nao tem nada ver com subscrição private é com relacao a classe… olhe o codigo abaixo…
class Avi{
private void dados(){}
}
class Av extends Avi{
void dados(){}
}
compila normal e nao é uma subscrição do metodo…
bom pessoal eu pensei assim quando vi uma classe desse tipo se eu tiver errado, so corrigir… heh valeu
cara… volta la e leia meu texto novamente… eu apenas disse que se marcar a classe pai como private, a classe filha pode escrever o metodo com a mesma assinatura que não dará erro de compilacao… eu nao disse que a classe filha herda, tampouco subscreve um metodo private, pelo contrário… eu disse que a classe filha NÃO SUBSCREVE…
cuidado com essa expressao, pq private nem herdado é… pertence a classe… entao nao tem nada ver com subscrição private é com relacao a classe… olhe o codigo abaixo…
class Avi{
private void dados(){}
}
class Av extends Avi{
void dados(){}
}
compila normal e nao é uma subscrição do metodo…
[/quote]
cara… volta la e leia meu texto novamente… eu apenas disse que se marcar a classe pai como private, a classe filha pode escrever o metodo com a mesma assinatura que não dará erro de compilacao… eu nao disse que a classe filha herda, tampouco subscreve um metodo private, pelo contrário… eu disse que a classe filha NÃO SUBSCREVE… [/quote]
assim se ela nao herda como é que vai subscrever? entao entendi errado… mais foi o que qdo li, o que vc falou que entendi… so nao precisa ficar nervoso por algo tao simples.
cuidado com essa expressao, pq private nem herdado é… pertence a classe… entao nao tem nada ver com subscrição private é com relacao a classe… olhe o codigo abaixo…
class Avi{
private void dados(){}
}
class Av extends Avi{
void dados(){}
}
compila normal e nao é uma subscrição do metodo…
[/quote]
cara… volta la e leia meu texto novamente… eu apenas disse que se marcar a classe pai como private, a classe filha pode escrever o metodo com a mesma assinatura que não dará erro de compilacao… eu nao disse que a classe filha herda, tampouco subscreve um metodo private, pelo contrário… eu disse que a classe filha NÃO SUBSCREVE… [/quote]
assim se ela nao herda como é que vai subscrever? entao entendi errado… mais foi o que qdo li, o que vc falou que entendi… so nao precisa ficar nervoso por algo tao simples.
[/quote]
exatamente… vc entendeu errado … e não é a primeira vez… uma critica construtiva… não me leve a mal
[quote=Schuenemann]Sei disso, mas essa é minha dúvida.
Em outras linguagens, você não consegue chamar um método estático com n.nome(), só Neto.nome().
A pergunta é se existe algum motivo especial para o código não compilar ou se é só decisão de projeto da linguagem.[/quote]
sim sim… porém no java podemos chamar metodo/atributo/classe interna estatico dentro de uma variavel de instancia, como se pertencesse a instancia, como vc bem sabe … na minha opiniao isso não é legal porque prejudica a legibilidade, mas tudo bem… é uma boa pegadinha pra prova
qto a sua real pergunta entao, métodos de instancia subscritos tem como finalidade o polimorfismo … metodos estaticos são redefinidos… agora misturar estatico com instancia… seria redefinido ou subscrito?
creio eu que seja um dos motivos de gerar erro de compilacao… é a minha visao do problema… outras serão bem vindas…
public class EnumHash {
enum estacao{
PRIM,VERA,OUT,INVER }
public static void main(String[] args) {
Set<estacao> es = new HashSet<estacao>();
es.add(estacao.OUT);
es.add(estacao.PRIM);
for(estacao c: es)
System.out.println(c);
Como vcs acha que é a saida? hehe explica porque… essa ai entra as regras de conjunto e ter atenção que é um HashSet.
ops esqueci das chaves tirando isso a saida é :
PRIM
OUT
observe ele nao tem uma ordem de iteração mais, meu conjunto é classificado pq enum segue o contrato de equals e hashCode enum implementa o contrato de forma eficiente… entao ele ordena… agora se fosse uma List --ArrayList ele ia imprimir:
OUT
PRIM
ja que o acesso é por indice… e o conjunto nao foi ordenado…
eu tive essa conclusão com esse codigo… seria isso?
Adicione todos os elementos no set e daí imprima. Vc vai ver que a saída é:
PRIM
OUT
VERA
INVER
Sair ordenado com PRIM e OUT foi só coincidência.
Nem que os hashCodes fossem ordenados, ainda haveria a possibilidade de um HashMap não devolver os números ordenados.
