O q eles estão querendo dizer é q num tem nada a ver usar construtores parciais…
Cara, a questão é vc assegurar a consistência de estado da sua classe no momento da criação do objeto da mesma. Ou por todo tempo de vida(se ela não tiver accessors que possam comprometer seu estado). Mas ai vai da implementação e do padrão que vc está seguindo.
Se vc possui uma classe Cliente e quer assegurar a consistência dela na sua criação vc utilizaria:
public class Cliente {
private Integer id;
private String nome;
public Cliente(Integer id, String nome) {
this.id = id;
this.nome = nome;
}
//Setters e getters
}Nessa situação só é possível criar um objeto da classe Cliente passando o id e o nome. Aí estamos assegurando a consistência do estado do objeto apenas na criação.
Deixando os setters em sua forma padrão facilmente o estado do objeto poderia ser comprometido, por exemplo:
cliente.setNome(null);
cliente.setId(null);Porém isso pode ser verificado através de um tratamento no setter da classe:
public void setId(Integer id) {
if (id == null) {
throw new IdClienteInvalidoException();
}
this.id = id;
}Eu poderia ter um construtor sem argumentos(default), isso permitiria criar um objeto sem estado inicial. Ou um construtor parcial. A questão é que meu código deve assegurar a consistência do estado do objeto. Pode-se fazer isso de N maneiras.
Sim. Então é possivel afirma q um costrutor parcial não é uma pratica ruim, é uma opção que depende do model em questão.
Essa aqui que o Sergio deu, e que o Foxtol foi alem, é sem duvida a regra “maxima”.
Nao entendi essa Sergio. Se da na mesma, porque escrever? So pra ter legibilidade de que voce quer mesmo um construtor como o default?
[quote=Paulo Silveira]
Nao entendi essa Sergio. Se da na mesma, porque escrever? So pra ter legibilidade de que voce quer mesmo um construtor como o default?[/quote]
Exato. Quando a classe não tem construtor, ela não tem porque não precisa ou ela não tem porque o programador errou em não colocar ? Se o construtor não está lá quem garante que o estado é consistente ? Posso asumir que o estado default é consistente ?
A propria declaração do construtor vazio singifica : “Esta classe sabe manter seu estado coerente na inicilizalização e esse estado é igual ao estado padrão de todos os seus atributos”.
A falta da declaração não significa “estou usando o construtor implicito” significa “não sei qual construtor usar”.
Uma boa prática em qualquer area : implicito == ruim. explicito == bom
Ate concordo com esse caso Sergio, e eu gosto ate de escrever this mesmo quando implicito (talvez isso seja vicio depois de tanto tempo que dei aula);mas voce tem de tomar cuidad, senao vai comecar a escrever extends Object em tudo que é classe “sem mae” e public abstract do lado de metodos de interfaces 
[quote=Paulo Silveira]
Ate concordo com esse caso Sergio, e eu gosto ate de escrever this mesmo quando implicito (talvez isso seja vicio depois de tanto tempo que dei aula);mas voce tem de tomar cuidad, senao vai comecar a escrever extends Object em tudo que é classe “sem mae” e public abstract do lado de metodos de interfaces :)[/quote]
São coisa completamente diferentes. Escrever this está evitando um problema de shadowing. Colocar “extends Object” não está evitando problema algum. Não tem como o programador criar uma classe que não extende Object, mas tem como esquecer de colocar um construtor numa classe e isso destruir a integridade de estado.
Extends Object = burocracia do java
Constutor sem parametros = regra de integridade de estado.
É bem diferente. Vc só pode usar implicitos quando eles são burocráticos. O resto, vc tem que usar explicitos.
Quando mais novato vc for na linguagem mais explicitos deve usar. (Lembra do Implicit None ?)
Pela mãozinha gorda, acho que é o Moisés. E pelo apelido (nick) de mau gosto, acho que é o Diego.
Mas vamos lá!
O pessoal aqui já disse muito a respeito dos construtores e os seus argumentos e explicaram bem.
Como disseram, pode não ser por “boas práticas”, mas sim por conta do modelo de desenvolvimento adotado para o projeto. O que concordo.
Como eu sei que estamos falando do mesmo projeto, neste caso, não vejo como adequado criar N variantes do construtor da classe de uma entidade, o que pode levar ao uso equivocado dessas diferentes variantes.
Em alguns casos, algumas IDEs podem não interpretar corretamente os nomes dos parâmetros, possibilitando erros na implementação.
Exemplo:
[code]public class Pessoa {
String nome;
String cpf;
String email;
public Pessoa() {}
public Pessoa( String nome, String cpf, String email ) {}
public Pessoa( String nome, String cpf ) {}
public Pessoa( String nome, String email ) {} // NÃO COMPILA!!!
}[/code]
Além do mais, no auto complete de alguma IDEs, você não consegue saber se os nomes dos argumentos dos construtores. Eles acabam colocando algo como “param1, param2”.
Está vendo a possibilidade de problemas que se abrem?
Neste caso, se precisar passar apenas alguns argumentos na criação do objeto, por exemplo, nome e cpf, faça assim:
Pessoa p = new Pessoa( nome, cpf, null );Fica explícito e é menos suscetível a erros, na minha opinião.
Abraços a todos de Mococa!
Daniel Destro
Ou com aquele esqueminha de “programação fluente” que o pessoal costuma usar:
Pessoa p = new Pessoa().setNome("João").setCpf("123.456.789/00");Isso é mais uma das coisas herdadas do C++. Como seria mais fácil se pudéssemos usar algo como
Pessoa p = new Pessoa (nome = "João", cpf = "123.456.789/00");