Propriedade privada, herda ou não herda?

JavaEvangelist Membro desde: 28/01/2005 12:42:15 Mensagens: 414 Offline

Herança não tem nda a ver com a linguagem , herança tem a ver com conceitos de OO !

Tentem desvincular o conceito OO e a linguagem ....

Virtual Machine Man Membro desde: 12/09/2006 08:26:06 Mensagens: 672 Offline

goofed wrote:So pra contradizer melhor o exemplo do CPF do pai e do filho aqui vem um exemplo:
class Pessoa { private String nome; public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } } class Funcionario { private String empresa; }

Nossa... Uma pessoa tem um nome... um funcionario não! ???
Pra mim, a relacao de classe nao eh tipo... pai pra filho como alguns dizem.
Que eu saiba a relacao é do famoso "é um".
Funcionario é uma Pessoa, logo Funcionario tem um atributo nome.

Pelo o que eu entendi...através da herança - conceito OO, funcionário tem NOME sim...mas na linguagem java Funcionario não herda a propriedade nome diretamente, porém, ele acessa a propriedade através dos metodos get/set e a linguagem se encarrega de fazer essa 'assossiacao' entre as classes..de modo que o conceito herança seja aplicado..

certo pessoal?!

JavaEvangelist Membro desde: 28/01/2005 12:42:15 Mensagens: 414 Offline

Quem tiver tempo, faça download do BlueJ (http://www.bluej.org/index.html)
A resposta esta la !

So pra adiantar, metodos privados são herdados !

Acreditam que eu tava estudando o Heads First Java e li que não herdam e perguntei no Javaranch?
Não herdam explicitamente, mas com métodos set e get posso acessá-los tranquilamente.

Ps.: PM, o que o BlueJ tem a ver? Eu tenho ele (na verdade acho que é a melhor IDE pra se aprender java, sinceramente) e aconselho pra muita gente. Vale muito a pena pra aprender.

JavaEvangelist Membro desde: 28/01/2005 12:42:15 Mensagens: 414 Offline

O BlueJ é uma das melhores ferramentas para aprender OO.

Cria as duas classes uma Pai e outra filho.
Criar um atributo privado na Pai e depois cria uma instancia da filho.
Olha as "propriedades"(inspect) da objeto e ae vc vai ver que ele herda o atributo privado da classe Pai.

simples assim !

JavaEvangelist Membro desde: 28/01/2005 12:42:15 Mensagens: 414 Offline

dedejava wrote:
Não herdam explicitamente, mas com métodos set e get posso acessá-los tranquilamente.

Herdar é diferente de acessar !!
Neste caso, gets e sets tem haver com polimorfismo !

O que eu fiz... criei uma classe pessoa...

depois fiz a seguinte classe estendendo de pessoa...

no eclipse em modo debug acontece o seguinte

eu não consegui colocar a imagem mais seria isso)

p = Pessoa
CPF = null
nome = "Nome de Pessoa"
RG = null
sexo = "Sexo da Pessoa"

c = Carlos
CPF = null
nome = "Nome de Pessoa"
RG = null
sexo = "Sexo da Pessoa"

seguindo esse raciocinio.. acho que herda sim, porém não há visibilidade, como já foi dito.

é só minha humilde opnião...

pm wrote:

dedejava wrote:
Não herdam explicitamente, mas com métodos set e get posso acessá-los tranquilamente.

Herdar é diferente de acessar !!
Neste caso, gets e sets tem haver com polimorfismo !

Polimorfismo? Por que? Não teria mais haver com encapsulamento?
Eu acesso a variavel de instância pela subclasse e não pela superclasse. Mesmo se eu usasse o polimorfismo, fazendo:

Eu poderia acessar ele, por causa do acessador, né?
Teria como explicar o porquê do Polimorfismo nesse caso?

JavaEvangelist Membro desde: 28/01/2005 12:42:15 Mensagens: 414 Offline

ups ...é isso mesmo !!!!

me desculpe e obrigado por me corrigir!

This message was edited 3 times. Last update was at 08/01/2008 21:15:54

Sérgio.

Eu sempre tenho muito cuidado ao falar de reflexão.

E, eu estava sugerindo explicitamente que se violasse o encapsulamento usando reflexão justamente para se demonstrar como a herança de fato ocorreu, embora as regras de visibilidade restrinjam o acesso ao atributo. Somente através da reflexão (ou analisando o bytecode gerado, o que não é nada fácil) é possível demonstrar aspectos como esse.

Eu concordo com você que isso não é boa prova (nem sequer é prova), e que herança é uma regra. Mas você também restringiu herança a um aspecto de implementação, que se resume em "aumentar um escopo". Herança certamente não é isso. Isso é uma consequência da herança, não o seu significado. A herança implementa a regra é um. Ou seja, semanticamente, um filho é um exemplo mais específico do pai.

Não é possível conceber essa regra tendo um filho que é "parte de um pai", o que aconteceria se coisas não fossem herdadas. O filho pode não ter acesso ou controle sobre partes do pai, mas ele as possui.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 1977 Offline

ViniGodoy wrote:
Eu concordo com você que isso não é boa prova (nem sequer é prova), e que herança é uma regra. Mas você também restringiu herança a um aspecto de implementação, que se resume em "aumentar um escopo". Herança certamente não é isso. Isso é uma consequência da herança, não o seu significado. A herança implementa a regra é um. Ou seja, semanticamente, um filho é um exemplo mais específico do pai.

Não é possível conceber essa regra tendo um filho que é "parte de um pai", o que aconteceria se coisas não fossem herdadas. O filho pode não ter acesso ou controle sobre partes do pai, mas ele as possui.

O aumento do escopo não é um dado de implementação. É regra da linguagem. É graças a ele que pode ser feito shadowing. A implementação segue regras que têm que respeitar as regras da linguagem, mas como já disse, a JVM não força essas regras. Para outras linguagens, os compiladores podem estipular outras regras de escopo diferentes.

Herança não passa de um tipo especial de polimorfismo. Todo o polimorfismo é baseado em escopo. Herança , não é portanto diferente. As outras formas de polimorfismo adicionam capacidades paralelas enquanto herança cria uma hierarquia. É porque ele cria uma hierarquia que a condição é-um se aplica. Mas essa condição não define herança. O que define herança é apenas e só o aumento do escopo. Voce pode extender classes com outras que não "são um". Isso não é sempre errado. Por exemplo, Stack extends Vector. Stack não é um vector, mas ele herda as mesmas operações. O conceito de herança como "é-um" é superficial e induz ao erro de pensar que é por isso que herança existe. Não é verdade.

O tem-um e é-um são formas de construir modelos de objetos. Sua implementação pode ser muito diferente conforme o paradigma que seguimos. Normalmente é-um pede herança, mas muitas vezes isso cria problemas (o famoso caso da pessoa fisica e juridica que herdam de pessoa. é-um parece ser a melhor forma de modelar, mas não é). A directiva tem-um pode ser implementa de várias formas desde um simples atributo até uma coleção com um unico elemento. As diretivas de modelagem têm formas padrão de se expressagem em java, e herança é a mais usada para é-um. Mas não tem sempre que ser assim.

Enfim, a directiva é-um é algo que existe em modelagem e que pode ser implementada com uso de herança, mas herança não foi criada apenas para expressar relações é-um. Ela foi criada para reaproveitar codigo numa forma hierarquica que se traduz por aumentar o escopo dos membros da classe a outra classes particular (a filha). O aumento do escopo é uma simples regra de visibilidade que o compilador força mas a JVM não controla.
Nem Herança nem o aumento do escopo são detalhes de implementação. Ou posto de outra forma: herança é o nome de uma forma especifica de aumento de escopo. Shadowing seria outra, por exemplo. O compilador entende essas regras e as força (compiladores diferentes, forçam regras diferentes).
A JVM apenas "dá-à-manivela" e faz tudo isso funcionar.

This message was edited 2 times. Last update was at 09/01/2008 10:10:04

Já sei porque estamos discutindo. Porque existem várias definições de herança. E nenhuma delas é mais correta ou adequada, porque elas dependem da ótica e do problema sendo analisados. Resolvi procurar na internet e achamos a definição, clássica, o Booch, que é mais parecida com a minha. Por outro lado, a definição de LaLonde, é muito próxima da sua. Só para citar grandes nomes da OO.

Herança, pode ser encarada apenas do ponto de vista da análise, que está preocupada mais com a relação entre os tipos e com o significado dessa relação do que aspectos de implementação. O exemplo da PessoaFisica e PessoaJurica, mostra uma relação de duas classes parecidas, mas que na verdade são entidades distintas. Por isso, não deviam pertencer a mesma hierarquia, ou então, não num nível tão baixo.

Então, como aqui é o GUJ e é do Java que estamos falando, resolvi procurar a definição de herança segundo a Sun. Infelizmente, no site da Sun a definição é ambígua o suficiente para dar margem a discussão (a boa e velha "herança é quando um objeto herda de outro"):
http://java.sun.com/docs/books/tutorial/java/concepts/inheritance.html

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? Também não, classes friend (do C++), por exemplo, não formam herança e aumentam escopo. Classes onde se faz: class x : private Y, também não formam herança (formam relação "é implementado em termos de") e também aumentam escopo.

Então, o que é específico nessa forma de aumento de escopo?

This message was edited 1 time. Last update was at 09/01/2008 10:28:57

Lintz_net wrote:Cara, eu não me lembro onde, mas eu já li que os membros private são herdados, porém, não são acessados... só não lembro onde foi que eu li.

Simples... Cria uma classe com um atributo privato e tenta utilizar este atributo em outra classe que a herda. Resultado?

Erro de compilação!!!

Herança deveria ser estudada do ponto de vista da OO...senão amanhã aparece uma nova linguagem orientada a objetos e vão dar a sua própria definição de Herança? Estranho...

PQP... catzo.

Só para compreender essa m.. toda que estão fazendo aqui.

Se eu tenho uma classe A e em baixo dela eu coloco um trangulo e outras classes abaixo desse triangulo (naquele diagrama de classe da UML que ninguém aqui sabe para que serve). Qual a idéia dessas classes?

Na idade da pedra da OO (Coad e Yourdon) chamavam isso de especialização, que era a forma de representar casos especiais ou de especializar uma superclasse. Como eu posso especilizar alguma coisa e ao mesmo tempo não ser essa coisa ou não ter partes dela.

Ou como eu posso passar no teste É UM se eu não tiver TODAS as características dessa coisa.

sinceramente senhores se a superclasse for constituída de um bit e eu criar uma subclasse que adicione outro bit, não importa a visibilidade do bit da superclasse, minha subclasse SEMPRE SERÁ (SER e NÃO TER) constituída por dois bits.

fw