A coisa mais importante a lembrar é que essas são diretrizes, não regras.
Há casos em que um método simplesmente deve receber um argumento. Pense no +
método para números, por exemplo. Ou o add
método para uma coleção.
De fato, pode-se argumentar que o que significa adicionar dois números depende do contexto, por exemplo, em ℤ 3 + 3 == 6
, mas em ℤ | 5 3 + 3 == 2
, portanto, o operador de adição deve ser um método em um objeto de contexto que usa dois argumentos em vez de um método em números que leva um argumento.
Da mesma forma, um método para comparar dois objetos deve ser o método de um objeto usando o outro como argumento, ou um método do contexto, usando dois objetos como argumento, portanto, não faz sentido ter um método de comparação com menos de um argumento.
Dito isto, há algumas coisas que podem ser feitas para reduzir o número de argumentos para um método:
- Torne o método menor : Talvez, se o método precisar de tantos argumentos, esteja fazendo muito?
- Uma abstração ausente : se os argumentos estão intimamente correlacionados, talvez eles pertençam um ao outro e há uma abstração que está faltando? (Exemplo de livro de texto canônico: em vez de duas coordenadas, passe um
Point
objeto ou, em vez de passar nome de usuário e email, passe um IdCard
objeto.)
- Estado do objeto : se o argumento for necessário por vários métodos, talvez ele deva fazer parte do estado do objeto. Se for necessário apenas para alguns dos métodos, mas não para outros, talvez o objeto esteja fazendo muito e realmente deva ser dois objetos.
Uma maneira é extrair os argumentos para uma nova classe, mas isso certamente levaria a uma explosão de classes?
Se o seu modelo de domínio tiver muitos tipos diferentes de coisas, seu código terminará com muitos tipos diferentes de objetos. Não há nada de errado nisso.
E é provável que essas classes acabem com nomes que violam algumas das regras de nomenclatura (terminando com "Dados" ou "Informações" etc.)?
Se você não conseguir encontrar um nome adequado, talvez agrupe muitos argumentos ou poucos. Portanto, você possui apenas um fragmento de uma classe ou possui mais de uma classe.
Outra técnica é transformar as variáveis usadas por várias funções em uma variável membro privada para evitar que elas sejam transmitidas, mas isso expande o escopo da variável, possivelmente de forma que seja aberta a funções que na verdade não precisam.
Se você possui um grupo de métodos que funcionam com os mesmos argumentos e outro grupo que não, talvez eles pertençam a classes diferentes.
Observe com que frequência eu usei a palavra "talvez"? É por isso que essas são diretrizes, não regras. Talvez o seu método com 4 parâmetros esteja perfeitamente correto!