herança de entidades

Entenda herança como um modo de impedir que classes possuam atributos/métodos iguais.
Por exemplo, você vai criar uma Pessoa para garantir que PessoaFisica e PessoaJuridica não repitam atributos e/ou métodos entre si.
Logo, coloque o id na classe Pessoa e, por herança, as três terão um método setId e um getId.

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionadades (metodos) e caracteriscas (propriedades)…

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionadades (metodos) e caracteriscas (propriedades)…
Distintas, não?
Pelo visto não fui bem interpretado.
Embora seja possível que existam duas ou mais classes que se relacionem por herança com métodos e até mesmo atributos iguais (definir qual iremos usar pode ser feito através das keywords super e this), a maior probabilidade é que façamos o “agrupamento” na superclasse e, se necessário, façamos uso do polimorfismo (em específico para métodos) para modificar o comportamento dos métodos que devem ter essa peculiaridade.

public class A{
    private String abc;
    public String getAbc(){
        return this.abc;
    }
}

public class AB extends A{
    public String getAbc(){
        return "Super: " + super.getAbc();
    }
}

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionadades (metodos) e caracteriscas (propriedades)…

Sinceramente não entendi o que estava errado…

Pode explicar Rafael?

vlw…

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionadades (metodos) e caracteriscas (propriedades)…
Sobrecarga é uma opção a ser aplicada quando temos que definir métodos com mesmo nome, porém, com parâmetros diferentes (por que uma cozinheira usa ingredientes distintos para preparar alimentos distintos, mas a ação é a mesma: preparar alimento).
Também é possível sobrecarregar atributos, quando temos uma relação de herança (caso contrário, teremos dois ou mais atributos com nome duplicado).
Quando falamos de sobrecarga de métodos em uma relação de herança, podemos estar tratando de um simples polimorfismo (quando a subclasse redefine o modo como o método funciona na superclasse) ou sobrecarga real (quando um novo método com mesmo nome é criado, mas com parâmetros diferentes).

public class A{
    private String abc;
    public String getAbc(){
        return this.abc;
    }
}

public class AB extends A{
    private String abc;//Sobrecarga de atributo
    public String getAbc(){//Polimorfismo, mesmo sem o @Override
        return this.abc + " " + super.getAbc();
    }

    public String getAbc(int opc){//Sobrecarga - método com mesmo nome, mas parâmetro diferente
        return (opc == 1) ? this.abc : super.getAbc();
    }
}

Isso bele, porém não entendi o que ele apontou como errado na sua primeira resposta, porque pra mim isso ficou claro…

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionadades (metodos) e caracteriscas (propriedades)…
Ah, isso também não é de todo verdade. Se você tiver atributos e/ou métodos precedidos do modificador de acesso private na super classe, eles são inacessíveis (e invisíveis) para todas as demais, incluindo as sub classes.
Caso estejamos falando de uma superclasse em um package e as sub classes em outro, se houver atributos sem modificador de acesso (ou com acesso default), estes serão inacessíveis (e invisíveis) para todas as classes externas ao package da super classe, incluindo suas subclasses.

Ola,

Na programação Orientada a Objetos (O.O), a herança é um mecanismo pelo qual uma classe obtém as características e modos de outra
para expandi -la ou especializá - la de alguma forma, ou seja, uma classe pode herdar características métodos e atributos de outras classes.

Da mesma maneira transmite suas características para outras classes, tornando aquelas que recebem suas características suas herdeiras.

Do ponto de vista prático da O.O, a herança é um mecanismo muito inteligente de aproveitamento de código.

A grande vantagem neste caso é o reúso de todo o código já implementado na classe pai, restando apenas implementar os métodos e atributos
que a diferenciam da classe pai.

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionalidades (métodos) e características (propriedades)…

Sinceramente não entendi o que estava errado…

Pode explicar Rafael?

vlw…

Homem e mulher ambos herdam tudo que o ser HUMANO tem e ambos RESPIRAM… então provavelmente a FUNÇÃO(método) de RESPIRAR de ambos sejam iguais. Ou seja POSSIBILIDADE…
Mas se considerarmos que o HOMEM tem um funcionamento corpóreo diferente e que o modo que ele RESPIRA é diferente da mulher… o FUNÇÃO(método) de RESPIRAR dele terá o mesmo nome… porém o que vai mudar é o como RESPIRA…
Dai Homem vai ter o seu próprio RESPIRAR e ainda vai ter o RESPIRAR que todo o humano tem…

Por isso que eu disse que PODE ‘COMPARTILHAR’…
Na herança o que determina que não pode haver um método iguais (mesmo nome e mesmos parâmetros) é a palavra chama FINAL na declaração do método na classe pai. Isso obriga a todo filho a nunca TER um método com mesmo nome e parâmetros iguais que estejam no pai.

Para a VM… método iguais desde que tenham mesmo nome, visibilidade, e parâmetros…
Você está falando de técnicas de especialização… e não da definição de herança em si. Para nós que já temos noção… sua definição está correta. Para que está aprendendo herança… complica um pouco… devido a outros pré-conhecimentos necessários…

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionadades (metodos) e caracteriscas (propriedades)…
Ah, isso também não é de todo verdade. Se você tiver atributos e/ou métodos precedidos do modificador de acesso private na super classe, eles são inacessíveis (e invisíveis) para todas as demais, incluindo as sub classes.
Caso estejamos falando de uma superclasse em um package e as sub classes em outro, se houver atributos sem modificador de acesso (ou com acesso default), estes serão inacessíveis (e invisíveis) para todas as classes externas ao package da super classe, incluindo suas subclasses.

Por isso eu coloquei POSSAM em maiúsculo. Pois podem compartlhar… não quer dizer que DEVEM compartilhar.
Até porque não faz sentido herdar uma classe que todos os atributos e métdos privados… pois a não haveria herança. (Nem sei se a VM permite herdar um classe que só tenha atributos privados).

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionalidades (métodos) e características (propriedades)…

Sinceramente não entendi o que estava errado…

Pode explicar Rafael?

vlw…

Homem e mulher ambos herdam tudo que o ser HUMANO tem e ambos RESPIRAM… então provavelmente a FUNÇÃO(método) de RESPIRAR de ambos sejam iguais. Ou seja POSSIBILIDADE…
Mas se considerarmos que o HOMEM tem um funcionamento corpóreo diferente e que o modo que ele RESPIRA é diferente da mulher… o FUNÇÃO(método) de RESPIRAR dele terá o mesmo nome… porém o que vai mudar é o como RESPIRA…
Dai Homem vai ter o seu próprio RESPIRAR e ainda vai ter o RESPIRAR que todo o humano tem…

Claro. Num contexto como o sistema de cadastro de clientes essa diferença é totalmente plausível, não?
Entendo o teu ponto de vista, mas para tratarmos um objeto e, então, definirmos sua classe, temos que considerar o escopo no qual este objeto está inserido.
Um sistema hospitalar deve considerar a religião do paciente, que é um ser humano. Independente de ter um útero ou uma bolsa escrotal, ele é um ser humano e cuja religião pode afetar procedimentos cirúrgicos (algumas religiões não permitem transfusão sanguínea).

Engraçado que aqui você cita técnicas de especialização e abaixo questiona minha informação? Legal…

Opá… olha a Sobrecarga ai…
A herança prove que classe destintas POSSAM “compartilhar” as mesmas funcionadades (metodos) e caracteriscas (propriedades)…
Ah, isso também não é de todo verdade. Se você tiver atributos e/ou métodos precedidos do modificador de acesso private na super classe, eles são inacessíveis (e invisíveis) para todas as demais, incluindo as sub classes.
Caso estejamos falando de uma superclasse em um package e as sub classes em outro, se houver atributos sem modificador de acesso (ou com acesso default), estes serão inacessíveis (e invisíveis) para todas as classes externas ao package da super classe, incluindo suas subclasses.

Por isso eu coloquei POSSAM em maiúsculo. Pois podem compartlhar… não quer dizer que DEVEM compartilhar.
Até porque não faz sentido herdar uma classe que todos os atributos e métdos privados… pois a não haveria herança. (Nem sei se a VM permite herdar um classe que só tenha atributos privados).
Permite. Isso me daria um certo nível de polimorfismo, como implementar a interface Serializable…

Ae, vcs estão viajando… rs… Eu sei o que é sobrecarga, herança, etc…

A minha dúvida não é sobre o que é e sim o que voccê achou de errado na primeira explicação do drsmachado.

Não tenho dúvidas sobre OO (ou pelo menos não sobre isso), minha dúvida foi apenas em porque corrigiu a explicação dele…

joaoabi:

Do ponto de vista prático da O.O, a herança é um mecanismo muito inteligente de aproveitamento de código.

A grande vantagem neste caso é o reúso de todo o código já implementado na classe pai, restando apenas implementar os métodos e atributos
que a diferenciam da classe pai.

Na verdade isso já caiu por terra, não herde uma classe porque quer aproveitar código. A herança define uma relação de identidade com a classe pai, ou seja, uma classe filho é um tipo da classe pai. A interface define uma relação de comportamento, ou seja, a classe que implementa se comporta como a interface.

Além disso, a herança pode, inclusive, violar o encapsulamento das classes, acabando por quebrar um dos princípios básicos da Orientação a Objetos. Ela também cria um acoplamento por vezes desnecessário, já que a classe filho precisa conhecer detalhes de implementação da classe pai.

Nunca, nunca mesmo, herde uma classe para aproveitar código.Melhor ainda: evite usar herança em qualquer caso. Utilize composição em vez disso.

Alguns textos sobre o assunto:

http://craigpardey.com/wp/2012/07/anti-pattern-re-use-through-inheritance/
http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/

diogogama:

Ae, vcs estão viajando… rs… Eu sei o que é sobrecarga, herança, etc…

A minha dúvida não é sobre o que é e sim o que voccê achou de errado na primeira explicação do drsmachado.

Não tenho dúvidas sobre OO (ou pelo menos não sobre isso), minha dúvida foi apenas em porque corrigiu a explicação dele…

Ataxexe:

joaoabi:

Do ponto de vista prático da O.O, a herança é um mecanismo muito inteligente de aproveitamento de código.

A grande vantagem neste caso é o reúso de todo o código já implementado na classe pai, restando apenas implementar os métodos e atributos
que a diferenciam da classe pai.

Na verdade isso já caiu por terra, não herde uma classe porque quer aproveitar código. A herança define uma relação de identidade com a classe pai, ou seja, uma classe filho é um tipo da classe pai. A interface define uma relação de comportamento, ou seja, a classe que implementa se comporta como a interface.

Além disso, a herança pode, inclusive, violar o encapsulamento das classes, acabando por quebrar um dos princípios básicos da Orientação a Objetos. Ela também cria um acoplamento por vezes desnecessário, já que a classe filho precisa conhecer detalhes de implementação da classe pai.

Nunca, nunca mesmo, herde uma classe para aproveitar código.Melhor ainda: evite usar herança em qualquer caso. Utilize composição em vez disso.

Alguns textos sobre o assunto:

http://craigpardey.com/wp/2012/07/anti-pattern-re-use-through-inheritance/
http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/

Ataxexe:

joaoabi:

Do ponto de vista prático da O.O, a herança é um mecanismo muito inteligente de aproveitamento de código.

A grande vantagem neste caso é o reúso de todo o código já implementado na classe pai, restando apenas implementar os métodos e atributos
que a diferenciam da classe pai.

Na verdade isso já caiu por terra, não herde uma classe porque quer aproveitar código. A herança define uma relação de identidade com a classe pai, ou seja, uma classe filho é um tipo da classe pai. A interface define uma relação de comportamento, ou seja, a classe que implementa se comporta como a interface.

Além disso, a herança pode, inclusive, violar o encapsulamento das classes, acabando por quebrar um dos princípios básicos da Orientação a Objetos. Ela também cria um acoplamento por vezes desnecessário, já que a classe filho precisa conhecer detalhes de implementação da classe pai.

Nunca, nunca mesmo, herde uma classe para aproveitar código.Melhor ainda: evite usar herança em qualquer caso. Utilize composição em vez disso.

Alguns textos sobre o assunto:

http://craigpardey.com/wp/2012/07/anti-pattern-re-use-through-inheritance/
http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/

Eu em momento algum do disse a ele para usar herança(eu mesmo prefiro usar composição ao invés de herança), nem que herança era pra ser usada ou não usada, eu apenas defini herança.
E acredito que do ponto de vista conceitual minha definição esta correta, caso no esteja perdão me deem a certa e terei prazer em aprender.

Não tive intenção de dizer para ele usar ou não este mecanismo.
E relendo o que escrevi, não disse.

Com relação a quebrar o encapsulamento isso só ocorre se você declara um método ou uma classe como estática e ou se houver declaração de
atributos, metodos etc como public…

Abraço!

joaoabi:

Eu em momento algum do disse a ele para usar herança(eu mesmo prefiro usar composição ao invés de herança), nem que herança era pra ser usada ou não usada, eu apenas defini herança.
E acredito que do ponto de vista conceitual minha definição esta correta, caso no esteja perdão me deem a certa e terei prazer em aprender.

Não tive intenção de dizer para ele usar ou não este mecanismo.
E relendo o que escrevi, não disse.

Com relação a quebrar o encapsulamento isso só ocorre se você declara um método ou uma classe como estática e ou se houver declaração de
atributos, metodos etc como public…

Abraço!

Só estou dizendo para tomarem cuidado porque ela é considerada por muitos uma má prática. Por isso eu disse para não usarem. E em momento algum questionei sua definição, estou alertando para uma coisa que hoje não é mais vista como antes (tal qual o famoso Singleton, considerado por muitos autores como um Anti-Pattern).

Tá difícil alertar os GUJeiros por aqui ultimamente. O povo anda levando tudo pro lado errado.

Ataxexe:

joaoabi:

Do ponto de vista prático da O.O, a herança é um mecanismo muito inteligente de aproveitamento de código.

A grande vantagem neste caso é o reúso de todo o código já implementado na classe pai, restando apenas implementar os métodos e atributos
que a diferenciam da classe pai.

Na verdade isso já caiu por terra, não herde uma classe porque quer aproveitar código. A herança define uma relação de identidade com a classe pai, ou seja, uma classe filho é um tipo da classe pai. A interface define uma relação de comportamento, ou seja, a classe que implementa se comporta como a interface.

Além disso, a herança pode, inclusive, violar o encapsulamento das classes, acabando por quebrar um dos princípios básicos da Orientação a Objetos. Ela também cria um acoplamento por vezes desnecessário, já que a classe filho precisa conhecer detalhes de implementação da classe pai.

Nunca, nunca mesmo, herde uma classe para aproveitar código.Melhor ainda: evite usar herança em qualquer caso. Utilize composição em vez disso.

Alguns textos sobre o assunto:

http://craigpardey.com/wp/2012/07/anti-pattern-re-use-through-inheritance/
http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/

Então você está dizendo que devemos tentar evitar um dos pilares da OO?

Provavelmente não tenho o mesmo conhecimento que o seu, mas não me pareceu um conselho correto, visto que OO se resume a:
· Abstração

· Encapsulamento

· Herança

· Polimorfismo

será que estou pensando errado???

drsmachado:

diogogama:

Ae, vcs estão viajando… rs… Eu sei o que é sobrecarga, herança, etc…

A minha dúvida não é sobre o que é e sim o que voccê achou de errado na primeira explicação do drsmachado.

Não tenho dúvidas sobre OO (ou pelo menos não sobre isso), minha dúvida foi apenas em porque corrigiu a explicação dele…

Acho que está rolando um flash mob para minar tudo o que eu digo no guj… Acho…
Enfim, ele está certo. Sob determinadas circunstâncias o que eu disse pode acabar confundindo. Ele já explicou depois.

Ok, mas não acho que foi o caso… mas bele então…

diogogama:

Ataxexe:

joaoabi:

Do ponto de vista prático da O.O, a herança é um mecanismo muito inteligente de aproveitamento de código.

A grande vantagem neste caso é o reúso de todo o código já implementado na classe pai, restando apenas implementar os métodos e atributos
que a diferenciam da classe pai.

Na verdade isso já caiu por terra, não herde uma classe porque quer aproveitar código. A herança define uma relação de identidade com a classe pai, ou seja, uma classe filho é um tipo da classe pai. A interface define uma relação de comportamento, ou seja, a classe que implementa se comporta como a interface.

Além disso, a herança pode, inclusive, violar o encapsulamento das classes, acabando por quebrar um dos princípios básicos da Orientação a Objetos. Ela também cria um acoplamento por vezes desnecessário, já que a classe filho precisa conhecer detalhes de implementação da classe pai.

Nunca, nunca mesmo, herde uma classe para aproveitar código.Melhor ainda: evite usar herança em qualquer caso. Utilize composição em vez disso.

Alguns textos sobre o assunto:

http://craigpardey.com/wp/2012/07/anti-pattern-re-use-through-inheritance/
http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/

Então você está dizendo que devemos tentar evitar um dos pilares da OO?

Provavelmente não tenho o mesmo conhecimento que o seu, mas não me pareceu um conselho correto, visto que OO se resume a:
· Abstração

· Encapsulamento

· Herança

· Polimorfismo

será que estou pensando errado???

Mas assim não né, meu senhor. Você té colocando contexto… cada contexto tem suas particularidades.
Você tá tentando tirar o conceito de herança de um exemplo prático para tentar explicar.
Eu quis mostrar um exemplo de herança… hora nenhuma disse que ele é o único tipo de herença que existe. Mas falar que herança proíbe que métodos iguais está longe de tá certo para uma pessoas que não tem noções de como se comporta o relacionamento de classes…

Como eu disse… eu entendi o que você queria dizer… mas não serão todos. Principalmente quem está aprendendo o que é sobrecarga agora.
Como e já disse… sem contexto… Herança PROMOVE que classes distintas passam COMPARTILHAR mesmos atributos e métodos. Mas isso não significa que DEVAM compartihar…
Não adianta vir com o sistema de gestão de negócio… porque cada negócio tem suas regras de domino diferentes.

Cara você pode ser um excelente programador. Mas é um péssimo interpretador de texto.
Onde falar de controle de acesso, parametros e nome de método é técnicas de especialização??? Técnicas de especialização são estratégia e meios de como a especialização é feita e não a definição dela!

Cara não adianta. Você pode até não aceitar ou ter seu ponto de vista. Mas que você disse fere o conceito de sobrecarga.
Dai veio tentando corrigir com uso de THIS e SUPER… o THIS nem é mais usado explicitamente em herança… visto que a VM SEMPRE procura o a propriedade na classe chamadora e caso não tenha ele vai descendo na árvore de herança.

Pelo visto você ainda vai teimar…
Então aconselho a todos que estajam com duvidas a esse assunto. Considerar a resposta do joaoabi

E sejamos todos felizes!

No hard feeling drsmachado!

diogogama:

drsmachado:

diogogama:

Ae, vcs estão viajando… rs… Eu sei o que é sobrecarga, herança, etc…

A minha dúvida não é sobre o que é e sim o que voccê achou de errado na primeira explicação do drsmachado.

Não tenho dúvidas sobre OO (ou pelo menos não sobre isso), minha dúvida foi apenas em porque corrigiu a explicação dele…

Acho que está rolando um flash mob para minar tudo o que eu digo no guj… Acho…
Enfim, ele está certo. Sob determinadas circunstâncias o que eu disse pode acabar confundindo. Ele já explicou depois.

Ok, mas não acho que foi o caso… mas bele então…

Rafael_Leal:

drsmachado:

Claro. Num contexto como o sistema de cadastro de clientes essa diferença é totalmente plausível, não?
Entendo o teu ponto de vista, mas para tratarmos um objeto e, então, definirmos sua classe, temos que considerar o escopo no qual este objeto está inserido.
Um sistema hospitalar deve considerar a religião do paciente, que é um ser humano. Independente de ter um útero ou uma bolsa escrotal, ele é um ser humano e cuja religião pode afetar procedimentos cirúrgicos (algumas religiões não permitem transfusão sanguínea).

Mas assim não né, meu senhor. Você té colocando contexto… cada contexto tem suas particularidades.
Você tá tentando tirar o conceito de herança de um exemplo prático para tentar explicar.
Eu quis mostrar um exemplo de herança… hora nenhuma disse que ele é o único tipo de herença que existe. Mas falar que herança proíbe que métodos iguais está longe de tá certo para uma pessoas que não tem noções de como se comporta o relacionamento de classes…

Como eu disse… eu entendi o que você queria dizer… mas não serão todos. Principalmente quem está aprendendo o que é sobrecarga agora.
Como e já disse… sem contexto… Herança PROMOVE que classes distintas passam COMPARTILHAR mesmos atributos e métodos. Mas isso não significa que DEVAM compartihar…
Não adianta vir com o sistema de gestão de negócio… porque cada negócio tem suas regras de domino diferentes.

Cara você pode ser um excelente programador. Mas é um péssimo interpretador de texto.
Onde falar de controle de acesso, parametros e nome de método é técnicas de especialização??? Técnicas de especialização são estratégia e meios de como a especialização é feita e não a definição dela!

Cara não adianta. Você pode até não aceitar ou ter seu ponto de vista. Mas que você disse fere o conceito de sobrecarga.
Dai veio tentando corrigir com uso de THIS e SUPER… o THIS nem é mais usado explicitamente em herança… visto que a VM SEMPRE procura o a propriedade na classe chamadora e caso não tenha ele vai descendo na árvore de herança.

Pelo visto você ainda vai teimar…
Então aconselho a todos que estajam com duvidas a esse assunto. Considerar a resposta do joaoabi

E sejamos todos felizes!

No hard feeling drsmachado!

drsmachado:

diogogama:

drsmachado:

diogogama:

Ae, vcs estão viajando… rs… Eu sei o que é sobrecarga, herança, etc…

A minha dúvida não é sobre o que é e sim o que voccê achou de errado na primeira explicação do drsmachado.

Não tenho dúvidas sobre OO (ou pelo menos não sobre isso), minha dúvida foi apenas em porque corrigiu a explicação dele…

Acho que está rolando um flash mob para minar tudo o que eu digo no guj… Acho…
Enfim, ele está certo. Sob determinadas circunstâncias o que eu disse pode acabar confundindo. Ele já explicou depois.

Ok, mas não acho que foi o caso… mas bele então…

Foi uma brincadeira apenas.

Falei que não foi o caso da correção do cara, não da sua brincadeira… Não acho que a interpretação que ele sugeriu se daria a ocasião, sacou???

drsmachado:

diogogama:

Ataxexe:

joaoabi:

Do ponto de vista prático da O.O, a herança é um mecanismo muito inteligente de aproveitamento de código.

A grande vantagem neste caso é o reúso de todo o código já implementado na classe pai, restando apenas implementar os métodos e atributos
que a diferenciam da classe pai.

Na verdade isso já caiu por terra, não herde uma classe porque quer aproveitar código. A herança define uma relação de identidade com a classe pai, ou seja, uma classe filho é um tipo da classe pai. A interface define uma relação de comportamento, ou seja, a classe que implementa se comporta como a interface.

Além disso, a herança pode, inclusive, violar o encapsulamento das classes, acabando por quebrar um dos princípios básicos da Orientação a Objetos. Ela também cria um acoplamento por vezes desnecessário, já que a classe filho precisa conhecer detalhes de implementação da classe pai.

Nunca, nunca mesmo, herde uma classe para aproveitar código.Melhor ainda: evite usar herança em qualquer caso. Utilize composição em vez disso.

Alguns textos sobre o assunto:

http://craigpardey.com/wp/2012/07/anti-pattern-re-use-through-inheritance/
http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/

Então você está dizendo que devemos tentar evitar um dos pilares da OO?

Provavelmente não tenho o mesmo conhecimento que o seu, mas não me pareceu um conselho correto, visto que OO se resume a:
· Abstração

· Encapsulamento

· Herança

· Polimorfismo

será que estou pensando errado???

Sim.
Não é por que é possível pela OO que deve ser usado. Aliás, deve sim, mas com parcimônia.
A herança trava muito da flexibilidade da OO, ainda mais em java, onde não pode-se usar herança múltipla. Com agregação e composição é mais fácil trabalhar. É apenas isso que o ataxexe quis dizer.

Mas olha só, eu estive uma vez em uma palestra do Paulo Silveira sobre boas práticas na orientação a objeto e aprendi que uma das melhores formas seria uma programação orientada a interface e que nas assinaturas dos métodos não deveríamos tentar restringir. ex:

usar ArrayList ou List, era preferível eu usar um Collection e quem fosse assinar que pegaria e faria o tipo que quisesse…

Mas para fazer isso, eu preciso ter em mente que o que rege é a herança… eu recebo um método extendido de pessoa, se vai ser homem ou mulher pouco me importa…

Será que eu consegui explicar o que eu queria??? rs…

qualquer dúvida me fala que tento melhorar a explicação…

diogogama:

Mas olha só, eu estive uma vez em uma palestra do Paulo Silveira sobre boas práticas na orientação a objeto e aprendi que uma das melhores formas seria uma programação orientada a interface e que nas assinaturas dos métodos não deveríamos tentar restringir. ex:

usar ArrayList ou List, era preferível eu usar um Collection e quem fosse assinar que pegaria e faria o tipo que quisesse…

Mas para fazer isso, eu preciso ter em mente que o que rege é a herança… eu recebo um método extendido de pessoa, se vai ser homem ou mulher pouco me importa…

Será que eu consegui explicar o que eu queria??? rs…

qualquer dúvida me fala que tento melhorar a explicação…

drsmachado:

Exato, está certo.
Quando você tem um método, deve prepará-lo para tratar qualquer tipo de pessoa e não apenas uma. Deve, ainda, pensar que futuramente pode existir um novo tipo de pessoa (PessoaFisicaJuridica) e que você terá de tratar também.

Mas para que eu faça isso eu não preciso ter bem defino e trabalhar muito bem com o conceito de Herança???

diogogama:

drsmachado:

Exato, está certo.
Quando você tem um método, deve prepará-lo para tratar qualquer tipo de pessoa e não apenas uma. Deve, ainda, pensar que futuramente pode existir um novo tipo de pessoa (PessoaFisicaJuridica) e que você terá de tratar também.

Mas para que eu faça isso eu não preciso ter bem defino e trabalhar muito bem com o conceito de Herança???

Não! Você pode fazer isso com interfaces, sem usar herança.

Ataxexe:

diogogama:

drsmachado:

Exato, está certo.
Quando você tem um método, deve prepará-lo para tratar qualquer tipo de pessoa e não apenas uma. Deve, ainda, pensar que futuramente pode existir um novo tipo de pessoa (PessoaFisicaJuridica) e que você terá de tratar também.

Mas para que eu faça isso eu não preciso ter bem defino e trabalhar muito bem com o conceito de Herança???

Não! Você pode fazer isso com interfaces, sem usar herança.

Ok, mas eu posso receber um Collection porque List herda dela, não???

e não porque implementa, correto???

ou me enganei???

diogogama:

Ataxexe:

diogogama:

drsmachado:

Exato, está certo.
Quando você tem um método, deve prepará-lo para tratar qualquer tipo de pessoa e não apenas uma. Deve, ainda, pensar que futuramente pode existir um novo tipo de pessoa (PessoaFisicaJuridica) e que você terá de tratar também.

Mas para que eu faça isso eu não preciso ter bem defino e trabalhar muito bem com o conceito de Herança???

Não! Você pode fazer isso com interfaces, sem usar herança.

Ok, mas eu posso receber um Collection porque List herda dela, não???

e não porque implementa, correto???

ou me enganei???

Sim, mas aí é herança de interfaces, não de classes (que é completamente diferente no sentido Anti Pattern da coisa).

A herança a que me referi anteriormente era exclusivamente a herança de classes. Acho que foi por isso que você se confundiu.

Obg, já consegui solucionar o problema.
Tópico resolvido.
Quanta polemica a proposito…
Valeu =]

Gutofbnk:

Obg, já consegui solucionar o problema.
Tópico resolvido.
Quanta polemica a proposito…
Valeu =]

Polêmica não amigão… Aprendizado…

Esquece de colocar [RESOLVIDO] na frente do tópico…

Ataxexe:

Sim, mas aí é herança de interfaces, não de classes (que é completamente diferente no sentido Anti Pattern da coisa).

A herança a que me referi anteriormente era exclusivamente a herança de classes. Acho que foi por isso que você se confundiu.

Então não é uma boa prática eu criar uma classe que implementa serializable e atributos e métodos e outras herdarem dela???

Ou seja, de um modo geral, ex:

public class Animal {

       private String raça;

       public Animal() {
       }

       public void anda {
               .
               .
               .
        }
}

public class Gato extends Animal {
         .
         .
         .
}

isso estaria errado segundo as boas práticas??? Sinceramente não to conseguindo entender.... Que um dos pilares (visto que dele se tem tmb o polimorfismo) seria uma má prática....

diogogama:

Ataxexe:

Sim, mas aí é herança de interfaces, não de classes (que é completamente diferente no sentido Anti Pattern da coisa).

A herança a que me referi anteriormente era exclusivamente a herança de classes. Acho que foi por isso que você se confundiu.

Então não é uma boa prática eu criar uma classe que implementa serializable e atributos e métodos e outras herdarem dela???

Ou seja, de um modo geral, ex:

public class Animal {

       private String raça;

       public Animal() {
       }

       public void anda {
               .
               .
               .
        }
}

public class Gato extends Animal {
         .
         .
         .
}

isso estaria errado segundo as boas práticas??? Sinceramente não to conseguindo entender.... Que um dos pilares (visto que dele se tem tmb o polimorfismo) seria uma má prática....

Não foi isso que eu disse. Eu disse que a herança de interfaces é algo sadio:

public interface MinhaInterface extends Serializable {
// métodos aqui
}

public interface List<E> extends Collection<E> {
// bla bla bla
}

O problema da herança é que ela quase nunca é utilizada como uma especialização (na grande maioria das vezes é somente para aproveitamento de código) e, nas vezes em que é utilizada como uma especialização, pode quebrar o encapsulamento das classes e gerar dependências de implementação entre elas. Acaba que, em muitos casos, os pontos negativos vindos do uso da herança não valem a pena pelos pontos positivos. Um exemplo besta:

public class Pilha<E> extends ArrayList<E> {
}

Perceba que eu acabei vinculando a minha Pilha a uma implementação direta de ArrayList. Se eu quiser alterar o comportamento dela eu não consigo muita coisa porque estarei preso à implementação de ArrayList. É muito mais flexível trabalhar assim:

public class Pilha<E> {
  private List<E> lista;
  public Pilha(List<E> lista) {
    this.lista = lista;
  }
  // outras coisas aqui
}

Dessa forma eu posso passar o List mais adequado para cada situação. Claro que existem alguns problemas nesse exemplo, mas se atente apenas ao fato de que é uma má ideia se acoplar com uma implementação.

Esse é o cuidado que se deve ter com herança. Geralmente, usar herança impossibilita a abstração (como no exemplo da Pilha, onde eu não pude abstrair a lista, ficando "preso" à implementação de ArrayList).

Outros pontos:

1- Muitos autores consideram por boa prática abolir a herança em favor da composição.
2- O polimorfismo não vem somente da herança, você pode tê-lo com interfaces.

Entendi, mas acho que essa regra não se aplica a todos os casos de herança, porém concordo que na maioria das vezes seria melhor…

Mas vlw pela explicação.