Métodos de Extensão

Observação

Este conteúdo é reimpresso com permissão da Pearson Education, Inc. de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Essa edição foi publicada em 2008 e, desde então, o livro foi totalmente revisado na terceira edição. Algumas das informações nesta página podem estar desatualizadas.

Os métodos de extensão são um recurso de linguagem que permite chamar métodos estáticos usando a sintaxe de chamada de método de instância. Esses métodos devem usar pelo menos um parâmetro, que representa a instância em que o método deve operar.

A classe que define esses métodos de extensão é conhecida como a "patrocinadora" e deve ser declarada como estática. Para usar métodos de extensão, é necessário importar o namespace que define a classe patrocinadora.

❌ EVITE definir métodos de extensão de maneira frívola, especialmente em tipos que não são seus.

Se você detiver um código-fonte de um tipo, considere usar métodos de instância regulares. Se você não for o proprietário e quiser adicionar um método, tenha muito cuidado. O uso liberal de métodos de extensão pode desordenar APIs de tipos que não foram projetadas para ter esses métodos.

✔️ CONSIDERE usar métodos de extensão em qualquer um dos seguintes cenários:

  • Para fornecer funcionalidade auxiliar relevante para cada implementação de uma interface, se essa funcionalidade puder ser gravada nos termos da interface principal. Isso ocorre porque implementações concretas não podem ser atribuídas a interfaces. Por exemplo, os operadores LINQ to Objects são implementados como métodos de extensão para todos os tipos IEnumerable<T>. Assim, qualquer implementação IEnumerable<> é habilitada automaticamente para LINQ.

  • Quando um método de instância introduziria uma dependência em algum tipo, mas essa dependência quebraria as regras de gerenciamento de dependência. Por exemplo, uma dependência de String a System.Uri provavelmente não é desejável, portanto, o método de instância String.ToUri() retornando System.Uri seria o design errado de uma perspectiva de gerenciamento de dependências. Um método Uri.ToUri(this string str) de extensão estático retornando System.Uri seria um design muito melhor.

❌ EVITE definir métodos de extensão em System.Object.

Os usuários do VB não poderão chamar esses métodos em referências de objeto usando a sintaxe do método de extensão. O VB não dá suporte à chamada desses métodos porque, no VB, declarar uma referência como Objeto força que todas as invocações de método nele sejam associadas tardiamente (o membro real chamado é determinado em tempo de execução), enquanto as associações aos métodos de extensão são determinadas em tempo de compilação (limite antecipado).

Observe que a diretriz se aplica a outras linguagens em que o mesmo comportamento de associação está presente ou em que métodos de extensão não têm suporte.

❌ NÃO coloque métodos de extensão no mesmo namespace que o tipo estendido, a menos que seja para adicionar métodos a interfaces ou para gerenciamento de dependências.

❌ EVITE definir dois ou mais métodos de extensão com a mesma assinatura, mesmo que eles residam em namespaces diferentes.

✔️ CONSIDERE definir métodos de extensão no mesmo namespace que o tipo estendido se o tipo for uma interface e se os métodos de extensão forem destinados a serem usados na maioria ou em todos os casos.

❌ NÃO defina métodos de extensão que implementam um recurso em namespaces normalmente associados a outros recursos. Em vez disso, defina-os no namespace associado ao recurso ao qual pertencem.

❌ EVITE a nomenclatura genérica de namespaces dedicados aos métodos de extensão (por exemplo, "Extensões"). Use um nome descritivo (por exemplo, "Roteamento") em vez disso.

Portions © 2005, 2009 Microsoft Corporation. Todos os direitos reservados.

Reimpresso com permissão da Pearson Education, Inc. das Diretrizes de Design do Framework: convenções, linguagens e padrões para bibliotecas do .NET reutilizável, 2ª edição por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da série de desenvolvimento do Microsoft Windows.

Confira também