Sobrecarga de membro

Artigo
08/01/2011

Assinatura de um membro inclui sua lista de nome e o parâmetro. Cada assinatura do membro deve ser exclusiva dentro do tipo. Os membros podem ter o mesmo nome, contanto que diferem de suas listas de parâmetros. Quando dois ou mais membros em um tipo são o mesmo tipo de membro (método, propriedade, construtor e assim por diante) e tem o mesmo nome e as listas de parâmetros diferentes, o membro é dito ser sobrecarregados. Por exemplo, o Array classe contém dois CopyTo métodos. A primeira usa de método um array e uma Int32 valor e a segunda usa do método um array e uma Int64 valor.

Observação

Alterar o tipo de retorno de um método não faz o método exclusivo, conforme indicado no common language runtime specification.Não é possível definir sobrecargas que variam de acordo somente com o tipo de retorno.

Membros sobrecarregados devem fornecer a variações sobre a mesma funcionalidade. Por exemplo, não seria correto para um tipo para ter dois CopyTo membros, onde o primeiro membro copiou os dados para uma matriz e os segundo dados copiados para um arquivo. Um uso comum de sobrecarga do membro é fornecem sobrecargas que usam parâmetros poucos ou nenhum e são fáceis de usar. Esses membros chamam sobrecargas que são mais eficientes, mas também exigem mais experiência para usar corretamente. Sobrecargas de fácil de usar suportam a cenários comuns, passando os valores padrão para as sobrecargas de complexas. Por exemplo, o File classe fornece sobrecargas para o Open método. A sobrecarga de simple Open toma um caminho de arquivo e o modo de arquivo. Ele chama o Open sobrecarga que utiliza o caminho, o modo de arquivo, acesso a arquivos e parâmetros de compartilhamento de arquivo e fornece comumente usados valores padrão para o acesso a arquivos e parâmetros de compartilhamento de arquivo. Os desenvolvedores que não é necessário a flexibilidade da sobrecarga de complexa não precisa saber sobre o acesso a arquivos e modelos de compartilhamento para poder abrir um arquivo.

Para facilidade de manutenção e Versionamento, sobrecargas de simples devem usar sobrecargas de complexas para realizar suas ações; a funcionalidade subjacente não deve ser implementada em vários lugares.

Diretrizes de sobrecarga.

As diretrizes a seguir ajudam a garantir que seus membros sobrecarregados são bem projetados.

Tente usar nomes de parâmetro descritivo para indicar o valor padrão usado pelas sobrecargas mais simples.

Essa diretriz é mais aplicável para Boolean parâmetros. O nome do parâmetro da sobrecarga mais complexo deve indicar o valor padrão fornecido pela sobrecarga mais simples, que descreve o estado ou a ação oposta. Por exemplo, o String classe fornece os seguintes métodos sobrecarregados:

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
);

A segunda sobrecarga fornece uma Boolean parâmetro chamado ignoreCase. Isso indica que diferencia a sobrecarga mais simples e você precisará usar a sobrecarga mais complexa, somente quando você deseja ignorar maiúsculas e minúsculas. Em geral, o valor padrão deve normalmente ser false.

Evite arbitrariamente diversos nomes de parâmetro em sobrecargas. Se um parâmetro em uma sobrecarga representa a mesma entrada como um parâmetro em sobrecarga de outro, os parâmetros devem ter o mesmo nome.

Por exemplo, não faça o seguinte:

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){}

A definição correta para essas sobrecargas é o seguinte:

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){}

Ser consistente com a ordem dos parâmetros de membros sobrecarregados. Parâmetros com o mesmo nome devem aparecer na mesma posição em todas as sobrecargas.

Por exemplo, não faça o seguinte:

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){}

A definição correta para essas sobrecargas é o seguinte:

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){}

Essa diretriz tem duas restrições:

Se uma sobrecarga leva a uma lista de argumento variável, a lista deve ser o último parâmetro.
Se a sobrecarga tem out parâmetros, por convenção, eles devem aparecer como o último parâmetros.

Verifique apenas a maior sobrecarga virtual (Overridable em Visual Basic) se for necessária a extensibilidade. Sobrecargas de menores devem simplesmente chamar por meio a uma sobrecarga maior.

O exemplo de código a seguir demonstra essa prática.

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.
    }

Não usar ref ou out modificadores para sobrecarregar membros.

Por exemplo, não faça o seguinte.

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)

Em geral, se você tiver um design onde ocorre, provavelmente há um problema de design mais profundo. Considere a possibilidade de se um dos membros deve ser renomeado para fornecer mais informações sobre a ação exata que está sendo executada pelo método.

Permitir nulo (Nothing no Visual Basic) a serem passados para os argumentos opcionais. Se um método leva argumentos opcionais que são tipos de referência, permita nulos a serem passados para indicar que o valor padrão deve ser usado. Isso evita o problema de ter que verificar antes de chamar um membro null.

Por exemplo, os desenvolvedores não devem ter que verificar se há null o exemplo a seguir.

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);
        }
    }

Use o membro sobrecarga, em vez de definir os membros com argumentos padrão. Os argumentos padrão não são compatíveis com CLS e não podem ser usados em alguns idiomas.

O exemplo de código a seguir demonstra o design do método incorreto.

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

Esse código deve ser redesenhado como duas sobrecargas com a sobrecarga mais simples, fornecendo o valor padrão. O exemplo de código a seguir demonstra o design correto.

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

Para obter mais informações sobre as diretrizes de design, consulte a "diretrizes de Design do Framework: Convenções, idiomas e padrões de reutilizável.Bibliotecas de rede" catálogo por Krzysztof Cwalina e Brad Abrams, publicado pela Addison-Wesley, 2005.

Consulte também

Outros recursos

Diretrizes de Design do membro

Diretrizes de Design para desenvolvimento bibliotecas de classe

Partilhar via

Sobrecarga de membro

Diretrizes de sobrecarga.

Consulte também

Outros recursos

Recursos adicionais