Não Herdar Certos Métodos da Classe sem Private

Jaba:

E aew galera, blz?

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.

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).

Agora eu fiquei em dúvida tbm…

Com o final, o método é visível apenas pela própria classe?

sergiotaborda:

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, ele não Pode ser Sobrescrito, mais ainda continua visivel para as SubClasses porque vai ser Herdado, mesmo que somente internamente!

Nops, Claudneto! O mesmo só não vai poder ser Sobrescrito.

Não dá Jaba, o Java não permite, e não tem muita lógica em fazer isso.

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.

Uai, é só colocar vários class dentro do arquivo. Só não podem ser public, mas ainda podem usar o extends normalmente.

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.

Mas que confusão…

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”).