Boa tarde!
qual a diferença entre esses dois metodos construtores?
String nome;
public Exemplo(String nome){
setNome(nome);
}
public Exemplo(String nome){
this.nome = nome;
}
qual usar?
Bom dia Colegas !
Opinião pessoal: não vejo sentido em usar metodos set e get dentro da própria classe.
A não ser que eles tenham alguma regra embutida, tipo:
public void setValor(int valor) {
if (valor < 0) {
this.valor = 0;
} else {
this.valor = valor;
}
}[]s
se essa classe exemplo estiver extendendo ou implementando ha uma diferença sim, agora se nao é mais questao de leitura mesmo (na minha opniao) e “1 passo” a mais pra jvm 
ja q ela ao inves de apenas atribuir o valor ela vai ter q chamar o metodo antes d atribuir o valor… mas é inperseptivel em questao d tempo
Bom dia Colegas !
andrerios:
Poderia explicar a diferença caso a classe esteja extendendo ou implementando ?
[]s
pq se vc estiver extendendo esse metodo setNome pode estar vindo d alguma superclasse… dai lá pode haver alguma outra validacao ou ate mesmo outro atributo nome… entao o this.nome so serve se for um atributo da propria classe Exemplo e nao d uma super classe (se for private)
Bom dia Colegas !
Entendi…
É que tomei por premissa que fazendo this.nome significava que o atributo era da própria classe…
[]s
[quote=Luciano Danilo]Boa tarde!
qual a diferença entre esses dois metodos construtores?
[/quote]
não se diz “método contrutor” isso é errado. Um método não é um construtor e vice-versa.
A frase seria “Qual a diferença entre estes dois construtores?”
(Métodos e Construtores são menbros da classe e têm uma declaração muito semelhante, mas não são
a mesma coisa. Construtores não são métodos.)
[quote]
String nome;
public Exemplo(String nome){
setNome(nome);
}
public Exemplo(String nome){
this.nome = nome;
}
qual usar?[/quote]
O segundo.
O primeiro invoca um método , o segundo faz uma atribuição a um atributo da classe.
Invocar o método não garante que a atribuição será feita e portanto o estado do objeto pode ficar
“capenga”. Nesse caso o construtor criou um objeto com estado inválido o que vai contra as regras de um construtor.
Por isso se deve usar a segunda opção já que não tem como o estado ser inválido dessa forma.
Boa tarde Colegas !
sergiotaborda:
Mas utilizar método set não seria justamente para garantir que o objeto fique com um valor válido ?
Não sei, mas como no exemplo que falei:
public void setValor(int valor) {
if (valor < 0) {
this.valor = 0;
} else {
this.valor = valor;
}
}
Se o construtor atribuir diretamente ao atributo ele irá ficar com um valor negativo, o que nesse exemplo, não seria um valor válido…
[]s
Vejo que usar setters no construtor pode abrir as pernas para que uma classe filha mude o comportamento de um setter e não iniciar as variáveis corretamente. (Exemplo: setNome() da classe Derivada possui conteúdo vazio.)
A questão de desempenho é irrelevante. Com o JIT, é possível que um construtor com setter e o outro sem tenham o mesmo tempo de execução.
os métodos GET e SET são padrões em java. Se vc não acredita construa uma aplicação usando JSF e Hibernate com classes sem GEt e SET.
Será q funciona ???
Se vc tem uma classe e ela extende outra que tem um atributo private String name e tem um public void setName(String)
e se vc sobreescrever este metodo e não tomar os devidos cuidados vc pode nunca mais conseguir acessar a variavel name. Pois ela é privada.
Usar set e get ajuda por exemplo a não ter uma classe cachorro com um tamanho 0.
ou ainda vc definiu que o cachorro não pode ser menor que 5 e nem maior que 10.
Usa set e get mas no construtor ele recebe o tamanho e gaurda o mesmo direto.
E depois de 1 ano vc descobriu que existe um cachorro com tamanho 3. vc vai precisar dar manutenção em seu código são 2 lugares para mexer…
Entende ?
Eu prefiro usar set e get isso ajuda muito alem de ser padrão java beans.
[quote=Zeed01]Boa tarde Colegas !
sergiotaborda:
Mas utilizar método set não seria justamente para garantir que o objeto fique com um valor válido ?
Não sei, mas como no exemplo que falei:
public void setValor(int valor) {
if (valor < 0) {
this.valor = 0;
} else {
this.valor = valor;
}
}
Se o construtor atribuir diretamente ao atributo ele irá ficar com um valor negativo, o que nesse exemplo, não seria um valor válido…
[/quote]
- se o valor que vc recebe não é válido vc deve lançar uma exceção ( IllegalArgumentException). NUNCA deve assumir um outro valor.
- a regra 1 é válida para métodos e construtores.
O seu é para garantir que fique válido, sim, mas o construtor tb. O ponto é “Quando” precisa ficar válido.
O set é chamado de Modificador. Isto porque o objeto já existe em um estado válido e ele tem que garantir que o estado será mudado para um outro estado também válido.
O construtor define qual é o estaod válido inicial. Neste momento o objeto ainda não existe, pelo que ele tem que garantir o primeiro estado válido. É esse estado que o set vai modificar.
Vc pode achar que está amarrando as coisas, mas isso é uma falácia a menos que o set seja identificado como final.
Pois caso contrario a classe filha pode simplesmente não fazer os mesmos controles e deixar o estado inválido. Por outro lado, o contrutor da classe filha pode nem chamar set o que significa que outras regras serão usadas…
Como boa prática é recomendado que não misture as coisas. Mesmo que tenha que fazer as mesmas verificações, faça-as nos dois lugares.
[quote=sergiotaborda][quote=Luciano Danilo]Boa tarde!
qual a diferença entre esses dois metodos construtores?
[/quote]
não se diz “método contrutor” isso é errado. Um método não é um construtor e vice-versa.
A frase seria “Qual a diferença entre estes dois construtores?”
(Métodos e Construtores são menbros da classe e têm uma declaração muito semelhante, mas não são
a mesma coisa. Construtores não são métodos.)
[quote]
String nome;
public Exemplo(String nome){
setNome(nome);
}
public Exemplo(String nome){
this.nome = nome;
}
qual usar?[/quote]
O segundo.
O primeiro invoca um método , o segundo faz uma atribuição a um atributo da classe.
Invocar o método não garante que a atribuição será feita e portanto o estado do objeto pode ficar
“capenga”. Nesse caso o construtor criou um objeto com estado inválido o que vai contra as regras de um construtor.
Por isso se deve usar a segunda opção já que não tem como o estado ser inválido dessa forma.[/quote]
Boa Tarde Sergio
Obrigado pelo detalhe, porem algumas bibliografias apontam construtor, como um tipo de método, porém acho uma expressao meio forte afirmar que esta errada. Mais é claro muito importante sua colocação para poder buscar o certo.
Porém concordo com sua colocação a respeito do segundo construtor estar correto, porem o primeiro da impressao de que invoca um metodo foge do conceito de passar parametros de instancia de um objeto no ato de sua construção. Só que essa duvida surgiu devido essas diferenças de conceitos em livros, alguns exemplos encontrei da primeira forma e outros da segunda. Agora como opiniao usando this me permite nao criar um metodo set, opa ganho algumas linhas no codigo :lol:, se isso ta certo nao sei mais as duas formas funcionam iguais.
Existem várias coisas que evidenciam que construtores não são métodos. Dizer que eles são diferentes não é uma questão de gosto
ou de opinião. É uma questão de fato que pode ser comprovada facilmente pelas ditas evidencias.
Para começo de conversa construtores não têm retorno, métodos sempre têm retorno ( mesmo que void).
Construtores nunca são herdados, métodos sempre são herdados ( até explicitação em contrário com final).
Construtores são invocados quando o objeto ainda não existe. Métodos são invocados apenas em objetos que existem.
Via reflection vc vai encontrar no objeto Class métodos para obter todos os métodos de uma classe e outros para obter todos os construtores. São todos membros da classe, mas não são do mesmo “tipo”.
Tlv as diferenças sejam subtis, mas elas estão lá marcando as diferenças. Eu desconsideraria qualquer livro que apontasse construotres sendo métodos sem uma justificativa bem dada para : “se são a mesma coisa, porquê têm regras diferentes?”
Como regra geral é uma má prática vc usar as capacidades de OO apenas para escrever menos código sem levar em consideração as implecações tecnicas e teoricas das suas ações. Ambos os construtores , com set ou sem set, funcionam. Mas um está em acordo com boas práticas e evita problemas, o outro não. Isso é um problema comum tb em relação a herança.
Veja assim, se vc usa principios de OO e isso lhe pouca escrever codigo, otimo. Mas se vc subverte as capacidades do Java para escrever menos código isso é perguiça e não bom OO.
não tenha medo de escrever this muitas vezes. é para isso que ele serve.
[quote=sergiotaborda][quote=Luciano Danilo]
Boa Tarde Sergio
Obrigado pelo detalhe, porem algumas bibliografias apontam construtor, como um tipo de método, porém acho uma expressao meio forte afirmar que esta errada. Mais é claro muito importante sua colocação para poder buscar o certo.
[/quote]
Existem várias coisas que evidenciam que construtores não são métodos. Dizer que eles são diferentes não é uma questão de gosto
ou de opinião. É uma questão de fato que pode ser comprovada facilmente pelas ditas evidencias.
Para começo de conversa construtores não têm retorno, métodos sempre têm retorno ( mesmo que void).
Construtores nunca são herdados, métodos sempre são herdados ( até explicitação em contrário com final).
Construtores são invocados quando o objeto ainda não existe. Métodos são invocados apenas em objetos que existem.
Via reflection vc vai encontrar no objeto Class métodos para obter todos os métodos de uma classe e outros para obter todos os construtores. São todos membros da classe, mas não são do mesmo “tipo”.
Tlv as diferenças sejam subtis, mas elas estão lá marcando as diferenças. Eu desconsideraria qualquer livro que apontasse construotres sendo métodos sem uma justificativa bem dada para : “se são a mesma coisa, porquê têm regras diferentes?”
Como regra geral é uma má prática vc usar as capacidades de OO apenas para escrever menos código sem levar em consideração as implecações tecnicas e teoricas das suas ações. Ambos os construtores , com set ou sem set, funcionam. Mas um está em acordo com boas práticas e evita problemas, o outro não. Isso é um problema comum tb em relação a herança.
Veja assim, se vc usa principios de OO e isso lhe pouca escrever codigo, otimo. Mas se vc subverte as capacidades do Java para escrever menos código isso é perguiça e não bom OO.
não tenha medo de escrever this muitas vezes. é para isso que ele serve.
[/quote]
Grato por sua colocação Sérgio, olha só quanta coisa deu pra extrair em sua citação…
Grande abraço