¿Existen pautas sobre cuántos parámetros debe aceptar una función?

He notado que algunas funciones con las que trabajo tienen 6 o más parámetros, mientras que en la mayoría de las bibliotecas que uso es raro encontrar una función que requiera más de 3.

A menudo, muchos de estos parámetros adicionales son opciones binarias para alterar el comportamiento de la función. Creo que algunas de estas innumerables funciones parametrizadas probablemente deberían ser refactorizadas. ¿Hay una guía para qué número es demasiado?

Nunca he visto una directriz, pero en mi experiencia una función que toma más de tres o cuatro parámetros indica uno de dos problemas:

1. La función está haciendo demasiado. Debe dividirse en varias funciones más pequeñas, cada una de las cuales tiene un conjunto de parámetros más pequeño.
2. Hay otro objeto escondido allí. Es posible que deba crear otro objeto o estructura de datos que incluya estos parámetros. Consulte este artículo sobre el patrón de objeto de parámetro para obtener más información.

Es difícil saber lo que estás viendo sin más información. Lo más probable es que la refactorización que necesita hacer es dividir la función en funciones más pequeñas que se invocan desde el elemento primario dependiendo de los indicadores que actualmente se pasan a la función.

Al hacer esto, hay algunas buenas ganancias:

• Hace que su código sea más fácil de leer. Personalmente, me resulta mucho más fácil leer una "lista de reglas" compuesta de una ifestructura que llama a muchos métodos con nombres descriptivos que una estructura que lo hace todo en un solo método.
• Es más comprobable por unidad. Ha dividido su problema en varias tareas más pequeñas que son individualmente muy simples. La colección de pruebas unitarias se compondría de un conjunto de pruebas de comportamiento que verifica las rutas a través del método maestro y una colección de pruebas más pequeñas para cada procedimiento individual.

Según el "Código limpio: un manual de artesanía ágil de software", cero es el ideal, uno o dos son aceptables, tres en casos especiales y cuatro o más, ¡nunca!

Las palabras del autor:

El número ideal de argumentos para una función es cero (niládico). Luego viene uno (monádico), seguido de cerca por dos (diádico). Se deben evitar tres argumentos (triádicos) siempre que sea posible. Más de tres (poliádico) requieren una justificación muy especial, y de todos modos no deberían usarse.

En este libro hay un capítulo que habla solo de las funciones en las que se discuten los parámetros, por lo que creo que este libro puede ser una buena guía de cuántos parámetros necesita.

En mi opinión personal, un parámetro es mejor que nadie porque creo que está más claro lo que está sucediendo.

Como ejemplo, en mi opinión, la segunda opción es mejor porque es más claro lo que el método está procesando:

LangDetector detector = new LangDetector(someText);
//lots of lines
String language = detector.detectLanguage();

vs.

LangDetector detector = new LangDetector();
//lots of lines
String language = detector.detectLanguage(someText);

Acerca de muchos parámetros, esto puede ser una señal de que algunas variables se pueden agrupar en un solo objeto o, en este caso, muchos valores booleanos pueden representar que la función / método está haciendo más de una cosa, y en este caso, Es mejor refactorizar cada uno de estos comportamientos en una función diferente.

Si las clases de dominio en la aplicación están diseñadas correctamente, la cantidad de parámetros que pasamos a una función se reducirá automáticamente, porque las clases saben cómo hacer su trabajo y tienen suficientes datos para hacer su trabajo.

Por ejemplo, supongamos que tiene una clase de gerente que le pide a una clase de tercer grado que complete las tareas.

Si modelas correctamente,

3rdGradeClass.finishHomework(int lessonId) {
    result = students.assignHomework(lessonId, dueDate);
    teacher.verifyHomeWork(result);
}

Esto es simple.

Si no tiene el modelo correcto, el método será así

Manager.finishHomework(grade, students, lessonId, teacher, ...) {
    // This is not good.
}

El modelo correcto siempre reduce los parámetros de función entre las llamadas a métodos, ya que las funciones correctas se delegan a sus propias clases (responsabilidad única) y tienen suficientes datos para realizar su trabajo.

Cada vez que veo que aumenta el número de parámetros, verifico mi modelo para ver si diseñé mi modelo de aplicación correctamente.

Sin embargo, hay algunas excepciones: cuando necesito crear un objeto de transferencia u objetos de configuración, usaré un patrón de construcción para producir objetos construidos pequeños primero antes de construir un objeto de configuración grande.

Un aspecto que las otras respuestas no abordan es el rendimiento.

Si está programando en un lenguaje de nivel suficientemente bajo (C, C ++, ensamblaje), una gran cantidad de parámetros puede ser bastante perjudicial para el rendimiento en algunas arquitecturas, especialmente si la función se llama una gran cantidad de veces.

Cuando una llamada de función se realiza en ARM por ejemplo, los primeros cuatro argumentos se colocan en registros r0a r3y argumentos restantes tienen que ser empujado en la pila. Mantener el número de argumentos por debajo de cinco puede marcar una gran diferencia para las funciones críticas.

Para las funciones que se llaman muy a menudo, incluso el hecho de que el programa tiene que establecer los argumentos antes de cada llamada puede afectar al rendimiento ( r0a r3pueden ser sobrescritos por la función llamada y tendrá que ser reemplazado antes de la siguiente llamada) por lo que en ese sentido cero argumentos son los mejores.

Actualizar:

KjMag trae a colación el interesante tema de la alineación. La alineación mitigará esto de alguna manera, ya que permitirá que el compilador realice las mismas optimizaciones que usted podría hacer si escribiera en ensamblado puro. En otras palabras, el compilador puede ver qué parámetros y variables utiliza la función llamada y puede optimizar el uso del registro para minimizar la lectura / escritura de la pila.

Sin embargo, hay algunos problemas con la alineación.

1. La alineación hace que el binario compilado crezca ya que el mismo código se duplica en forma binaria si se llama desde múltiples lugares. Esto es perjudicial cuando se trata del uso de I-cache.
2. Los compiladores generalmente solo permiten alinearse hasta cierto nivel (¿3 pasos IIRC?). Imagine llamar a una función en línea desde una función en línea desde una función en línea. El crecimiento binario explotaría si inlinefuera tratado como obligatorio en todos los casos.
3. Hay muchos compiladores que ignorarán por completo inlineo realmente le darán errores cuando lo encuentren.

Cuando la lista de parámetros crezca a más de cinco, considere definir una estructura u objeto de "contexto".

Esto es básicamente una estructura que contiene todos los parámetros opcionales con algunos valores predeterminados razonables establecidos.

En el mundo procesal C, una estructura simple sería suficiente. En Java, C ++ un objeto simple será suficiente. No te metas con getters o setters porque el único propósito del objeto es mantener valores "públicos" configurables.

No, no hay una directriz estándar.

Pero hay algunas técnicas que pueden hacer que una función con muchos parámetros sea más soportable.

Puede usar un parámetro list-if-args (args *) o un parámetro dictionary-of-args (kwargs **)

Por ejemplo, en python:

// Example definition
def example_function(normalParam, args*, kwargs**):
  for i in args:
    print 'args' + i + ': ' + args[i] 
  for key in kwargs:
    print 'keyword: %s: %s' % (key, kwargs[key])
  somevar = kwargs.get('somevar','found')
  missingvar = kwargs.get('somevar','missing')
  print somevar
  print missingvar

// Example usage

    example_function('normal parameter', 'args1', args2, 
                      somevar='value', missingvar='novalue')

Salidas:

args1
args2
somevar:value
someothervar:novalue
value
missing

O podría usar la sintaxis de definición literal de objeto

Por ejemplo, aquí hay una llamada jQuery de JavaScript para lanzar una solicitud AJAX GET:

$.ajax({
  type: 'GET',
  url: 'http://someurl.com/feed',
  data: data,
  success: success(),
  error: error(),
  complete: complete(),
  dataType: 'jsonp'
});

Si echa un vistazo a la clase ajax de jQuery, hay muchas (aproximadamente 30) propiedades más que se pueden configurar; principalmente porque las comunicaciones ajax son muy complejas. Afortunadamente, la sintaxis literal del objeto facilita la vida.

C # intellisense proporciona documentación activa de parámetros, por lo que no es raro ver arreglos muy complejos de métodos sobrecargados.

Los lenguajes de tipo dinámico como python / javascript no tienen esa capacidad, por lo que es mucho más común ver argumentos de palabras clave y definiciones literales de objetos.

Prefiero definiciones literales de objeto ( incluso en C # ) para administrar métodos complejos porque puede ver explícitamente qué propiedades se establecen cuando se instancia un objeto. Tendrá que hacer un poco más de trabajo para manejar los argumentos predeterminados, pero a la larga su código será mucho más legible. Con las definiciones literales de objetos, puede romper su dependencia de la documentación para comprender lo que hace su código a primera vista.

En mi humilde opinión, los métodos sobrecargados están muy sobrevalorados.

Nota: si recuerdo correctamente, el control de acceso de solo lectura debería funcionar para los constructores literales de objetos en C #. Básicamente funcionan igual que establecer propiedades en el constructor.

Si nunca ha escrito ningún código no trivial en un lenguaje basado en javaScript de tipo dinámico (python) y / o funcional / prototipo, le recomiendo que lo pruebe. Puede ser una experiencia esclarecedora.

Puede ser aterrador primero romper su dependencia de los parámetros para el enfoque final de la inicialización de funciones / métodos, pero aprenderá a hacer mucho más con su código sin tener que agregar una complejidad innecesaria.

Actualizar:

Probablemente debería haber proporcionado ejemplos para demostrar el uso en un lenguaje de tipo estático, pero actualmente no estoy pensando en un contexto de tipo estático. Básicamente, he estado haciendo demasiado trabajo en un contexto de tipo dinámico para cambiar repentinamente.

Lo que sí sé es que la sintaxis de definición literal de objetos es completamente posible en lenguajes estáticamente tipados (al menos en C # y Java) porque los he usado antes. En lenguajes tipados estáticamente se llaman 'Inicializadores de objetos'. Aquí hay algunos enlaces para mostrar su uso en Java y C # .

Personalmente, más de 2 es donde se dispara mi código de alarma de olor. Cuando considera que las funciones son operaciones (es decir, una traducción de entrada a salida), es raro que se usen más de 2 parámetros en una operación. Los procedimientos (que son una serie de pasos para lograr un objetivo) requerirán más aportes y, a veces, son el mejor enfoque, pero en la mayoría de los idiomas en estos días no deberían ser la norma.

Pero, de nuevo, esa es la guía más que una regla. A menudo tengo funciones que toman más de dos parámetros debido a circunstancias inusuales o facilidad de uso.

Al igual que dice Evan Plaice, soy un gran admirador de simplemente pasar matrices asociativas (o la estructura de datos comparable de su idioma) a funciones siempre que sea posible.

Por lo tanto, en lugar de (por ejemplo) esto:

<?php

createBlogPost('the title', 'the summary', 'the author', 'the date of publication, 'the keywords', 'the category', 'etc');

?>

Ir por:

<?php

// create a hash of post data
$post_data = array(
  'title'    => 'the title',
  'summary'  => 'the summary',
  'author'   => 'the author',
  'pubdate'  => 'the publication date',
  'keywords' => 'the keywords',
  'category' => 'the category',
  'etc'      => 'etc',
);

// and pass it to the appropriate function
createBlogPost($post_data);

?>

Wordpress hace muchas cosas de esta manera, y creo que funciona bien. (Aunque mi código de ejemplo anterior es imaginario, y no es en sí mismo un ejemplo de Wordpress).

Esta técnica le permite pasar una gran cantidad de datos a sus funciones fácilmente, pero le libera de tener que recordar el orden en que cada uno debe pasar.

También apreciará esta técnica cuando llegue el momento de refactorizar; en lugar de tener que cambiar potencialmente el orden de los argumentos de una función (como cuando se da cuenta de que necesita pasar Yet Another Argument), no necesita cambiar el parámetro de sus funciones lista en absoluto.

Esto no solo le evita tener que volver a escribir la definición de su función, sino que le ahorra tener que cambiar el orden de los argumentos cada vez que se invoca la función. Esa es una gran victoria.

Una respuesta anterior mencionó a un autor confiable que declaró que cuantos menos parámetros tengan sus funciones, mejor será su desempeño. La respuesta no explica por qué, pero los libros lo explican, y aquí hay dos de las razones más convincentes de por qué necesita adoptar esta filosofía y con la que personalmente estoy de acuerdo:

• Los parámetros pertenecen a un nivel de abstracción que es diferente del de la función. Esto significa que el lector de su código tendrá que pensar sobre la naturaleza y el propósito de los parámetros de sus funciones: este pensamiento es de "nivel inferior" que el del nombre y el propósito de sus funciones correspondientes.

• La segunda razón para tener la menor cantidad posible de parámetros para una función es la prueba: por ejemplo, si tiene una función con 10 parámetros, piense cuántas combinaciones de parámetros tiene para cubrir todos los casos de prueba para, por ejemplo, una unidad prueba. Menos parámetros = menos pruebas.

Para proporcionar algo más de contexto en torno al consejo para que el número ideal de argumentos de función sea cero en el "Código limpio: un manual de artesanía ágil de software" de Robert Martin, el autor dice lo siguiente como uno de sus puntos:

Los argumentos son difíciles. Toman mucho poder conceptual. Es por eso que me libré de casi todos ellos del ejemplo. Considere, por ejemplo, el StringBufferen el ejemplo. Podríamos haberlo pasado como un argumento en lugar de convertirlo en una variable de instancia, pero nuestros lectores habrían tenido que interpretarlo cada vez que lo vieran. Cuando estás leyendo la historia contada por el módulo, includeSetupPage() es más fácil de entender que includeSetupPageInto(newPageContent). El argumento está en un nivel diferente de abstracción que el nombre de la función y te obliga a conocer un detalle (en otras palabras StringBuffer) que no es particularmente importante en ese punto.

Para su includeSetupPage()ejemplo anterior, aquí hay un pequeño fragmento de su "código limpio" refactorizado al final del capítulo:

// *** NOTE: Commments are mine, not the author's ***
//
// Java example
public class SetupTeardownIncluder {
    private StringBuffer newPageContent;

    // [...] (skipped over 4 other instance variables and many very small functions)

    // this is the zero-argument function in the example,
    // which calls a method that eventually uses the StringBuffer instance variable
    private void includeSetupPage() throws Exception {
        include("SetUp", "-setup");
    }

    private void include(String pageName, String arg) throws Exception {
        WikiPage inheritedPage = findInheritedPage(pageName);
        if (inheritedPage != null) {
            String pagePathName = getPathNameForPage(inheritedPage);
            buildIncludeDirective(pagePathName, arg);
        }
    }

    private void buildIncludeDirective(String pagePathName, String arg) {
        newPageContent
            .append("\n!include ")
            .append(arg)
            .append(" .")
            .append(pagePathName)
            .append("\n");
    }
}

La "escuela de pensamiento" del autor argumenta a favor de clases pequeñas, bajo (idealmente 0) número de argumentos de función y funciones muy pequeñas. Si bien tampoco estoy totalmente de acuerdo con él, me pareció estimulante y creo que vale la pena considerar la idea de argumentos de función cero como ideal. Además, tenga en cuenta que incluso su pequeño fragmento de código anterior también tiene funciones de argumento distintas de cero, por lo que creo que depende del contexto.

(Y como otros han señalado, también argumenta que más argumentos lo hacen más difícil desde el punto de vista de la prueba. Pero aquí quería destacar principalmente el ejemplo anterior y su justificación para argumentos de función cero).

Idealmente cero. Uno o dos están bien, tres en ciertos casos.
Cuatro o más suele ser una mala práctica.

Además de los principios de responsabilidad única que otros han notado, también puede pensarlo desde las perspectivas de prueba y depuración.

Si hay un parámetro, conocer sus valores, probarlos y encontrar errores con ellos es relativamente fácil, ya que solo hay un factor. A medida que aumenta los factores, la complejidad total aumenta rápidamente. Para un ejemplo abstracto:

Considere un programa de "qué ponerse en este clima". Considere qué podría hacer con una entrada: temperatura. Como puede imaginar, los resultados de qué ponerse son bastante simples en función de ese único factor. Ahora considere lo que el programa podría / podría / debería hacer si se supera la temperatura, humedad, punto de rocío, precipitación, etc.