FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
||||
|
||||
Hola,
Opino igual que Al, ¿10 parámetros? ¿Que de ellos el 40% sea opcional? Desde ya decanto esa opción. Creo que deberías reconsiderar un mejor análisis de la situación. Yo he llegado a declarar funciones, y clases... pero ninguna excede cuanto mucho a los 4 o 5 parámetros. ¿No podrías considerar que agunos parámetros sean propiedades de la clase? Con respecto a la opción que te recomienda Neftali, creo que es la acertada. Y eso no quiere decir que debas codificar 10 veces el mismo código. Como te lo han dicho hay un error de diseño. La solución es buscar la mínima expresión común e implementarla en una función. Cada sobre carga llamará a dicha función (que debe ser privada, según una primera impresión y análisis). El objetivo de los parámetros opcionales es evitar estar declarando valores que en la mayoría de los casos son considerados por defecto (o considerado lo mayormente esperado), por lo cual indicar un valor distinto sería considerado un caso "particular" (algo no habitual). Este enfoque puede llevarse a la inversa. Es decir que nadie puede impedirte que emplees el valor opcional (por defecto) para evitar hacer una cosa. Algo como esto:
En resumen lo que he tratado de decirte es que podrías llevar y emplear el valor opcional en la forma inversa, es decir que si se suministra un valor distinto que se haga la operación que deba realizar. Para finalizar, debo decirte que a pesar de que esta alternativa pueda llegar a funcionar sigue siendo un error conceptual y de diseño ya que el modo de trabajo no es el normal o "el esperado" del lenguaje. Puede llevar a confusiones en el futuro, y lo hace muy dificil de seguirle un correcto mantenimiento y documentación. Espero que se me entienda. Saludos, |
#22
|
||||
|
||||
Cita:
Contando que el método esté bien definido y sin poner en duda la definición de la cabecera (cosa que empiezo a dudar dados los problemas que te surgen), lo que yo he comentado es: Cita:
En ese caso, seguramente habría que cambiar la cabecera de la función y llamar con dos arrays de parámetros, por ejemplo: (x1:Integer; xNames:array of String; xValues: array of string) Un array fijo de 4 posiciones, sólo para los opcionales o algun otro sistema que se ajuste a tus necesidades concretas (9 parámetros de tipo string, 4 opcionesles y que además llamas de la forma comentada).
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#23
|
|||
|
|||
Muchas Gracias
Muchas Gracias a todos los que, tomarón un poco de sutiempo y postearón tratando de ayudar, al final de cuentas deje el procedimiento como estaba, me parecieron execelentes la mayoria de respuestas...Gracias
Creo que con esto se cierra el tema.... Gracias de nuevo. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
¿como llamo un procedimiento almacenado? | jeshu252006 | Conexión con bases de datos | 6 | 28-10-2006 17:49:55 |
Parametros Opcionales no Parametros por defecto | Velia | Varios | 7 | 19-08-2006 15:18:42 |
Parametros Opcionales | c748a | Varios | 5 | 21-09-2005 04:53:25 |
Parametros Opcionales en Procedures/Functions | Enan0 | Varios | 4 | 03-03-2005 10:32:30 |
Parametros opcionales en SELECTs | Gydba | Firebird e Interbase | 4 | 22-04-2004 22:46:38 |
|