¿Son útiles los parámetros opcionales o un obstáculo para el mantenimiento de la aplicación? [cerrado]

14

Como se indica en el título, los parámetros opcionales, como los que se usan en C # son útiles ¿O son un obstáculo para el mantenimiento de la aplicación y deben evitarse ya que pueden hacer que el código sea más difícil de entender?

    
pregunta rjzii 30.11.2010 - 16:10

10 respuestas

22

En mi experiencia, los parámetros opcionales han sido una buena cosa. Nunca los he encontrado confusos (al menos no más confusos que la función real), ya que siempre puedo obtener los valores predeterminados y saber qué se llama.

Un uso para ellos es cuando tengo que agregar otro parámetro a una función que ya está en uso general, o al menos en la interfaz pública. Sin ellos, tendría que rehacer la función original para llamar a uno que tiene otro argumento, y que puede volverse muy viejo si termino agregando argumentos más de una vez.

    
respondido por el David Thornley 30.11.2010 - 16:15
15

En general, si necesita muchos / parámetros opcionales a menudo, sus funciones están haciendo demasiado, y deberían estar separadas. Es probable que estés rompiendo el SRP (Principio de responsabilidad única).

Busque los parámetros que se pueden agrupar, por ejemplo (xey, se convierten en un punto).

¿Estas banderas de parámetros opcionales tienen un valor predeterminado? Si estás usando banderas, la función debería estar dividida.

Eso no quiere decir que nunca debas tener parámetros opcionales, pero en general, más de uno o dos parámetros sugieren un olor a código.

También podría ser una pista de que la función, en realidad debería ser una clase, con los parámetros opcionales cambiados a propiedades, y la parte de parámetros requerida del constructor.

    
respondido por el CaffGeek 30.11.2010 - 16:22
4

Los parámetros opcionales están bien

Por lo general, la justificación es que a) sabes que tienes muchos argumentos posibles para tu método pero no quieres sobrecargarte por temor a saturar tu API, o b) cuando no sabes todo lo posible argumentos, pero no desea forzar a su usuario para proporcionar una matriz. En cada caso, los parámetros opcionales vienen al rescate de una manera limpia y elegante.

Aquí hay algunos ejemplos:

1. Desea evitar la sobrecarga y no desea especificar una matriz

Eche un vistazo a printf () de C, Perl, Java, etc. Es un gran ejemplo del poder de parámetros opcionales.

Por ejemplo:

printf("I want %d %s %s",1,"chocolate","biccies");

printf("I want %d banana",1);

Sin sobrecargas, sin matrices, simple e intuitivo (una vez que haya comprendido los códigos de formato de cadena estándar). Algunos IDE incluso le dirán si su cadena de formato no coincide con sus parámetros opcionales.

2. Desea permitir el uso de valores predeterminados y mantenerlos ocultos para el usuario del método

sendEmail ("[email protected]");

El método sendEmail detecta que faltan varios valores esenciales y los llena utilizando valores predeterminados definidos (asunto, cuerpo, cc, bcc, etc.). La API se mantiene limpia, pero flexible.

Una nota sobre demasiados parámetros

Sin embargo, como han dicho otros, tener demasiados parámetros obligatorios para un método indica que probablemente tenga algún problema con su diseño. Esto es particularmente cierto si comparten el mismo tipo, ya que el desarrollador puede cambiarlos por accidente, lo que produce resultados extraños en el tiempo de ejecución:

String myMethod(String x, String y, String z, String a, int b, String c, int d) {}

es un candidato ideal para el Presente el Objeto de Parámetro para crear una factorización

String myMethod(ParameterObject po) {}

class ParameterObject {
  // Left as public for clarity
  public String x;
  public String y;
  ... etc

}

Esto, a su vez, puede llevar a un mejor diseño basado en un patrón de Fábrica con una especificación proporcionada como el objeto de parámetro.

    
respondido por el Gary Rowe 30.11.2010 - 18:19
2

Uno de los problemas con los parámetros predeterminados en C # (estoy pensando en anular DoSomething (int x = 1)) es que son constantes. Eso significa que si cambia el valor predeterminado, tendrá que volver a compilar a los consumidores de esa llamada de método. Si bien esto es bastante fácil de hacer, hay ocasiones en que esto es peligroso.

    
respondido por el Po-ta-toe 08.05.2012 - 08:54
1

Depende de lo que esté haciendo tu código. Si hay valores predeterminados razonables, debe usar parámetros opcionales, pero si no hay valores predeterminados razonables, agregar parámetros opcionales hará que su código sea más complicado. En muchos casos, los parámetros opcionales son una forma ordenada de eludir las comprobaciones nulas y eliminar la lógica de bifurcación. Javascript no tiene parámetros opcionales, pero hay una manera de emularlos con || (lógico o) y lo uso todo el tiempo cuando hago cosas relacionadas con la base de datos porque si el usuario no proporciona algún valor, entonces sustituyo mis propios valores con la ayuda de || lo que me ahorra la molestia de escribir un montón de declaraciones if then.

    
respondido por el davidk01 30.11.2010 - 21:01
1

Los parámetros opcionales son una excelente manera de hacer que las cosas simples sean simples y las cosas posibles al mismo tiempo. Si hay un valor predeterminado razonable y claro que la mayoría de los usuarios querrán, al menos en casos de uso rápido y sucio, entonces no deberían tener que escribir repetitivo para especificarlo manualmente cada vez que llamen a su función. Por otro lado, si las personas pueden tener una buena razón para querer cambiarlo, entonces es necesario que esté expuesto.

Usar una clase es, en mi humilde opinión, una solución terrible, ya que es detallado, ineficiente e inconsistente con el modelo mental típico de lo que hace una clase. Una función es la abstracción perfecta para un verbo, es decir, hacer algo y volver. Una clase es la abstracción correcta para un sustantivo, es decir, algo que tiene estado y se puede manipular de varias maneras. Si el primero debe ser el modelo mental del usuario de la API, entonces no lo conviertas en una clase.

    
respondido por el dsimcha 01.12.2010 - 03:01
1

El problema con los argumentos opcionales es que las personas tienden a agregar más y más (y más) argumentos a la función en lugar de extraer código relevante en una nueva función. Esto se lleva al extremo en php . Por ejemplo:

bool array_multisort ( array &$arr [, mixed $arg = SORT_ASC
                      [, mixed $arg = SORT_REGULAR [, mixed $... ]]] )
    
respondido por el Martin Wickman 01.12.2010 - 00:03
1

Los parámetros opcionales son básicamente una forma diferente de sobrecargar una función. Entonces, básicamente, esto se reduce a: "¿está sobrecargando una función mal"?

    
respondido por el Pieter B 08.05.2012 - 10:03
1

Inicialmente me encantó esta función en Python, y la usé para "extender" métodos ya utilizados. Y se veía agradable y fácil, pero se mordió pronto; porque cuando agregué un parámetro opcional, esto modificaba el comportamiento de un método existente en el que se basaba el antiguo cliente y de una manera que no fue detectada por los casos de prueba de unidad existentes. Básicamente, hacer esto es romper el Principio Abierto Abierto; El código está abierto para extensión pero cerrado para modificación. Así que creo que usar esta función para modificar el código existente no es una buena idea; pero está bien si se usa desde el principio

    
respondido por el Alex Punnen 01.03.2016 - 11:19
0

Creo que sería mejor sobrecargar una función con diferentes firmas (es decir, parámetros) que usar parámetros opcionales.

    
respondido por el HardCode 30.11.2010 - 18:43

Lea otras preguntas en las etiquetas