Pessoal esse tópico tá rendendo heim…
E vcs falam, falam e não saem do lugar. Arrumaram diversas maneiras
de dizer a msm coisa.
Na minha humilde opinião e através de tudo que foi dito pude concluir que todas as variáveis e metodos são herdados de
uma classe, mas as variaveis “private” não são acessiveis diretamente, mas somente pelos metodos set e get. Então se uma determinada variavel
não pode ser acessada e modificada por uma outra classe no caso da
herança devemos repensar o encapsulamento da variavel.
qualquer coisa private nao herda,sendo variavel ou metodo,se quiserem modificar uma variavel private,crie um metodo publico,logico o metodo na classe pai onde c encontar a variavel vlw!!!
Logico que herda…pq vcs não fazem o download do BlueJ ou olhem do debug de qq IDE que o atributo privado do pai pertence ao filho, isto é, foi herdado.
[quote]
Mas a definição de que herança é só uma forma de aumentar o escopo também é fraca. Você mesmo falou: “herança é o nome de uma forma especifica de aumento de escopo”. E o que torna essa forma específica?
Justamente a criação de herarquias de classes. Qualquer hierarquia? [/quote]
Só ha uma hierarquia em java.
Então, herança é apenas uma forma de aumentar o escopro do membros de uma classe que implicam que a classe derivada pertence na hirarquia da original.
O que vc está dizendo aqui é que existem outras formas de aumentar o escopo, que não são a herança. Certo. Como eu disse: em java, shadowing também é uma forma de aumentar o escopo.
Por existirem várias formas de aumentar o escopo ( static seria outra) é que eu disse que a herança é uma forma especifica. É uma entre outras.
na minha opinião não herda.
Pode ocorrer coisas estranhas como o reflections
um método publico chamar um privado e assim ter um pseudo acesso, mas isso não é a definição.
É como herança múltipla, não tem, mas vc pode contornar.
Eu estou ficando realmente surpreso com a profundidade da capacidade lógica de pensar…
Se for considerada uma classe pai que tenha uma propriedade com o modificador de acesso private e um método que lê essa propriedade, quando eu estender essa classe e fizer o uso desse método herdado, a propriedade que preserva a informação (declarada na classe pai como private) estará alocada na memória do além e naturalmente não fará parte do objeto que é uma instância da classe filha e quando um objeto dessa subclasse fizer uma leitura através desse método get, a VM do java irá romper a barreira do material e obter uma informação do além e que naturalmente NÃO FARÁ PARTE DO OBJETÖ…
Vamos continuar a conversar sobre a policromia dos cristais partidos, mesmo com quem entra, não lê os posts anteriores e repete hipoteses já derrubadas e não fundamentadas…
Interessante… pensando que, todo filho é o pai de uma forma especializada logicamente a resposta teria de ser sim… acredito que as referências que dizem que não herda seja pra facilitar o entendimento do modificador de acesso apenas, não levando em conta a essencia da coisa…
Vc consegue chamar o método, mas a definição é que não herda.
public class SuperPrivate {
public static void main(String args[]){
Filha a = new Filha();
a.acessaMetodoPrivado();
}
}
class SuperClass{
public void metodoPublico(String arg){
metodoPrivado(arg);
}
private void metodoPrivado(String arg){
System.out.println("Método privado chamado arg='"+arg+"'");
}
}
class Filha extends SuperClass{
public void acessaMetodoPrivado(){
super.metodoPublico("teste");
}
}
Por exemplo, vc herda o monitor da pessoa?
Não, porém vc consegue modificar o que é desenhado nele…
[quote=Dieval Guizelini]Se for considerada uma classe pai que tenha uma propriedade com o modificador de acesso private e um método que lê essa propriedade, quando eu estender essa classe e fizer o uso desse método herdado, a propriedade que preserva a informação (declarada na classe pai como private) estará alocada na memória
[/quote]
Memoria = JVM = Plataforma = Implementação
Herança = Regra = Linguagem = Teoria
Linguagem é diferente de plataforma. O que acontece na memoria não tem nada a ver com a linguagem.
A prova disso é que muitas linguagens compilam o mesmo bytecode e funcionam na mesma JVM usando a mesma memoria. É dificil de aceitar isto ? Acho que não.
Dado que o que acontece na memoria é completamente inutil para saber se ha herança ou não , porque perder tempo com esse exemplo ?
O livros não afirmam que membros privados não são herados simplesmente porque querem se didáticos, eles dizem isso porque é a verdade. A prova é que dada uma classe que extende outra vc não consegue acessar nenhum dos membros privados da classe hierarquicamente superior.
Se vc acessa um método publico i ou protegido da classe pa que por sua vez acessa a variável privada , tudo bem. Isso não prova que a clase filha tem acesso à variável privada.
Memoria = JVM = Plataforma = Implementação
Herança = Regra = Linguagem = Teoria
Linguagem é diferente de plataforma. O que acontece na memoria não tem nada a ver com a linguagem.
A prova disso é que muitas linguagens compilam o mesmo bytecode e funcionam na mesma JVM usando a mesma memoria. É dificil de aceitar isto ? Acho que não.
[/quote]
Depende, em que você queira aplicar, quando falamos em Java, normalmente estamos falando do conjunto todo.
Com relação a sua definição: “Herança = Regra = Linguagem = Teoria”, poderia ser melhor definida que “Herança é conceito definido na OO” e a interpretação dos engenheiros da SUN com relação a este conceito é exclusivamente implementado com o uso da palavra chave extends, e conforme as especificações do JCP para as VM.
Infelizmente não posso concordar, apenas com um conhecimento de como a ferramenta manipula a memória, IO e etc, pode-se compreender vários conceitos. Apenas para citar, que é outro ponto polêmico no Java, a passagem de parâmetros por valor ou referência.
[quote=sergiotaborda]
O livros não afirmam que membros privados não são herados simplesmente porque querem se didáticos, eles dizem isso porque é a verdade. A prova é que dada uma classe que extende outra vc não consegue acessar nenhum dos membros privados da classe hierarquicamente superior.
Se vc acessa um método publico i ou protegido da classe pa que por sua vez acessa a variável privada , tudo bem. Isso não prova que a clase filha tem acesso à variável privada.[/quote]
Como docente não posso “desconsiderar” a literatura normalmente aceita pela sociedade, mas como pesquisador da área de desenvolvimento eu posso afirmar dois grandes problemas com a literatura técnica, principalmente na área da informática:
Os tradutores normalmente não possuem conhecimento da área de informática, e quando possuem são fracos. O maior exemplo desse problema, talvez seja o livro de Inteligência Artificial do Norvig e Russellque quase conseguiu acabar com a área de IA no Brasil no fim da década de 80 e início dos anos 90.
O conceito de “aspectos didáticos” associados aos livros que se destinam a treinamentos ou preparação para certificações são em sua maioria ruins e apresentam metodologias que já não são mais tão utilizadas no sistema educacional do Brasil. Principalmente as metodologias baseadas em Piaget. A exemplo o livro da Kathy.
Agora, focando no conceito de OO, de herança, observe que quando uma subclasse executar qualquer código que faça uso (ou é dependente) de uma propriedade declarada com private, ela não deveria funcionar se não tivesse herdado essa característica. Logo, volto a afirmar que toda classe especializada de outra classe através do recurso de herança, seja em Java ou em qualquer linguagem do paradgima Orientado a Objetos, terá todos os recursos da classe pai.
[quote]
ViniGodoy wrote
Existe uma diferença entre a existência de um atributo e a sua visibilidade.
O que o Dieval quer dizer é que, uma classe filha herdará um atributos e métodos do pai, no sentido de que, essas estruturas existirão, serão alocadas em memória, e serão usadas pelos mecanismos internos da classe. Afinal de contas, o filho é um objeto da classe pai e nada mais natural do que ele ter absolutamente todos os atributos do pai.
Entretanto, graças às regras de escopo, esses atributos e métodos não serão visíveis na classe filha. Daí a confusão. Assim, eles são herdados (pq existem e são acessados indiretamente pelos filhos), mas não são visíveis, estão fora do escopo da classe filha.
Por isso, não é possível fazer polimorfismo de métodos privados, por exemplo. O que ocorre se sobrescrevermos métodos privados é acabarmos com métodos de escopos diferentes. Um deles será usado quando a porção do pai invocar, outro será usado quando a porção do filho invocar que, se houvesse polimorfismo, apenas o método do filho seria invocado. [/quote]
Pra mim ViniGodoy foi muito feliz nessa resposta, o fato de não ser visivel naum quer dizer que não foi herdado.
Tá tudo explicado ai
Você defende, portanto, que o que está em memoria reflete sem equivocos as regras da linaguem java ?
Vc não está pensando no problema como um todo.
Vc diz que se a classe A tem o atributo z então B que estende A também tem. A sua justificativa é que no debug (que é feito por uma ferramenta de runtime ) z aparece num objecto do tipo B.
Se A também tiver um atributo y estático ele também irá aparece em cada objecto de B. Contudo , isto não significa que y existe em cada objecto de B. Como pode um atributo (um só) pertencer simultaneamente a N objetos diferentes ?
A resposta é simples. A ferramente de debug mostra o estado do objeto, mas isso não significa que ela é limitada pelos atributos do objeto. Ela mostra tudo o que existir. Independentemente de onde.
Por outro lado , quando diz que z existe em B isso não é verdadeiro. z existe em A e B é uma expanção de A.
É como fazer um circulo à volta da são paulo e dizer que são paulo pertence ao circulo. Mas se eu fizer um circulo maior em torno do primeiro, são paulo continua petencendo ao circulo menor. Ele apenas está dentro do maior, porque este contém o menor. Estar “incluso” é diferente de “existir em”
Se aceitarmos o argumento de que z existe em B porque existe em A, porque a ferramente assim mostra, temos que aceitar que y existe em cada objecto do tipo de B, porque a ferramenta assim mostra. E isso é um absurdo porque y é estático (ele não pertence aos objetos). Logo, não podemos aceitar o argumento baseado em ferramentas de debug.
Os implementadores da ferramenta de debug poderiam ter escolhido esconder coisas estáticas. Seria mais correto do ponto de vista teorico, mas seria absurdo do ponto de vista prático. Por isso que qualquer coisas que seja uma ferramenta , ou uma API que se baseia no estado da memoria em runtime não pode ser argumento para provar o que é regra em tempo de compilação. O fato de membros privados não serem visiveis em tempo de compilação é que é a regra. E isso que significa “membros privados não são herados” ou seja, “a visibilidade de membros privados não se estende a subclasses”. Privados = “só dela”.
[quote=sergiotaborda][quote=Dieval Guizelini]Se for considerada uma classe pai que tenha uma propriedade com o modificador de acesso private e um método que lê essa propriedade, quando eu estender essa classe e fizer o uso desse método herdado, a propriedade que preserva a informação (declarada na classe pai como private) estará alocada na memória
[/quote]
Memoria = JVM = Plataforma = Implementação
Herança = Regra = Linguagem = Teoria
Linguagem é diferente de plataforma. O que acontece na memoria não tem nada a ver com a linguagem.
A prova disso é que muitas linguagens compilam o mesmo bytecode e funcionam na mesma JVM usando a mesma memoria. É dificil de aceitar isto ? Acho que não.
Dado que o que acontece na memoria é completamente inutil para saber se ha herança ou não , porque perder tempo com esse exemplo ?
O livros não afirmam que membros privados não são herados simplesmente porque querem se didáticos, eles dizem isso porque é a verdade. A prova é que dada uma classe que extende outra vc não consegue acessar nenhum dos membros privados da classe hierarquicamente superior.
Se vc acessa um método publico i ou protegido da classe pa que por sua vez acessa a variável privada , tudo bem. Isso não prova que a clase filha tem acesso à variável privada.[/quote]
Eu concordo plenamente com você. Detalhes de implementação da linguagem não nos interessa e até podem mudar entre versões, sem impactar na linguagem.
Um outro exemplo é o compartilhamento de métodos pelos objetos da mesma classe.
Eu não disse que a herança é justificada pela representação da informação que o debug mostra e sim pelo fato que de a classe B ao estender A, ela terá todos os recursos (propriedades e métodos) independentes da visibilidade dos mesmos.
Eu acredito que esse é o ponto principal da questão e onde surge a divergência de opniões, o fato de um círculo ter outro não significa que É o mesmo.
O problema não está no fato de eu ter duas classes que TENHAM propriedades iguais, exemplo:
public class A {
public int a;
}
public class B {
public int a;
}
Neste caso, não existe nenhuma relação entre estas classes, são classes distintas. Mas que possuem (usando o seu termo, contém) uma propriedade do mesmo tipo de informação e com o mesmo identificador. Mas não são a mesma coisa, logo:
B b = new B();
System.out.println( b instanceof A); // sempre será falso
Agora, quando temos:
public class A {
modificador_qualquer int a;
}
public class B extends A {
}
independentemente do modificador, sempre as instâncias de B produzirão verdadeiro no teste abaixo:
B b = new B();
System.out.println( b instanceof B); // sempre será falso
E este é ponto para mim, ou seja, ter uma classe herdada de outra em java, implica que:
ela sempre passará no teste É UM;
ela sempre terá os recursos da classe pai, independentemente de visibilidade e da disponibilidade desse recursos para a própria subclasse ou classes terceiras.
Observe novamente que herança não está associada a idéia de pertinência ou de conter.
Novamente o seu exemplo deixa claro que você está misturando o conceito de pertinência com o conceito de existência.
quando um recurso é declarado como static, esse recurso pertence a classe e está associado a todos os objetos dessa classe. Se eu criar uma subclasse, essa subclasse será também associada ao mesmo recurso. Na prática, estamos falando de uma única região de memória compartilhado por todos os objetos.
Então, para você a herança é uma regra implementada na etapa de compilação? Os objetos existem na fase de compilação?
As regras de visibilidade são validadas também em tempo de compilação, mas não somente nesta etapa. A herança e sua implementação é uma definida no nível de classe, mas as conseqüências, ou sua real implementação ocorre em tempo de execução tanto no nível de classe como de objeto.
Enquanto o código não estiver em execução, a memória não será alocada, a classe não receberá os recursos da classe pai e assim por diante.
