Eu geralmente tenho lido que ter muitos (4) argumentos para uma função / construtor é uma prática ruim. Isso ainda é considerado uma prática ruim? [fechadas]

5

Geralmente tenho lido que ter muitos argumentos (> 4) para uma função / construtor é uma prática ruim.

  1. Isso ainda é considerado uma prática ruim? E existe uma razão não óbvia?
  2. Em algo como uma Classe de Caso Scala, onde pode haver muitos campos, o que pode ser feito para evitar tal construção?

(Não tenho certeza se isso é mais adequado para aqui, SO ou CodeReview)

    
por ford prefect 06.08.2014 / 21:06
fonte

5 respostas

5

Eu tenho vários testes de 'cheiro' para 'melhor prática'. Alguns vêm através de implementações ruins ou ferramentas fracas. Alguns ajudam nossas mentes imperfeitas a criar coisas de alta qualidade. Alguns são identificados por correlações entre código e bugs (embora a causalidade nunca possa ser demonstrada). Então, eu gosto de entender o que uma regra está contribuindo.

Está bem claro que muitos parâmetros podem se tornar um desafio de usabilidade.

No entanto, vamos testar alguns critérios mais rígidos.

Muitos sistemas fazem transações CRUD em bancos de dados relacionais.

Assim, um teste é "esta regra de melhor prática 'afetaria as transações CRUD dos meus códigos de maneira positiva ou negativa?"

Afinal, embora você possa não gostar do meu benchmark, os bancos de dados relacionais têm a intenção de representar partes do mundo real em formas transacionais robustas do ACID.

Criar relacionamentos incompletos, que não representam o estado do mundo real, geralmente é "uma coisa ruim". Cria uma complexidade extra para suportá-lo, sem pagamento aparente.

Esta não é uma licença para ignorar os "tipos corretos". Se partes da lista de parâmetros do construtor ou da função contiverem os valores de tipos significativos reais, representando algo relevante no domínio, que tenha comportamento no aplicativo, esses devem ser construídos ou passados.

AFAIK, todas as linguagens funcionais explicitamente fornecem mecanismos para representar e construir 'relacionamentos apropriados', e isso é 'uma coisa boa'.

Então, aceito que há alguns problemas de usabilidade simples e razoáveis, que não devem ser ignorados.

No entanto, no caso de uma linguagem funcional '> 4' não parece útil. A imutabilidade é um "martelo" muito maior para resolver problemas. Para mim, representar corretamente o estado da realidade, supera '4' todas as vezes.

    
por 06.08.2014 / 22:20
fonte
4
  1. Sim. O número de permutações possíveis para os argumentos n escala rapidamente . É fácil esquecer a ordem dos argumentos para uma função de arity 5. Além disso, há uma boa chance de alguns desses argumentos. são sempre usados juntos. Envolvê-los facilita a sua passagem (e é necessário devolvê-los de funções).

  2. Não muito familiarizado com o Scala, mas aulas anônimas ajudariam, já que a ordem dos campos não é importante.

por 06.08.2014 / 21:25
fonte
1

As classes de casos Scala são muito parecidas com tuplas imutáveis (além de outras coisas irrelevantes para essa questão). Eu não acho estranha uma tupla com mais de 4 elementos, embora certamente haja um limite onde ela se torne ilegível.

Além disso, como uma classe de caso como Person(name: String, age: Int) é imutável, alguns dos padrões de Java para criar objetos complexos, como o padrão Builder, tornam-se difíceis de aplicar. Veja Qual é o Scala equivalente a um padrão de construtor Java? e Padrão de construtor seguro de tipos no Scala .

    
por 06.08.2014 / 21:55
fonte
0

Eu nunca ouvi isso.

O que você espera fazer se precisar passar um nome de usuário e uma permissão de segurança específica? Você deve criar uma nova classe que possa conter ambos, preenchê-lo e enviá-lo para manter "menos é melhor" em relação aos parâmetros? Não consigo imaginar que isso seja verdade.

Até mesmo as bibliotecas obcecadas com desempenho (jQuery, php, .NET) possuem vários argumentos em suas funções.

Acho que minha resposta fez mais sentido antes que o OP editasse sua pergunta para abranger apenas os parâmetros de > 4. Minha resposta é se houver apenas dois parâmetros ou mais.

Se houver parâmetros > 4 ... sim, você deve reavaliar o que está fazendo e considerar se todos os parâmetros são realmente necessários ou se um objeto mais abrangente pode ser passado.

    
por 06.08.2014 / 21:21
fonte
0

A questão é dupla.

Em caso de funções / métodos:

  • Ter que passar muitos parâmetros é uma indicação de um design não coeso.
  • O método não usa o estado da aula.
  • Se for um método estático em uma classe de utilitário estático, tudo bem. Caso contrário, é possível indicar que o método não pertence a essa classe.
  • Mesmo no caso de um método estático, você pode evitar muitos parâmetros criando um "objeto de parâmetro" que é uma classe com todos os valores necessários para passar para o método.

No caso do construtor:

  • Você pode usar o objeto de parâmetro " que mencionei acima
  • Ou você pode preencher o objeto com métodos de definição . Nesse caso, você deve fornecer "padrões inteligentes" para que o objeto tenha um estado padrão para começar, ou lançar uma exceção de estado inválido se chamar um método que requeira o objeto ser totalmente inicializado.
por 06.08.2014 / 21:36
fonte