Compartir a través de


Sobrecarga de miembro

La firma de un miembro incluye su nombre y su lista de parámetros. Cada firma de miembro debe ser única dentro del tipo. Los miembros pueden tener el mismo nombre siempre y cuando sus listas de parámetros sean diferentes. Cuando dos o más miembros de un tipo sean del mismo tipo de miembro (método, propiedad, constructor, etc.) y tengan el mismo nombre y distintas listas de parámetros, se dice que el miembro está sobrecargado. Por ejemplo, la clase Array contiene dos métodos CopyTo. El primer método toma una matriz y un valor Int32, mientras que el segundo método toma una matriz y un valor Int64.

NotaNota

Cambiar el tipo de valor devuelto de un método no hace que el método sea único según la especificación de Common Language Runtime.No puede definir sobrecargas que sólo se diferencian por el tipo de valor devuelto.

Los miembros sobrecargados deberían proporcionar variaciones en la misma funcionalidad. Por ejemplo, no sería correcto que un tipo tuviera dos miembros CopyTo, en los que los datos del primer miembro se copian en una matriz y los del segundo en un archivo. Un uso habitual de la sobrecarga de miembros es proporcionar sobrecargas que toman pocos parámetros o ninguno y son fáciles de usar. Estos miembros llaman a sobrecargas que son más eficaces, pero también exigen a más experiencia para utilizarlos correctamente. Las sobrecargas fáciles de usar admiten escenarios comunes pasando valores predeterminados a las sobrecargas complejas. Por ejemplo, la clase File proporciona sobrecargas para el método Open. La sobrecarga simple Open toma una ruta de acceso de archivo y modo de archivo. Llama a la sobrecarga Open que toma los parámetros de ruta de acceso, modo de archivo, acceso a archivo y uso compartido de archivo, y proporciona valores predeterminados usados frecuentemente a los parámetros de acceso a archivo y uso compartido de archivo. No es necesario que los desarrolladores que no requieren la flexibilidad de la sobrecarga compleja conozcan los modelos de acceso y uso compartido de archivos para poder abrir un archivo.

Para facilitar el mantenimiento y el control de versiones, las sobrecargas más simples deberían utilizar las sobrecargas complejas para realizar sus acciones; la funcionalidad subyacente no debería implementarse en varios lugares.

Instrucciones de sobrecarga

Las instrucciones siguientes ayudan a garantizar que sus miembros sobrecargados están bien diseñados.

Intente utilizar los nombres de parámetro descriptivos para indicar el valor predeterminado utilizado por las sobrecargas más simples.

Esta instrucción es más aplicable a los parámetros Boolean. El nombre de parámetro de la sobrecarga más compleja debería indicar el valor predeterminado proporcionado por la sobrecarga más simple describiendo la acción o el estado opuesto. Por ejemplo, la clase String proporciona las sobrecargas siguientes:

Overloads Public Shared Function Compare( _
   ByVal strA As String, _
   ByVal strB As String _
) As Integer

Overloads Public Shared Function Compare( _
   ByVal strA As String, _
   ByVal strB As String, _
   ByVal ignoreCase As Boolean _
) As Integer
public static int Compare(
   string strA,
   string strB
);

public static int Compare(
   string strA,
   string strB,
   bool ignoreCase
);

La segunda sobrecarga proporciona un parámetro Boolean denominado ignoreCase. Esto indica que la sobrecarga más simple distingue entre mayúsculas y minúsculas y necesita utilizar la sobrecarga más compleja sólo cuando se desea omitir la distinción entre mayúsculas y minúsculas. En general, el valor predeterminado normalmente debería ser false.

Evite variar arbitrariamente los nombres de parámetro en las sobrecargas. Si un parámetro de una sobrecarga representa la misma entrada que un parámetro de otra sobrecarga, los parámetros deberían tener el mismo nombre.

Por ejemplo, no haga lo siguiente:

Public Sub Write(message as String, stream as FileStream)
End Sub
Public Sub Write(line as String, file as FileStream, closeStream as Boolean)
End Sub
public void Write(string message, FileStream stream){}
public void Write(string line, FileStream file, bool closeStream){}
public:
    void Write(String^ message, FileStream^ stream){}
    void Write(String^ line, FileStream^ file, bool closeStream){}

La definición correcta para estas sobrecargas es como la siguiente:

Public Sub Write(message as String, stream as FileStream)
End Sub
Public Sub Write(message as String, stream as FileStream, _
    closeStream as Boolean)
End Sub
public void Write(string message, FileStream stream){}
public void Write(string message, FileStream stream, bool closeStream){}
public:
    void Write(String^ message, FileStream^ stream){}
    void Write(String^ message, FileStream^ stream, bool closeStream){}

Sea coherente en la ordenación de parámetros de los miembros sobrecargados. Parámetros que tienen el mismo nombre deberían aparecer en la misma posición en todas las sobrecargas.

Por ejemplo, no haga lo siguiente:

Public Sub Write( message as String, stream as FileStream)
End Sub
Public Sub Write(stream as FileStream, message as String, _
    closeStream as Boolean)
End Sub
public void Write(string message, FileStream stream){}
public void Write(FileStream stream,  string message, bool closeStream){}
public:
    void Write(String^ message, FileStream^ stream){}
    void Write(FileStream^ stream, String^ message, bool closeStream){}

La definición correcta para estas sobrecargas es como la siguiente:

Public Sub Write(message as String, stream as FileStream)
End Sub
Public Sub Write(message as String, stream as FileStream, _
    closeStream as Boolean)
End Sub
public void Write(string message, FileStream stream){}
public void Write(string message, FileStream stream, bool closeStream){}
public:
    void Write(String^ message, FileStream^ stream){}
    void Write(String^ message, FileStream^ stream, bool closeStream){}

Esta instrucción tiene dos restricciones:

  • Si una sobrecarga toma una lista de argumentos variable, la lista debe ser el último parámetro.

  • Si la sobrecarga toma los parámetros out, por convención éstos deberían aparecer como los últimos parámetros.

Convierta en virtual sólo la sobrecarga más larga (Overridable en Visual Basic) si se requiere la extensibilidad. Las sobrecargas más cortas simplemente realizan llamadas a una sobrecarga más larga.

El siguiente ejemplo de código ilustra esta práctica.

Public Sub Write(message as String, stream as FileStream)
    Me.Write(message, stream, false)
End Sub

Public Overridable Sub Write( _
    message as String, stream as FileStream, closeStream as Boolean)
    ' Do work here.
End Sub
public void Write(string message, FileStream stream)
{
    this.Write(message, stream, false);
}
public virtual void Write(string message, FileStream stream, bool closeStream)
{
    // Do work here.
}
public:
    void Write(String^ message, FileStream^ stream)
    {
        this->Write(message, stream, false);
    }

    virtual void Write(String^ message, FileStream^ stream, bool closeStream)
    {
        // Do work here.
    }

No utilice los modificadores ref u out para sobrecargar miembros.

Por ejemplo, no haga lo siguiente.

Public Sub Write(message as String,  count as Integer)


...


Public Sub Write(message as String, ByRef count as Integer)
public void Write(string message, int count)


...


public void Write(string message, out int count)
public:
    void Write(String^ message, int count)


...


void Write(String^ message, int% count)

En general, si tiene un diseño en el que ocurre esto, lo más probable es que hay un problema de diseño más profundo. Considere si debería cambiar el nombre de uno de los miembros para proporcionar más información sobre la acción exacta que realiza el método.

Permita pasar valores null (Nothing en Visual Basic) para los argumentos opcionales. Si un método toma argumentos opcionales que son tipos de referencia, permita pasar valores null para indicar que se debería utilizar el valor predeterminado. Esto evita el problema de tener que comprobar si el valor es null antes de llamar a un miembro.

Por ejemplo, los desarrolladores no deberían tener que comprobar si el valor es null en el ejemplo siguiente.

Public Sub CopyFile (source as FileInfo, _
    destination as DirectoryInfo, _
    newName as string)

    If newName Is Nothing
        InternalCopyFile(source, destination) 
    Else
        InternalCopyFile(source, destination, newName)
    End If
End Sub
public void CopyFile (FileInfo source, DirectoryInfo destination, string newName)
{
    if (newName == null)
    {
        InternalCopyFile(source, destination);
    }
    else
    {
        InternalCopyFile(source, destination, newName);
    }
}
public:
    void CopyFile(FileInfo^ source, DirectoryInfo^ destination, String^ newName)
    {
        if (newName == nullptr)
       {
            InternalCopyFile(source, destination);
        }
        else
        {
            InternalCopyFile(source, destination, newName);
        }
    }

Utilice sobrecargas de miembros en lugar de definir miembros con argumentos predeterminados. Los argumentos predeterminados no son conformes a CLS y no se pueden utilizar desde algunos lenguajes.

El ejemplo de código siguiente muestra un diseño de método incorrecto.

Public Sub Rotate (data as Matrix, Optional degrees as Integer = 180)
' Do rotation here
End Sub

Este código se debería rediseñar como dos sobrecargas, siendo la sobrecarga más simple la que proporciona el valor predeterminado. El ejemplo de código siguiente muestra el diseño correcto.

Overloads Public Sub Rotate (data as Matrix)
    Rotate(data, 180)
End Sub

Overloads Public Sub Rotate (data as Matrix, degrees as Integer)
' Do rotation here
End Sub

Portions Copyright 2005 Microsoft Corporation. Reservados todos los derechos.

Portions Copyright Addison-Wesley Corporation. Reservados todos los derechos.

Para obtener más información sobre las directrices de diseño, consulte “las instrucciones de diseño de Framework: Convenciones, frases realizadas y modelos para libro de bibliotecas reutilizables de .NET” de Krzysztof Cwalina y Brad Abrams, publicados por Addison-Wesley, 2005.

Vea también

Otros recursos

Instrucciones de diseño de miembros

Instrucciones de diseño para desarrollar bibliotecas de clases