Diseño de parámetros

2025-06-18

Nota:

Este contenido se reimprime con permiso de Pearson Education, Inc. de Directrices de diseño de frameworks: Convenciones, expresiones y patrones para bibliotecas reutilizables de .NET, 2ª edición. Esa edición fue publicada en 2008, y el libro ha sido totalmente revisado en la tercera edición. Parte de la información de esta página puede estar obsoleta.

En esta sección se proporcionan instrucciones generales sobre el diseño de parámetros, incluidas las secciones con instrucciones para comprobar argumentos. Además, debe consultar las directrices descritas en Parámetros de nomenclatura.

✔️ Use el tipo de parámetro menos derivado que proporcione la funcionalidad requerida por el miembro.

Por ejemplo, supongamos que desea diseñar un método que enumera una colección e imprime cada elemento en la consola. Este método debe tomar IEnumerable como parámetro, no ArrayList o IList, por ejemplo.

❌ NO use parámetros reservados.

Si se necesita más información de un miembro en alguna versión futura, se puede agregar una nueva sobrecarga.

❌ NO tiene métodos expuestos públicamente que toman punteros, matrices de punteros o matrices multidimensionales como parámetros.

Los punteros y las matrices multidimensionales son relativamente difíciles de usar correctamente. En casi todos los casos, las API se pueden rediseñar para evitar tomar estos tipos como parámetros.

✔️ COLOQUE todos los parámetros out que siguen a todos los parámetros ref y por valor (excepto las matrices de parámetros), incluso si se produce una incoherencia en el orden de los parámetros entre sobrecargas (consulte Sobrecarga de miembro).

Los out parámetros se pueden ver como valores devueltos adicionales y agruparlos facilita la comprensión de la firma del método.

✔️ SEA coherente a la hora de asignar nombres cuando se invaliden los miembros o se implementen los miembros de interfaz.

Esto comunica mejor la relación entre los métodos.

Elegir entre enumeración y parámetros booleanos

✔️ USE enumeraciones si, de lo contrario, un miembro tendría dos o más parámetros booleanos.

❌ NO use booleanos a menos que esté absolutamente seguro de que nunca habrá una necesidad de más de dos valores.

Las enumeraciones proporcionan espacio para agregar valores futuros, pero debe tener en cuenta todas las implicaciones de agregar valores a enumeraciones, que se describen en Diseño de enumeraciones.

✔️ CONSIDERE la posibilidad de usar booleanos para los parámetros de constructor que son realmente valores de dos estados y que simplemente se usan para inicializar propiedades booleanas.

Validación de argumentos

✔️ VALIDE los argumentos pasados a miembros públicos, protegidos o implementados explícitamente. Lance System.ArgumentException, o una de sus subclases, si la validación falla.

Tenga en cuenta que la validación real no tiene que ocurrir necesariamente en el propio miembro público o protegido. Podría ocurrir en un nivel inferior en alguna rutina privada o interna. El punto principal es que toda el área de superficie visible para los usuarios finales verifica los argumentos.

✔️ INICIE ArgumentNullException si se pasa un argumento NULL y el miembro no admite argumentos NULL.

✔️ VALIDE los parámetros de enumeración.

No suponga que los argumentos de enumeración estarán en el intervalo definido por la enumeración. CLR permite convertir cualquier valor entero en un valor de enumeración aunque el valor no esté definido en la enumeración.

❌ NO use Enum.IsDefined para las comprobaciones de intervalos de enumeración.

✔️ Tenga en cuenta que los argumentos mutables podrían haber cambiado después de validarlos.

Si el miembro es sensible a la seguridad, se recomienda que realice una copia y, a continuación, valide y procese el argumento.

Paso de parámetros

Desde la perspectiva de un diseñador de frameworks, hay tres grupos principales de parámetros: parámetros por valor, refparámetros y outparámetros.

Cuando un argumento se pasa a través de un parámetro por valor, el miembro recibe una copia del argumento real pasado. Si el argumento es un tipo de valor, se coloca una copia del argumento en la pila. Si el argumento es un tipo de referencia, se coloca una copia de la referencia en la pila. Los lenguajes CLR más populares, como C#, VB.NET y C++, de forma predeterminada pasan parámetros por valor.

Cuando un argumento se pasa a través de un parámetro ref, el miembro recibe una referencia al argumento real pasado. Si el argumento es un tipo de valor, se coloca una referencia al argumento en la pila. Si el argumento es un tipo de referencia, se coloca una referencia a la referencia en la pila. Ref Los parámetros se pueden usar para permitir que el miembro modifique los argumentos pasados por el autor de la llamada.

Out Los parámetros son similares a ref, con algunas pequeñas diferencias. Se considera inicialmente que el parámetro está sin asignar y no se puede leer en el cuerpo del miembro antes de que se le asigne algún valor. Además, debe asignarse algún valor al parámetro antes de que vuelva el miembro.

❌ EVITE usar los parámetros out o ref.

El uso de parámetros out o ref requiere experiencia con punteros, entender cómo difieren los tipos de valor y los tipos de referencia, y el manejo de métodos con múltiples valores de retorno. Además, no se suele saber qué diferencia hay entre los parámetros out y ref. Los arquitectos de entornos que diseñan para una audiencia general no deben esperar que los usuarios se vuelvan hábiles en trabajar con parámetros out o ref.

❌ NO pase tipos de referencia por referencia.

Hay algunas excepciones limitadas a la regla, como un método que se puede usar para intercambiar referencias.

Miembros con número variable de parámetros

Los miembros que pueden tomar un número variable de argumentos se expresan proporcionando un parámetro de matriz. Por ejemplo, String proporciona el método siguiente:

public class String {
    public static string Format(string format, object[] parameters);
}

A continuación, un usuario puede llamar al String.Format método , como se indica a continuación:

String.Format("File {0} not found in {1}",new object[]{filename,directory});

Al agregar la palabra clave params de C# a un parámetro de matriz, se cambia el parámetro a un parámetro de matriz params denominado y se proporciona un acceso directo a la creación de una matriz temporal.

public class String {
    public static string Format(string format, params object[] parameters);
}

Esto permite al usuario llamar al método pasando los elementos de matriz directamente en la lista de argumentos.

String.Format("File {0} not found in {1}",filename,directory);

Tenga en cuenta que la palabra clave params solo se puede agregar al último parámetro de la lista de parámetros.

✔️ CONSIDERE la posibilidad de agregar la palabra clave params a los parámetros de matriz si espera que los usuarios finales pasen matrices con un pequeño número de elementos. Si se espera que se pasen muchos elementos en escenarios comunes, es probable que los usuarios no pasen estos elementos en línea de todos modos y, por tanto, la palabra clave params no es necesaria.

❌ EVITE usar matrices de parámetros si el autor de la llamada casi siempre tendría la entrada ya en una matriz.

Por ejemplo, nunca se llamaría a los miembros con parámetros de matriz de bytes pasando bytes individuales. Por este motivo, los parámetros de matriz de bytes de .NET Framework no usan la palabra clave params.

❌ NO use matrices params si el miembro que toma el parámetro de matriz params modifica la matriz.

Debido al hecho de que muchos compiladores convierten los argumentos al miembro en una matriz temporal en el sitio de llamada, la matriz podría ser un objeto temporal y, por tanto, se perderán las modificaciones en la matriz.

✔️ CONSIDERE la posibilidad de usar la palabra clave params en una sobrecarga simple, incluso si una sobrecarga más compleja no pudiera utilizarla.

Pregúntese si los usuarios valoran tener la matriz de parámetros en una sobrecarga aunque no estuviera en todas las sobrecargas.

✔️ Intente ordenar parámetros para que sea posible usar la palabra clave params.

✔️ CONSIDERE la posibilidad de proporcionar sobrecargas y rutas de acceso al código especiales para las llamadas con un pequeño número de argumentos en las API que requieran un rendimiento muy alto.

Esto permite evitar la creación de objetos de matriz cuando se llama a la API con un pequeño número de argumentos. Forme los nombres de los parámetros tomando una forma singular del parámetro de matriz y agregando un sufijo numérico.

Solo debe hacerlo si va a marcar como caso especial toda la ruta de acceso al código, no solo crear una matriz y llamar al método más general.

✔️ Tenga en cuenta que null podría pasarse como argumento de una matriz de parámetros.

Debe validar que la matriz no es nula antes de procesarla.

❌ NO utilice los métodos varargs, también conocidos como puntos suspensivos.

Algunos lenguajes CLR, como C++, admiten una convención alternativa para pasar listas de parámetros de variable denominadas varargs métodos. La convención no debe usarse en marcos, ya que no es compatible con CLS.

Parámetros de puntero

En general, los punteros no deberían aparecer en el área expuesta pública de un marco de código administrado bien diseñado. La mayoría de las veces, se deben encapsular los punteros. Sin embargo, en algunos casos se requieren punteros por motivos de interoperabilidad y el uso de punteros en estos casos es adecuado.

✔️ PROPORCIONE una alternativa para cualquier miembro que tome un argumento de puntero, ya que los punteros no son conformes a CLS.

❌ EVITE realizar una comprobación costosa de los argumentos de puntero.

✔️ SIGA las convenciones habituales relacionadas con el puntero al diseñar miembros con punteros.

Por ejemplo, no es necesario pasar el índice de inicio, ya que se puede usar una aritmética de puntero simple para lograr el mismo resultado.

Reimpreso con permiso de Pearson Education, Inc. de Framework Design Guidelines: Convenciones, Idiomas y Patrones para Bibliotecas .NET Reusables, 2ª Edición por Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la Serie Desarrollo de Microsoft Windows.

Compartir a través de