Hola,
A ver... si la idea es que el resultado en realidad sea un "algo más otros" la función en realidad, técnicamente, SI está regresando varios valores... en cierto modo.
Pongamos por ejemplo que sea algo como:
Código Delphi
[-]const
OK = 0;
RESULT_OK1 = 1;
RESULT_OK2 = 2;
...
RESULT_OKN = N;
RESULT_NOT_OK = -1;
...
Si se diseña la función para regresar siempre un resultado que sea:
Código Delphi
[-]result := OK + LaConstante
Entonces podría decirse que si, la función estará regresando diferentes valores. El problema pasa aquí no por el lado de la función, sino del cliente que la utilizará. Es YA UNA RESPONSABILIDAD DE ÉSTE de procesar ese resultado variante. La manera más fácil y elemental de dar respuesta es disponer de un CASE:
Código Delphi
[-]
res := LlamandoAFuncion(...);
case res of
RESULT_OK1: ...
...
RESULT_OKN: ...
else ...
end;
Esta técnica, o algunas variantes menores, es utilizada en algunas bibliotecas. El concepto y la aplicación se sustenta en el uso de constantes, un resulto muy útil y pasado por alto.
Otra posibilidad que también puede considerarse como se señala en el hilo recomendado ecfisa es el uso de parámetros "var".
Es decir:
function NombreFuncion(Param1, tipo; ... ; var ParamResult: tipo);
begin
....
end;
Y dentro del cuerpo de la función alterar el valor de ParamResult por el adecuado.
Noten como ambos esquemas son posibles, es más yo sugeriría que los valores que devuelva ParamResult estén definidos como constantes:
Código Delphi
[-]
res := NombreFuncion(...,res_out);
case res_out of:
....
Uno de los peores males y diseños que deben evitarse es que una función regrese un array. Incluso, en lo posible debe de evitarse regresar una estructura como ser un record, o que esté formado por un conjunto de datos simples. Esto hace que existe un
acoplamiento de estampado, que si bien manejado no es maligno debe repensarse su utilización.
Además este acoplamiento se sugiere, y se lo utiliza de forma inversa. Es decir el módulo cliente o coordinador es quien le pasa como parámetro a otro módulo la estructura que requiere.
La idea que la función le regrese al cliente o coordinador dicha estructura es un esquema un tanto fuera de lo normal, a pesar de que pueden aceptarse casos como éste.
Hay dos peligros de este acoplamiento:
información Innecesaria: pueden darse casos en que no toda la información de dicha estructura se utilice por tanto se malgasta "espacio" o se pierde utilidad, y termina obscureciendo su uso.
bundling o empaquetamiento artificial: que se terminen empaquetando en una estructura de datos información no relacionada con la idea de reutilizarla en otros módulos y ganar "espacio" en los parámetros. Por ejemplo:
Código Delphi
[-]TInfoVentasRecibo: record
NroFactura: integer;
NroRecibo: integer;
DetalleFactura: array[0..MAX_FACTURAS] of TFactura;
DetalleRecibo: array[0..MAX_RECIBOS] of TRecibo;
end;
En el ejemplo se ha intentado "empaquetar" tanto la información sobre las Facturas y Recibos en una sola cosa pensando que sería una gran idea tenerlas juntas porque en dos o tres lugares se requiere de ambas. ¿Porqué no mejor separar Facturas de Recibos?
¿Se ve mejor el peligro de este acomplamiento? El acoplamiento por medio de parametros por referencia/valor de datos simples es más fácil de mantener, limpio y sano que este empaquetado.
En lo posible hay que llegar al acoplamiento de datos o al de Control (cuando un parámetro se utiliza para controlar la lógica interna).
Saludos,