Boas técnicas de programação - Construtor com muitos parâmetros

6 ou 7 parametros é muito mais legivel.

Caso os valores não devam ser alterados, vc so deve fazer gets, criar setters e getters a torto e a direita não é uma boa pratica.

Evite usar por exemplo um vetor quando os atributos não são dinamicos.

Obrigado pela opinião, Rafael.

Cara na minha opinião menos é mais e mais é exagero.

Dependendo da situação a utilização de muitos parâmetros para o contrutor se torna confuso e de manutenção cansativa. Se você instanciar um novo objetos em outras classes, quando for adicionar um atributo à esta classe do construtor, você deverá alterar todas as outras classes para que se adapte ao novo construtor.

Eu costumo usar construtor com parâmetro, com no máximo 4 parâmetros, do contrário utilizo sem parâmetro mesmo

O tópico é sugestivo, quero ver a opinião das outras pessoas, talvez o meu modo de pensar esteja errado.

de uma pesquisadinha sobre fluent interface, vai ajudar

abrassss

GenteFinaBR:

Boa tarde pessoal,

Gostaria de uma opinião de vocês. Tenho três opções aqui, poderia instanciar um objeto com um construtor muito grande, 6-7 parametros ou definir sets para os parametros após o objeto ser declarado e instanciado. Também poderia passar um vetor no construtor com os parametros.

Qual das soluções vcs acham mais elegante?

Abraços

Bem, essa pergunta me lembra o segundo capítulo do Java Effetive. Nele Joshua Block diz o seguinte: Considere o uso de métodos de fabricação estáticos em vez de contrutores.

Pelos seguintes motivos:

• Você pode dar nomes aos métodos de contrutação estáticos, já que, no seu caso, um contrutor de 5 parametros pode ter um contexto diferente de um de 6 parametros.
• Diferentemente dos contrutores, você não tem que criar um novo objeto caso os parametros que você passou sejam igual a um já criado.
• Você pode retornor qualquer objeto de um subtipo do tipo de retorno.
• Mais uma ou duas que eu não me lembro.

[]'s
JL

Olá, minha opinião.
6 ou 7 parâmetros acho necessário, se vc tiver que ter vários construtores, como fará para diferencia-los? mas se o caso é apenas um ou dois contrutores com muitos parâmetros, como diferenciar os de 6 e 7? fará com 2 e 3 parâmetros?(rs) vai ficar feio pacas…
você tem certeza que não precisará criar novos no futuro, caso precise de mais ou menos parâmetros?
eu opto por manter todos os parâmetros nocontrutor.

como disse o amigo Felagund, criar apenas gets e sets necessários para não poluir.

essa de estaticos eu n entendi muito, claro que um de 5 , será diferente de um contrutor de 6.

Obrigado a todos pelas respostas.
Acredito que numa boa implementação devemos evitar construtores ou métodos com tantos parâmetros.
Portanto a solução seria dividir o problemas em classes, ou métodos, se for possível dentro do tempo que temos.

Como o pessoal comentou, fazendo desta forma pode-se deixar o software um pouco restrito, dependendo do caso, mais um ponto negativo a se considerar.

Vou estudar melhor o problema e tentar resolve-lo, caso não consiga ficarei com todos os parâmetros mesmo, fazer oq.

Abraços e até a próxima.

Bateu na trave
O item do Effective Java que vem logo depois desse é: “Consider a builder when faced with many constructor parameters”, ou considere usar o padrão Builder quando seu construtor tiver muitos parâmetros. Tem tudo a ver com o assunto do tópico.

Escrevi este post há alguns dias atrás, ilustra o uso do padrão builder para esses casos:

http://www.guj.com.br/posts/list/130609.java#703698

EDIT - as classes StringBuffer e StringBuilder são exemplos do padrão builder na própria API Java.

Algumas sugestões:

1. Se forem parâmetros cujos valores forem recorrentes, crie mais de um construtor, o completo e outros com valores padrão.
Exemplo:

public void Usuario {
    public Usuario(String nome, String departamento, String algoritmoDeCriptografiaDaSenha, Calendar dataDeAdmissao, String ... filhos) {
         this.nome = nome;
         this.departamento = departamento;
         this.algoritmo = algoritmoDeCriptografiaDaSenha;
         this.dataDeAdmissao = dataDeAdmissao;
         this.filhos = Arrays.copyOf(filhos);
    }

    //Caso mais comum, usuário sem filhos, admitido no dia, usando DES para criptografar a senha.
    public Usuario(String nome, String departamento) {
         this(nome, departamento, "DES", Calendar.getInstance(), new String[]);
    }
}

2. Se forem parâmetros que são recorrentes, mas dentro de um contexto de uma única aplicação (e vão mudar entre aplicações), considere a possibilidade de criar um objeto fábrica. Defina esses parâmetros na fábrica e crie um método de construção mais simples lá, que já use os parâmetros setados (é uma boa tb se os parâmetros do construtor vierem de diferentes lugares. Você poderia criar uma fábrica para ler os parâmetros de um XML, banco de dados, ou recebe-los na aplicação, e escolher que fábrica usar de acordo com o caso). Exemplo:

Considere que sua classe de vários parâmetros seja a de criar uma conexão no banco. Você poderia fazer uma fábrica para ela:

/** Cria uma conexão no BD
      Conexões numa mesma aplicação são sempre iguais, mas mudam radicalmente entre aplicações */
public class ConectionFactory {
    public String dbName;
    public String driverName;
    public String dbUser;
    public byte[] dbPassword;
    
    public Conexao create() {
        return new Conexao(dbName, driverName, dbUser, dbPassword);
    }
}

E então essa fabrica retornaria sempre conexões do mesmo tipo.

3. Uma boa forma de evitar erros no código, é deixar os parâmetros obrigatórios no construtor, e usar setters para os opcionais. Você ainda pode simplificar a construção usando invocation channing (o setter retornar o próprio objeto). Essa é uma estratégia comum na implementação de fluent interfaces. Exemplo:

Usuario vinicius = new Usuario("Vinicius", "vgm", "vgm124")
   .setIdade(28)
   .setEstadoCivil(EstadoCivil.Solteiro)
   .setPeso(80.0)
   .setAltura(1.78);

Note que eu poderia desprezar todos os sets, mas não poderia desprezar o nome de usuário, nome completo e senha.