language agnostic - Cuando un método tiene demasiados parámetros?

language-agnostic ide

Question

Al depurar algún código de cliente de servicio web hoy (en Java, con jax-ws) me encontré con un método de servicio web con la asombrosa cantidad de 97 parámetros.

Tuve que crear un caso de prueba que llama a este método, y noté varias cosas:

• code assist / hover no escala bien. Estoy usando Eclipse, y la información sobre herramientas sobre el método es tan amplia como la pantalla y abarca varias líneas.
• Tuve que copiar los valores de los parámetros de una captura xml anterior, y era prácticamente imposible recordar "¿dónde estoy?" - cuando tenía el cursor ubicado después de una coma y antes de escribir algún valor, a menudo obtenía el tipo de datos incorrecto - escribí un entero en lugar de una cadena y viceversa.
• Incluso después de escribir todos los parámetros, todavía tenía algunos errores y la firma no coincidía. Desafortunadamente, Eclipse marca toda la línea en rojo como si tuviera un error, por lo que encontrar dónde se cometió el error llevó aún más tiempo :(

Así que esto me hizo pensar, ¿cuál crees que es el número máximo de parámetros para un método? Y si pudiera cambiar esta firma de servicio web, ¿cómo cree que se puede mejorar?

Answer 1

¡Gran Buda! ¿¿¿¿Noventa y siete????

La buena práctica generalmente aconseja sobre max. seis a ocho. Por supuesto, mmm, y puede haber una razón válida, de vez en cuando, para un noveno. Pero 97 ?? !!

Algunos pensamientos ... ¿son simplemente datos, o se toman decisiones basadas en sus valores?

Si muchos / la mayoría afecta el control de flujo, tiene un "diseño" casi inmanejable (incluso comprensible o comprobable) (para pequeños valores de "diseño").

Si son simplemente datos, ¿pueden agruparse en estructuras y punteros de esas estructuras?

¿Tienes alguna documentación de diseño? Puede que eso explique lo que está pasando.

Ah, y "Danger, Will Robinson": cualquiera que pase 97 parámetros abiertamente también podría pasar cualquier número, no tan obviamente, como variables globales.

Ps no sé cómo funciona Eclipse en Java, pero con C / C ++, si pones los paramaeters en líneas separadas

char DoEverything(
int meaninglessParameterName1,
char *meaninglessParameterName2,
....
long double *meaninglessParameterName97)
{ return !NULL;}

Eclipse identificará realmente la línea con el parámetro incorrecto

Answer 2

Bueno, si lo convierte en un objeto JSON, puede envolver todos los 97 (o más) en ese objeto y solo enviar un objeto.

Answer 3

Bueno, sugiero sobrecargar el método para que tenga implementaciones más simples del método. Esto puede ser especialmente útil si muchos de los parámetros rara vez cambian y se pueden asignar valores predeterminados. Sin embargo, si la memoria funciona, no creo que pueda sobrecargar una llamada al servicio web (debe usar un nombre de método distinto).

Otra posible solución es encapsular los parámetros en algún tipo de clase de metadatos cuyo propósito sea mantener los parámetros. Esto simplificaría la firma del método. Sin embargo, en algunos aspectos solo está descargando el problema a la clase de parámetros. Pero, si los parámetros se pueden catalogar en temas, esta técnica se puede emplear utilizando varias clases de metadatos, cada una de las cuales se incluiría como un parámetro para el servicio web. Esto debería simplificar las cosas y ayudarlo a entender este monstruo.

Finalmente, es difícil decirlo sin ningún detalle, pero ciertamente parece que este código es un candidato serio para la refactorización. No tengo una regla dura y rápida sobre el número de parámetros para un método que no sea el de abrazar el principio general de simplicidad y legibilidad.

Answer 4

Como Steve McConnell menciona en Code Complete , la regla de oro es 4 +/- 3 parámetros. Para el ser humano medio es difícil recordar más de 4 parámetros, 5-7 debe usarse solo en casos especiales y nunca debe usar 8 o más.

Answer 5

Cuando tienes que preguntar, probablemente sean demasiados.

Answer 6

En cuanto a los servicios web, prefiero manejar los parámetros como un solo objeto. Si bien su contrato de datos puede cambiar, su contrato de servicios no lo hará. Esto hace que sus servicios sean más a prueba de futuro.

Para todo lo demás, estoy a favor de 3 parámetros y ocasionalmente puedo llegar a 5.

Answer 7

En mi propia experiencia, he encontrado que las firmas de métodos comienzan a ser confusas y difíciles de recordar con más de 5 o 6 parámetros. Y una vez que pasas los 10 parámetros es simplemente ridículo.

Estos parámetros realmente necesitan combinarse en un objeto (o un pequeño conjunto de objetos) que contengan todos los datos. En los servicios que uso, cada operación de servicio siempre toma un solo objeto de solicitud y devuelve un solo objeto de respuesta.

Answer 8

No hay un límite claro, pero no me siento cómodo con más de 3-4 parámetros. AFAIR El tío Bob Martin en Clean Code recomienda un máximo de 3.

Hay varias refactorizaciones para reducir el número de parámetros del método (consulte Trabajar eficazmente con el código heredado , por Michael Feathers para obtener más información). Estos vienen a mi mente:

• encapsular muchos parámetros relacionados en un solo objeto (por ejemplo, en lugar de String surName, String firstName, String streetAddress, String phoneNumber pasar un objeto Person que contenga estos como campos)
• pasar parámetros en el constructor u otras llamadas al método antes de la invocación de este método

Answer 9

Si tiene más de 5-10 parámetros, cree un objeto que tome los parámetros en su lugar, podría ser un conjunto de datos tipeados, una estructura o lo que sea.

En lugar de :

Mywebservice.CreateUser(Firstname, LastName, Age,Sex, Haircolor,AmountOfFingers,AmountOfTeeht,Childrens,,,,,,,,,,,,,and so on)

Hacer:

Dim MyUser as new UserObject
MyUser.Firstname="Stefan"
...and so on...
MyWebservice.CreateUser(UserObject)