Não sei se o meu pensamento sobre o Desenvolvimento de Projeos ta Errado ou se falta conhecimento em Modificadores de Acesso, mas vamos lá:
Digamos que eu tenha um método em uma classe que eu não quero que as Classes que a Extendam herde-o.
Até ai tudo bem, é so marcar o Método com Privado.
Mas, se eu marcar como privado, não posso chamar esse Método em mais nenhuma instância da minha Classe.
Eu não quero isso. Eu quero que um certo método seja privado para as subclasses mas que eu possa chamar em qualquer instância dela.
Ai, provavelmente, vocês irão citar o modificador Protected.
Sim, eu sei que, ao declarar um metodo com esse modificador, ele se torna privado nas sub-classes e não na Instancia, mas para isso, eu preciso declarar a Classe Pai em outro Pacote, o que não chega a ser muito viável, dependendo do Objetivo.
Então, lá vai a pergunta que não quer calar: Dá pra declarar um método privado para as subclasses e pelo menos Default para as Instâncias, dentro do mesmo Pacote?
Não sei se o meu pensamento sobre o Desenvolvimento de Projeos ta Errado ou se falta conhecimento em Modificadores de Acesso, mas vamos lá:
Digamos que eu tenha um método em uma classe que eu não quero que as Classes que a Extendam herde-o.
Até ai tudo bem, é so marcar o Método com Privado.
[/quote]
O problema está aqui. PAra evitar que a subclasse subeescreva o método vc o declara final.
Modificador de acesso são outros 500.
Declarando como final o método pode ter qualquer modificador de acesso (exceto private, porque o private já é final por definição).
Certo, admite que não tem muita lógica, mas, e se eu quisesse organizar o codigo deixando a classe no mesmo arquivo das subclasses? Dessa maneira, eu tenho que ter um .Class para as Classes Pais.
esqueca o final, pq nao tem nada ver com herança! a melhor forma eh usar o private. Assim nao sei pq as pessoas serem querem complicar as coisas… ja acham um modificador pronto, a linguagem prontar mais querem reiventar a roda.vai entender rs!
Curto e grosso: o projeto das suas classes está errado. Se você não quer acessar métodos públicos da superclasse através de uma instância de uma subclasse é porque esse projeto não corresponde à realidade do seu problema.
Você ta querendo inventar um novo modificador de acesso isso sim
O mais próximo disso que você quer é marcar o método como public e final, ele será acessível nas instancias da sua classe e não poderá ser sobrescrito nas classes filhas.
A visibilidade do método não tem nada a haver com a possibilidade de sobre-escrever o método.
O objetivo original é : permitir que a subclasse use o método, mas não permitir que a subclass sobre-escreva o método.
coloca o método como private torna-o invisivel à subclasse e portanto ela não pode usar nem sobre-escrever simplesmente porque a subclasse não tem acesso nenhum a esse método.
coloca o método como final , independentemente da visibilidade , impede que seja sobre-escrito.
Não existe “Evitar que seja herdado”. Todos os métodos são herdados , mesmo os privados. Acontece apenas que a subclasse não os pode acessar ( não tem permissões para isso)
Se vc colocar o método private e final isso é redundante e por isso é considerado má-prática.
Se o método vai ser usado apenas pela subclasse e não é publico ele deve ser protected. Se a subclasse não o pode sobre-escrever ele é final.
Não ha nada de errado com este design. Aliás bem pelo contrário, prova que vc está pensando certo e recomenda-se
Métodos protected e final são uma otima solução para o problema em causa. E são muito uteis sobretudo em implementações do padrão Template Method ( o metodo template não pode ser sobreescrito, mas tem que ser usado pela subclasses e até pode ser publico )
O final não muda a visibilidade, ele não é um modificador de visibilidade. É um modificador de permissão de sobreescrita ( o default do java é “pode ser sobreescrito”).
