Bom já ouvi falar que o Super() chama o construtor da classe pai…
Mas na prática não consigo entender isso, já herdei de uma classe os métodos (extends) e essa declaração no construtor da classe filha (super()
não fez diferença alguma…
Se alguém puder me explicar e mostrar um exemplo ficarei muito grato
Isso, o super vai chamar o construtor da classe pai.
A tua classe pai tem algum código no construtor? Coloca um System.out.println por lá que tu vai ver.
O super chama o construtor da classe mae, podendo ser mais de um contrutor na classe mae, por exemplo, super() ou super(15).
Imagina que vc tenha a classe pessoa, mae da classe mulher, mas na classe pessoa o atributo de nome e prvado, entao mulher nao tera acesso, no caso de um sistema que nao muda o nome da pessoa vc pode criar o contrutor pessoa(String nome) que instancia a classe com o nome dado, quando for instancias mulher ela podera iniciar o campo nome que em sua classe mae e privado.
Desculpa a falta de acentuacao, mas ainda nao peguei como fazer, maquina nova : )
isso vai fazer diferença quando tiver algum código no construtor da sua classe pai…
dependendo dos casos, talves isso não funcionasse direito se o construtor da classe pai não fosse chamado ja que normalmente la tem (ou deveria ter) codigos para inicialisar as variaveis do objeto…
Sinceramente o super() é apenas mais uma maneira de errar na herança …
Hehehe …
A palestra super determina que, mesmo existindo um método com o mesmo nome no filho, será executado o método do pai.
O super() chama o construtor do pai, os que é muito interessante quando as aplicações realmente trabalham orientadas a objeto.
Não considero como mais uma maneira de errar na herança e sim uma característica da linguagem que, se bem utilizada pode ajudar o programador em algumas situações.
Pelo que vi as respostas abaixo são suficientes para esclarecer. Portanto indique que foi resolvido ou nos questione novamente.
Qualquer dúvida é só gritar!
[quote=ccefetpb]Sinceramente o super() é apenas mais uma maneira de errar na herança …
Hehehe …[/quote]
Pode explicar a resposta?
Desculpe se causei polemica , bem …
Um programador JAVA experiente sabe que herança é uma faca de dois gumes , tem o lado bom e o lado ruim .
E acredite o lado ruim é ruim , lembro que qndo estava aprendendo java em meu primeiro projeto JAVA , um joguinho de rpg , tive que fazer refatoramento em umas 20 classes ( pq usava herança ).
Dito isso , e sendo sabido que a maioria das pessoas prefere a composição a herança , vamo tomar como premissa que herança é uma coisa ruim ( pelo menos pra min , claro que deve haver todo um estudo antes de falar isso ou de negar a herança em um projeto , mas pra MIM : COMPOSIÇÂO IS BETTER , note a enfase que essa é minha opinião e niguem tem que concordar ).
Bem voltando , herança é uma forma de errar no projeto ( por favor não vamos discutir aqui se isso é verdade ou não , só estou tentando explicar minha opinião ) , algo comum que fazia quando aprendi java é colocar construtor com parametros inicializando os atributos :
public class Pessoa {
//atributos
public Pessoa(String nome,String cpf) {
this.setNome(nome);
this.setCPF(cpf);
}
//gets and sets
}Agora , como é comum na POO , começam a surgir novas classes na sua hierarquia usando herança fica algo assim :
public Funcionario extends Pessoa {
//novo atributo
private String cargo;
public Funcionario(String nome , String cpf , String cargo) {
setNome(nome);
setCPF(cpf);
setCargo(cargo);
}
//gets and sets
}Pois bem , para boa parte dos programadores novos da linguagem , e sem a ajuda de uma IDE , o código acima esta correto .
Voce consegeu achar o erro ?
bem o erro e que pra construir um Funcionario vc construir Pessoa , mas pra construir uma pessoa vc precisa de nome e cpf.
Entao está faltando um “super()” lá dentro do construtor …
Sei la , talvez meu comentário foi infeliz mais é isso ai ! Tenho direito a opinião.
O codigo correto é :
public class Funcionario extends Pessoa{
public String cargo;
public Funcionario(String nome, String cpf) {
super(nome, cpf);
setCargo(cargo);
}
public String getCargo() {
return cargo;
}
public void setCargo(String cargo) {
this.cargo = cargo;
}
}=P
Ou seja errei por causa do super logo o super e mais um dos erros que podem surgir por causa da herança ( outros erros : o losango mortal , uso errado da sobreposicao ou sobrecarga e etc. ).
O ccefetpb deu uma boa explicação na utilização do super(), mas acho que faltou falar uma coisa… Fora por umas duas linhas a menos no código, porquê isso seria bom?
Bem, vejamos… Imagine que no construtor da classe Pessoa vc tenha algum método de validação do CPF e outros métodos para validar toda a entrada. Sem aplicar o super(), você teria que copiar muita coisa para a classe Funcionario, que extende Pessoa. Aplicando o construtor super(), ele faria todos os testes de validação presentes na classe Pessoa e depois só teria que incluir o novo atributo cargo. :lol:
Usar o super() nessas ocasiões é uma boa prática de programação.
[quote=ccefetpb]…
[/quote]
boa a sua explicação, herança deve ser evitado na maioria dos casos (até ai eu ainda concordo), mais quando for usada a herança, ainda me parece bom que sejam iniciados também os atributos da classe pai, especialmente se você for usar na classe filha…
no use a cabeça padrões de projetos, ja no primeiro capitulo sobre o padrão strategy, mostra uns problemas relativos a herança, aparentemente parecidos com os problemas que você deve ter tido, explicando também muito bem por que seria melhor a composição de um objeto para acessar seus atributos (respeitando é claro o encapsulamento), mais mesmo nesse exemplo o proprio objeto decomposto também era de um supertipo…
bom, o que eu to tentando dizer é que eu concordo que herança seja ruim provavelmente na maioria, dos casos, mas isso é diferente de ser ruim sempre, é só uma questão de saber modelar direito… assim como os proprios patterns, deve-se saber quando aplicar.
o que o Marcos Lima disse é um bom exemplo de por que o super pode ser util… ainda acho (talvez teimosia minha) como antes tinha dito, que é util aproveita o código da classe pai, conforme o exemplo dado…
acho interessante essa discussão, até por que esta sendo feita de forma sadia, tem um conteudo legal e é um debate não uma troca de ofensas…
Só algumas observações:
a) Não se deve usar setters em construtores, a menos que eles sejam finais. Afinal, você pode fazer sobrecarga nesses métodos e, se isso ocorrer, você vai estar chamando um método de uma classe não completamente construída;
b) O super, pelo que ele explicou, é uma maneira de acertar na herança, não de errar.
c) Diamante da morte é um problema que só ocorre na herança múltipla, coisa que não existe no java.
Realmente, é difícil acertar com herança. São raros os casos onde ela é realmente necessária, mas nesses casos, o super exerce papel fundamental, seja na chamada do construtor, seja em métodos, para a execução do comportamento da superclasse. Ele permite que você crie comportamento adicional, sem a necessidade de reimplementar tudo.
O ideal mesmo é procurar manter a hierarquia de classes coesa, ou seja, com cada classe desempenhando um pequeno papel no sistema. E a herança vai contra essa idéia, já que classes finais da hierarquia tendem a serem muito grandes e sobrecarregadas.
Bem não fazendo propaganda …
Mas aprendi a programar java literalmente pelo Use a Cabeça !
Li o use a cabeça JAVA e aprendi todos os conceitos , fui fazer o projeto do jogo de RPG e PEI !
Descobri que embora soubesse os conceitos não significava saber programar , errei tanto .Minha professora na epoca falou que eu não sabia programar .Eu pensei ta dando trabalho mas ta pegando é isso conta alguem ja ouviu falar disso ( http://gohorseprocess.wordpress.com/ )
Ledo engano …
Ai resolvi aprender padrões e qual não foi minha surpresa ao conhecer o USe a Cabeça Padrões de Projetos . Li o livro inteiro nas ferias , ja li mais de uma vez até.
Li tambem o use a cabeça SQL , Jsp e Servlet e EJB ( em ingles ).
Acho o livro mais didático e …
Bem voltando ao assunto concordo com os dois ultimos comentarios em resumo : “Não existe o certo e o errado existe o mais indicado .Qndo optar pelo menos indicado use com moderação e estude como isso vai afetar seu projeto no futuro , afinal citando o use a cabeça padrões de projeto - A unica verdade no desenvolvimento de software e a ALTERAÇÂO”.
Concordo com você. Não é à toa que livros como Padrões de Projeto, Refatoração e Effetive Java (ou qualquer outro similar para a linguagem que você quer programar), deveriam ser leitura obrigatória para qualquer um da área.
Mas é a experiência que dá o balisador do que é programar mal e bem. Mesmo para usar padrões, você depende de escolhas e dificilmente você fará as certas, sem ter batido a cabeça por muito tempo em escolhas erradas.