¿Código de retorno o parámetro de salida?

Question

Estoy haciendo un método para obtener una lista de nombres de archivos de un servidor, pero he llegado a un problema que no puedo responder.

el método devuelve dos cosas:

• un SftpResult que es una enumeración con una variedad de códigos de retorno.
• la lista de nombres de archivos.

De estas tres firmas:

public static ArrayList GetFileList(string directory, out SftpResult result)

public static SftpResult GetFileList(string directory, out ArrayList fileNames)

public static SftpFileListResult GetFileList(string directory)

(donde SftpFileListResult es un objeto compuesto de una SftpResult y un ArrayList)

, ¿cuál es el preferido y por qué?

Answer 1

Personalmente prefiero la última opción (aunque usando un List<T> o ReadOnlyCollection<T> en lugar de ArrayList). Los parámetros out son básicamente una forma de devolver valores múltiples, y es generalmente más agradable para encapsularlos.

Otra opción en .NET 4 sería

Tuple<SftpResult, ArrayList> GetFileList(string directory) 

Eso dice explícitamente: "este método devuelve dos cosas ... los he empaquetadas para usted para este caso en particular, pero no vale la pena más encapsulándolos: no vale la pena componerlos en un tipo separado ".

(Si no está utilizando .NET 4 siempre se puede escribir su propio tipo Tuple.)

Answer 2

Prefiero la última opción. Los parámetros de salida rara vez se usan y pueden ser sorprendentes/confusos para algunos. Crear un objeto de resultado compuesto es una solución limpia. El único inconveniente es que debe crear una clase únicamente para este fin.

Answer 3

yo preferiría envolverlo en un objeto de retorno:

class FileResult 
{ 
    public FileResult(SftpResult resultCode, IEnumerable<string> files) 
    { 
     ResultCode = resultCode; 
     FileList = new List<string>(files); 
    } 
    public SftpResult ResultCode { get; private set; } 
    public IEnumerable<string> FileList { get; private set; } 
} 

Se siente una mucho más limpio para no usar out.

Answer 4

Diría que es el tercero, ya que encapsula la lógica que necesita en una ubicación. Solo puedo suponer que los métodos de retorno SftpResult y ArrayList deben ser privados y luego compensar la lógica interna del objeto de retorno compuesto.

Answer 5

lo haría:

public static bool GetFileList(string directory, out SftpResult result, out ArrayList fileNames) 

lo que no hay confusión acerca de lo que hace la función, y también me gustaría devolver un bool, si el GetFileList puede fallar.

Answer 6

¿Por qué no proporcionar los tres? Prefiero no tener parámetros fuera de mi función de llamadas, pero puedo apreciar que en muchas ocasiones son necesarios.Si no sabe qué firma respaldar, entonces apoye los tres. En última instancia, la elección está del lado de la persona que llama y lo mejor que puede hacer es ofrecer esta opción.

Answer 7

Si te gustan los diseños donde una función hace dos cosas, entonces usaría una tupla a la Jon o un objeto de retorno a la Fredrik.

Si quería ser todo OOPy de ello se podía permitir que el sistema de tipos hacen el trabajo:

abstract class FtpResult { ... } 
sealed class FileList : FtpResult { ... } 
sealed class Error : FtpResult { ... } 
... 
sealed class FtpService 
{ 
    ... 
    public FtpResult GetFileList(string directory) { ... } 
    ... 
} 
... 
var result = service.GetFileList(dir); 
var error = result as Error; 
var list = result as FileList; 
if (error != null) { ... } 
else if (list != null) 
{ 
    foreach(var name in list.Files) { ... } 
} 
...