Partilhar via

18 Interfaces

  • Artigo

18.1 Geral

Uma interface define um contrato. Uma classe ou estrutura que implemente uma interface deve aderir ao seu contrato. Uma interface pode herdar de várias interfaces base, e uma classe ou struct pode implementar várias interfaces.

As interfaces podem conter métodos, propriedades, eventos e indexadores. A interface em si não fornece implementações para os membros que declara. A interface apenas especifica os membros que devem ser fornecidos por classes ou estruturas que implementam a interface.

18.2 Declarações de interface

18.2.1 Generalidades

Um interface_declaration é um type_declaration (§14.7) que declara um novo tipo de interface.

interface_declaration
    : attributes? interface_modifier* 'partial'? 'interface'
      identifier variant_type_parameter_list? interface_base?
      type_parameter_constraints_clause* interface_body ';'?
    ;

Um interface_declaration consiste num conjunto opcional de atributos (§22), seguido por um conjunto opcional de interface_modifiers (§18.2.2), seguido por um modificador parcial opcional (§15.2.7), seguido pela palavra-chave e um interface que nomeia a interface, seguido por uma especificação variant_type_parameter_list opcional (§18.2.3), seguida por um interface_base opcional especificação (§18.2.4), seguida de uma especificação opcional type_parameter_constraints_clause(§15.2.5), seguida de uma interface_body (§18.3), opcionalmente seguida de ponto e vírgula.

Uma declaração de interface só pode fornecer um type_parameter_constraints_clausese fornecer também um variant_type_parameter_list.

Uma declaração de interface que fornece um variant_type_parameter_list é uma declaração de interface genérica. Além disso, qualquer interface aninhada dentro de uma declaração de classe genérica ou uma declaração struct genérica é ela própria uma declaração de interface genérica, uma vez que os argumentos de tipo para o tipo que contém devem ser fornecidos para criar um tipo construído (§8.4).

18.2.2 Modificadores de interface

Um interface_declaration pode, opcionalmente, incluir uma sequência de modificadores de interface:

interface_modifier
    : 'new'
    | 'public'
    | 'protected'
    | 'internal'
    | 'private'
    | unsafe_modifier   // unsafe code support
    ;

unsafe_modifier (§23.2) só está disponível em código não seguro (§23).

É um erro em tempo de compilação para o mesmo modificador aparecer várias vezes em uma declaração de interface.

O new modificador só é permitido em interfaces definidas dentro de uma classe. Especifica que a interface oculta um membro herdado com o mesmo nome, conforme descrito no §15.3.5.

Os publicmodificadores , protected, internale private controlam a acessibilidade da interface. Dependendo do contexto em que a declaração de interface ocorre, apenas alguns desses modificadores podem ser permitidos (§7.5.2). Quando uma declaração de tipo parcial (§15.2.7) inclui uma especificação de acessibilidade (através dos modificadores , public, protected, e internal ), aplicam-se as regras do private.

18.2.3 Listas de parâmetros de tipo variante

18.2.3.1 Generalidades

As listas de parâmetros de tipo variante só podem ocorrer em tipos de interface e delegados. A diferença do type_parameter_list s comum é o variance_annotation opcional em cada parâmetro detipo.

variant_type_parameter_list
    : '<' variant_type_parameters '>'
    ;

variant_type_parameters
    : attributes? variance_annotation? type_parameter
    | variant_type_parameters ',' attributes? variance_annotation?
      type_parameter
    ;

variance_annotation
    : 'in'
    | 'out'
    ;

Se a anotação de variância for out, o parâmetro type é dito ser covariante. Se a anotação de variância for in, o parâmetro type é dito ser contravariante. Se não houver anotação de variância, o parâmetro type é dito invariante.

Exemplo: No seguinte:

interface C<out X, in Y, Z>
{
    X M(Y y);
    Z P { get; set; }
}

X é covariante, Y é contravariante e é invariante Z .

Exemplo final

Se uma interface genérica for declarada em várias partes (§15.2.3), cada declaração parcial deve especificar a mesma variância para cada parâmetro de tipo.

18.2.3.2 Segurança da variância

A ocorrência de anotações de variância na lista de parâmetros de tipo de um tipo restringe os locais onde os tipos podem ocorrer dentro da declaração de tipo.

Um tipo T não é seguro para saída se uma das seguintes opções se mantiver:

  • T é um parâmetro de tipo contravariante
  • T é um tipo de matriz com um tipo de elemento não seguro de saída
  • T é um tipo de interface ou delegado Sᵢ,... Aₑ construído a partir de um tipo S<Xᵢ, ... Xₑ> genérico em que, pelo menos, uma Aᵢ das seguintes opções se mantém:
    • Xᵢ é covariante ou invariante e Aᵢ não é seguro em termos de saída.
    • Xᵢ é contravariante ou invariante e Aᵢ não é seguro para entrada.

Um tipo T não é seguro de entrada se uma das seguintes opções se mantiver:

  • T é um parâmetro de tipo covariante
  • T é um tipo de matriz com um tipo de elemento não seguro de entrada
  • T é um tipo de interface ou delegado S<Aᵢ,... Aₑ> construído a partir de um tipo S<Xᵢ, ... Xₑ> genérico em que, pelo menos, uma Aᵢ das seguintes opções se mantém:
    • Xᵢ é covariante ou invariante e Aᵢ não é seguro para entrada.
    • Xᵢ é contravariante ou invariante e Aᵢ não é segura.

Intuitivamente, um tipo de saída não segura é proibido em uma posição de saída, e um tipo de entrada não segura é proibido em uma posição de entrada.

Um tipo é seguro para saída se não for inseguro para saída e seguro para entrada se não for inseguro.

18.2.3.3 Conversão de variância

O objetivo das anotações de variância é fornecer conversões mais brandas (mas ainda seguras para tipos) para tipos de interface e delegados. Para o efeito, as definições de conversões implícitas (§10.2) e explícitas (§10.3) utilizam a noção de variância-convertibilidade, que é definida da seguinte forma:

Um tipo T<Aᵢ, ..., Aᵥ> é conversível em variância para um tipo T<Bᵢ, ..., Bᵥ> se T for uma interface ou um tipo delegado declarado com os parâmetros T<Xᵢ, ..., Xᵥ>de tipo variante e, para cada parâmetro Xᵢ de tipo de variante, uma das seguintes retenções:

  • Xᵢ é covariante e existe uma referência implícita ou conversão de identidade de Aᵢ para Bᵢ
  • Xᵢ é contravariante e existe uma referência implícita ou conversão de identidade de Bᵢ para Aᵢ
  • Xᵢ é invariante e existe uma conversão de Aᵢ identidade de para Bᵢ

18.2.4 Interfaces de base

Uma interface pode herdar de zero ou mais tipos de interface, que são chamados de interfaces base explícitas da interface. Quando uma interface tem uma ou mais interfaces base explícitas, na declaração dessa interface, o identificador de interface é seguido por dois pontos e uma lista separada por vírgulas de tipos de interface base.

interface_base
    : ':' interface_type_list
    ;

As interfaces de base explícitas podem ser construídas tipos de interface (§8.4, §18.2). Uma interface base não pode ser um parâmetro de tipo por si só, embora possa envolver os parâmetros de tipo que estão no escopo.

Para um tipo de interface construída, as interfaces de base explícitas são formadas tomando as declarações de interface de base explícitas na declaração de tipo genérica e substituindo, para cada type_parameter na declaração de interface de base, a type_argument correspondente do tipo construído.

As interfaces de base explícitas de uma interface devem ser pelo menos tão acessíveis como a própria interface (ponto 7.5.5).

Nota: Por exemplo, é um erro em tempo de compilação especificar uma private ou internal interface no interface_base de uma public interface. Nota final

É um erro em tempo de compilação para uma interface herdar direta ou indiretamente de si mesma.

As interfaces base de uma interface são as interfaces base explícitas e suas interfaces base. Em outras palavras, o conjunto de interfaces base é o fechamento transitivo completo das interfaces base explícitas, suas interfaces base explícitas e assim por diante. Uma interface herda todos os membros de suas interfaces base.

Exemplo: No código a seguir

interface IControl
{
    void Paint();
}

interface ITextBox : IControl
{
    void SetText(string text);
}

interface IListBox : IControl
{
    void SetItems(string[] items);
}

interface IComboBox: ITextBox, IListBox {}

as interfaces de base de IComboBox são IControl, ITextBox, e IListBox. Em outras palavras, a IComboBox interface acima herda membros SetText e SetItems também Paint.

Exemplo final

Os membros herdados de um tipo genérico construído são herdados após a substituição do tipo. Ou seja, todos os tipos constituintes no membro têm os parâmetros de tipo da declaração de classe base substituídos pelos argumentos de tipo correspondentes usados na especificação class_base .

Exemplo: No código a seguir

interface IBase<T>
{
    T[] Combine(T a, T b);
}

interface IDerived : IBase<string[,]>
{
    // Inherited: string[][,] Combine(string[,] a, string[,] b);
}

A interface IDerived herda o Combine método depois que o parâmetro T type é substituído por string[,].

Exemplo final

Uma classe ou struct que implementa uma interface também implementa implicitamente todas as interfaces base da interface.

O tratamento de interfaces em várias partes de uma declaração de interface parcial (§15.2.7) é discutido mais pormenorizadamente no §15.2.4.3.

Todas as interfaces de base de uma interface devem ser seguras para a saída (§18.2.3.2).

18.3 Corpo da interface

O interface_body de uma interface define os membros da interface.

interface_body
    : '{' interface_member_declaration* '}'
    ;

18.4 Membros da interface

18.4.1 Generalidades

Os membros de uma interface são os membros herdados das interfaces base e os membros declarados pela própria interface.

interface_member_declaration
    : interface_method_declaration
    | interface_property_declaration
    | interface_event_declaration
    | interface_indexer_declaration
    ;

Uma declaração de interface declara zero ou mais membros. Os membros de uma interface devem ser métodos, propriedades, eventos ou indexadores. Uma interface não pode conter constantes, campos, operadores, construtores de instância, finalizadores ou tipos, nem pode conter membros estáticos de qualquer tipo.

Todos os membros da interface têm implicitamente acesso público. É um erro em tempo de compilação para declarações de membro da interface para incluir quaisquer modificadores.

Um interface_declaration cria um novo espaço de declaração (§7.3), e os parâmetros de tipo e interface_member_declarationcontidos imediatamente pelo interface_declaration introduzem novos membros nesse espaço de declaração. As seguintes regras aplicam-se a interface_member_declarations:

  • O nome de um parâmetro de tipo na variant_type_parameter_list de uma declaração de interface deve diferir dos nomes de todos os outros parâmetros de tipo na mesma variant_type_parameter_list e deve diferir dos nomes de todos os membros da interface.
  • O nome de um método deve diferir dos nomes de todas as propriedades e eventos declarados na mesma interface. Além disso, a assinatura (§7.6) de um método deve diferir das assinaturas de todos os outros métodos declarados na mesma interface, e dois métodos declarados na mesma interface não devem ter assinaturas que diferem apenas por in, oute ref.
  • O nome de uma propriedade ou evento deve diferir dos nomes de todos os outros membros declarados na mesma interface.
  • A assinatura de um indexador deve diferir das assinaturas de todos os outros indexadores declarados na mesma interface.

Os membros herdados de uma interface especificamente não fazem parte do espaço de declaração da interface. Assim, uma interface pode declarar um membro com o mesmo nome ou assinatura que um membro herdado. Quando isso ocorre, diz-se que o membro da interface derivada oculta o membro da interface base. Ocultar um membro herdado não é considerado um erro, mas faz com que um compilador emita um aviso. Para suprimir o aviso, a declaração do membro derivado da interface deve incluir um new modificador para indicar que o membro derivado se destina a ocultar o membro base. Este tópico é discutido mais detalhadamente no §7.7.2.3.

Se um new modificador for incluído em uma declaração que não oculte um membro herdado, um aviso será emitido para esse efeito. Este aviso é suprimido removendo o new modificador.

Nota: Os membros em classe object não são, a rigor, membros de qualquer interface (§18.4). No entanto, os membros em classe object estão disponíveis através da pesquisa de membros em qualquer tipo de interface (§12.5). Nota final

O conjunto de membros de uma interface declarado em várias partes (§15.2.7) é a união dos membros declarados em cada parte. Os corpos de todas as partes da declaração de interface partilham o mesmo espaço de declaração (§7.3), e o âmbito de cada membro (§7.7) estende-se aos corpos de todas as partes.

18.4.2 Métodos de interface

Os métodos de interface são declarados usando interface_method_declarations:

interface_method_declaration
    : attributes? 'new'? return_type interface_method_header
    | attributes? 'new'? ref_kind ref_return_type interface_method_header
    ;

interface_method_header
    : identifier '(' parameter_list? ')' ';'
    | identifier type_parameter_list '(' parameter_list? ')'
      type_parameter_constraints_clause* ';'
    ;

Os atributos, return_type, ref_return_type, identificador e parameter_list de uma declaração de método de interface têm o mesmo significado que os de uma declaração de método em uma classe (§15.6). Uma declaração de método de interface não tem permissão para especificar um corpo de método e, portanto, a declaração sempre termina com um ponto-e-vírgula.

Todos os tipos de parâmetros de um método de interface devem ser seguros para a entrada (§18.2.3.2) e o tipo de retorno deve ser seguro para a void saída ou para a produção. Além disso, quaisquer tipos de parâmetros de saída ou de referência devem também ser seguros para a produção.

Nota: Os parâmetros de saída devem ser seguros para entrada devido a restrições comuns de implementação. Nota final

Além disso, cada restrição de tipo de classe, restrição de tipo de interface e restrição de parâmetros de tipo em qualquer parâmetro de tipo do método deve ser segura para entradas.

Além disso, cada restrição de tipo de classe, restrição de tipo de interface e restrição de parâmetro de tipo em qualquer parâmetro de tipo do método deve ser segura para entradas.

Essas regras garantem que qualquer uso covariante ou contravariante da interface permaneça seguro para digitação.

Exemplo:

interface I<out T>
{
    void M<U>() where U : T;     // Error
}

está mal formado porque o uso de como uma restrição de parâmetro de T tipo não U é seguro para entradas.

Se esta restrição não estivesse em vigor, seria possível violar a segurança do tipo da seguinte maneira:

class B {}
class D : B {}
class E : B {}
class C : I<D>
{
    public void M<U>() {...} 
}

...

I<B> b = new C();
b.M<E>();

Trata-se, na verdade, de um apelo à C.M<E>. Mas essa chamada exige que E derive de , então a segurança do tipo seria violada Daqui.

Exemplo final

18.4.3 Propriedades da interface

As propriedades da interface são declaradas usando interface_property_declarations:

interface_property_declaration
    : attributes? 'new'? type identifier '{' interface_accessors '}'
    | attributes? 'new'? ref_kind type identifier '{' ref_interface_accessor '}'
    ;

interface_accessors
    : attributes? 'get' ';'
    | attributes? 'set' ';'
    | attributes? 'get' ';' attributes? 'set' ';'
    | attributes? 'set' ';' attributes? 'get' ';'
    ;

ref_interface_accessor
    : attributes? 'get' ';'
    ;

Os atributos, o tipo e o identificador de uma declaração de propriedade de interface têm o mesmo significado que os de uma declaração de propriedade em uma classe (§15.7).

Os acessadores de uma declaração de propriedade de interface correspondem aos acessadores de uma declaração de propriedade de classe (§15.7.3), exceto que o accessor_body deve ser sempre um ponto-e-vírgula. Assim, os acessadores simplesmente indicam se a propriedade é leitura-gravação, somente leitura ou somente gravação.

O tipo de propriedade de interface deve ser seguro para a saída se houver um acessor get e deve ser seguro para entrada se houver um acessor definido.

18.4.4 Eventos da interface

Os eventos da interface são declarados usando interface_event_declarations:

interface_event_declaration
    : attributes? 'new'? 'event' type identifier ';'
    ;

Os atributos, o tipo e o identificador de uma declaração de evento de interface têm o mesmo significado que os de uma declaração de evento em uma classe (§15.8).

O tipo de evento de interface deve ser seguro para entradas.

18.4.5 Indexadores de interface

Os indexadores de interface são declarados usando interface_indexer_declarations:

interface_indexer_declaration
    : attributes? 'new'? type 'this' '[' parameter_list ']'
      '{' interface_accessors '}'
    | attributes? 'new'? ref_kind type 'this' '[' parameter_list ']'
      '{' ref_interface_accessor '}'
    ;

Os atributos, tipo e parameter_list de uma declaração de indexador de interface têm o mesmo significado que os de uma declaração de indexador em uma classe (§15.9).

Os acessadores de uma declaração de indexador de interface correspondem aos acessadores de uma declaração de indexador de classe (§15.9), exceto que o accessor_body deve ser sempre um ponto-e-vírgula. Assim, os acessadores simplesmente indicam se o indexador é leitura-gravação, somente leitura ou somente gravação.

Todos os tipos de parâmetros de um indexador de interface devem ser seguros para entradas (§18.2.3.2). Além disso, quaisquer tipos de parâmetros de saída ou de referência devem também ser seguros para a produção.

Nota: Os parâmetros de saída devem ser seguros para entrada devido a restrições comuns de implementação. Nota final

O tipo de indexador de interface deve ser seguro para a saída se existir um acessor get e deve ser seguro para entradas se existir um acessor definido.

18.4.6 Acesso de membros da interface

Os membros da interface são acessados através de acesso de membro (§12.8.7) e acesso de indexador (§12.8.12.3) expressões da forma I.M e I[A], onde I é um tipo de interface, M é um método, propriedade ou evento desse tipo de interface e A é uma lista de argumentos de indexador.

Para interfaces que são estritamente de herança única (cada interface na cadeia de herança tem exatamente zero ou uma interface base direta), os efeitos da pesquisa de membros (§12.5), invocação de método (§12.8.10.2) e acesso ao indexador (§12.8.12.3) são exatamente os mesmos que para classes e estruturas: Mais membros derivados ocultam menos membros derivados com o mesmo nome ou assinatura. No entanto, para interfaces de herança múltipla, ambiguidades podem ocorrer quando duas ou mais interfaces base não relacionadas declaram membros com o mesmo nome ou assinatura. Esta subcláusula apresenta vários exemplos, alguns dos quais conduzem a ambiguidades e outros não. Em todos os casos, moldes explícitos podem ser usados para resolver as ambiguidades.

Exemplo: No código a seguir

interface IList
{
    int Count { get; set; }
}

interface ICounter
{
    void Count(int i);
}

interface IListCounter : IList, ICounter {}

class C
{
    void Test(IListCounter x)
    {
        x.Count(1);             // Error
        x.Count = 1;            // Error
        ((IList)x).Count = 1;   // Ok, invokes IList.Count.set
        ((ICounter)x).Count(1); // Ok, invokes ICounter.Count
    }
}

As duas primeiras instruções causam erros em tempo de compilação porque a pesquisa de membros (§12.5) de Count in IListCounter é ambígua. Como ilustrado pelo exemplo, a ambiguidade é resolvida através da transmissão para o tipo de x interface base apropriado. Essas versões não têm custos de tempo de execução — elas consistem apenas em visualizar a instância como um tipo menos derivado em tempo de compilação.

Exemplo final

Exemplo: No código a seguir

interface IInteger
{
    void Add(int i);
}

interface IDouble
{
    void Add(double d);
}

interface INumber : IInteger, IDouble {}

class C
{
    void Test(INumber n)
    {
        n.Add(1);             // Invokes IInteger.Add
        n.Add(1.0);           // Only IDouble.Add is applicable
        ((IInteger)n).Add(1); // Only IInteger.Add is a candidate
        ((IDouble)n).Add(1);  // Only IDouble.Add is a candidate
    }
}

A invocação n.Add(1) seleciona IInteger.Add aplicando as regras de resolução de sobrecarga do §12.6.4. Da mesma forma, a invocação n.Add(1.0) seleciona IDouble.Add. Quando moldes explícitos são inseridos, há apenas um método candidato e, portanto, nenhuma ambiguidade.

Exemplo final

Exemplo: No código a seguir

interface IBase
{
    void F(int i);
}

interface ILeft : IBase
{
    new void F(int i);
}

interface IRight : IBase
{
    void G();
}

interface IDerived : ILeft, IRight {}

class A
{
    void Test(IDerived d)
    {
        d.F(1);           // Invokes ILeft.F
        ((IBase)d).F(1);  // Invokes IBase.F
        ((ILeft)d).F(1);  // Invokes ILeft.F
        ((IRight)d).F(1); // Invokes IBase.F
    }
}

o IBase.F membro é escondido pelo ILeft.F membro. A invocação d.F(1) seleciona, portanto, , mesmo ILeft.F que pareça não estar oculta no caminho de acesso que leva através IBase.Fdo IRight.

A regra intuitiva para se esconder em interfaces de herança múltipla é simplesmente esta: se um membro estiver oculto em qualquer caminho de acesso, ele estará oculto em todos os caminhos de acesso. Como o caminho de acesso de IDerived para ILeft para IBase se oculta, IBase.Fo membro também está oculto no caminho de acesso de IDerived para IRight .IBase

Exemplo final

18.5 Nomes de membros qualificados da interface

Um membro da interface às vezes é referido por seu nome de membro qualificado da interface. O nome qualificado de um membro da interface consiste no nome da interface na qual o membro é declarado, seguido por um ponto, seguido pelo nome do membro. O nome qualificado de um membro faz referência à interface na qual o membro é declarado.

Exemplo: Dadas as declarações

interface IControl
{
    void Paint();
}

interface ITextBox : IControl
{
    void SetText(string text);
}

o nome qualificado de Paint is IControl.Paint e o nome qualificado de SetText é ITextBox.SetText. No exemplo acima, não é possível referir-se a Paint .ITextBox.Paint

Exemplo final

Quando uma interface faz parte de um namespace, um nome de membro qualificado da interface pode incluir o nome do namespace.

Exemplo:

namespace System
{
    public interface ICloneable
    {
        object Clone();
    }
}

Dentro do System namespace, ambos ICloneable.Clone e System.ICloneable.Clone são nomes de membros qualificados da interface para o Clone método.

Exemplo final

18.6 Implementações de interface

18.6.1 Generalidades

As interfaces podem ser implementadas por classes e structs. Para indicar que uma classe ou struct implementa diretamente uma interface, a interface é incluída na lista de classes base da classe ou struct.

Exemplo:

interface ICloneable
{
    object Clone();
}

interface IComparable
{
    int CompareTo(object other);
}

class ListEntry : ICloneable, IComparable
{
    public object Clone() {...}    
    public int CompareTo(object other) {...}
}

Exemplo final

Uma classe ou struct que implementa diretamente uma interface também implementa implicitamente todas as interfaces base da interface. Isso é verdadeiro mesmo se a classe ou struct não listar explicitamente todas as interfaces base na lista de classes base.

Exemplo:

interface IControl
{
    void Paint();
}

interface ITextBox : IControl
{
    void SetText(string text);
}

class TextBox : ITextBox
{
    public void Paint() {...}
    public void SetText(string text) {...}
}

Aqui, a classe TextBox implementa ambos e IControlITextBox.

Exemplo final

Quando uma classe C implementa diretamente uma interface, todas as classes derivadas de C também implementam a interface implicitamente.

As interfaces de base especificadas numa declaração de classe podem ser construídas como tipos de interface (§8.4, §18.2).

Exemplo: O código a seguir ilustra como uma classe pode implementar tipos de interface construídos:

class C<U, V> {}
interface I1<V> {}
class D : C<string, int>, I1<string> {}
class E<T> : C<int, T>, I1<T> {}

Exemplo final

As interfaces de base de uma declaração de classe genérica devem satisfazer a regra de unicidade descrita no ponto 18.6.3.

18.6.2 Implementações explícitas de membros da interface

Para fins de implementação de interfaces, uma classe ou struct pode declarar implementações explícitas de membros da interface. Uma implementação explícita de membro da interface é um método, propriedade, evento ou declaração de indexador que faz referência a um nome de membro qualificado da interface.

Exemplo:

interface IList<T>
{
    T[] GetElements();
}

interface IDictionary<K, V>
{
    V this[K key] { get; }
    void Add(K key, V value);
}

class List<T> : IList<T>, IDictionary<int, T>
{
    public T[] GetElements() {...}
    T IDictionary<int, T>.this[int index] {...}
    void IDictionary<int, T>.Add(int index, T value) {...}
}

Aqui IDictionary<int,T>.this e IDictionary<int,T>.Add são implementações explícitas de membros da interface.

Exemplo final

Exemplo: Em alguns casos, o nome de um membro da interface pode não ser apropriado para a classe de implementação, caso em que o membro da interface pode ser implementado usando a implementação explícita do membro da interface. Uma classe implementando uma abstração de arquivo, por exemplo, provavelmente implementaria uma Close função de membro que tem o efeito de liberar o recurso de arquivo e implementaria o método da interface usando a DisposeIDisposable implementação explícita de membro da interface:

interface IDisposable
{
    void Dispose();
}

class MyFile : IDisposable
{
    void IDisposable.Dispose() => Close();

    public void Close()
    {
        // Do what's necessary to close the file
        System.GC.SuppressFinalize(this);
    }
}

Exemplo final

Não é possível acessar uma implementação explícita de membro da interface por meio de seu nome de membro qualificado da interface em uma chamada de método, acesso à propriedade, acesso a eventos ou acesso ao indexador. Uma implementação explícita de membro da interface só pode ser acessada por meio de uma instância de interface e, nesse caso, é referenciada simplesmente por seu nome de membro.

É um erro em tempo de compilação para uma implementação explícita de membro da interface incluir quaisquer modificadores (§15.6) diferentes de extern ou async.

É um erro em tempo de compilação para uma implementação de método de interface explícita para incluir type_parameter_constraints_clauses. As restrições para uma implementação genérica do método de interface explícita são herdadas do método de interface.

Nota: As implementações explícitas de membros da interface têm características de acessibilidade diferentes dos outros membros. Como as implementações explícitas de membro da interface nunca são acessíveis por meio de um nome de membro de interface qualificado em uma invocação de método ou um acesso de propriedade, elas são, de certa forma, privadas. No entanto, uma vez que podem ser acedidos através da interface, são, de certa forma, também tão públicos como a interface em que são declarados. As implementações explícitas de membros da interface servem a dois propósitos principais:

  • Como as implementações explícitas de membro da interface não são acessíveis por meio de instâncias de classe ou struct, elas permitem que as implementações de interface sejam excluídas da interface pública de uma classe ou struct. Isso é particularmente útil quando uma classe ou struct implementa uma interface interna que não é de interesse para um consumidor dessa classe ou struct.
  • Implementações explícitas de membros da interface permitem a desambiguação de membros da interface com a mesma assinatura. Sem implementações explícitas de membros da interface, seria impossível para uma classe ou struct ter implementações diferentes de membros da interface com a mesma assinatura e tipo de retorno, como seria impossível para uma classe ou struct ter qualquer implementação de membros da interface com a mesma assinatura, mas com tipos de retorno diferentes.

Nota final

Para que uma implementação explícita de membro da interface seja válida, a classe ou struct deve nomear uma interface em sua lista de classes base que contenha um membro cujo nome de membro de interface qualificado, tipo, número de parâmetros de tipo e tipos de parâmetros correspondam exatamente aos da implementação explícita de membro da interface. Se um membro da função de interface tiver uma matriz de parâmetros, o parâmetro correspondente de uma implementação de membro de interface explícita associada é permitido, mas não necessário, para ter o params modificador. Se o membro da função de interface não tiver uma matriz de parâmetros, uma implementação de membro de interface explícita associada não deve ter uma matriz de parâmetros.

Exemplo: Assim, na seguinte classe

class Shape : ICloneable
{
    object ICloneable.Clone() {...}
    int IComparable.CompareTo(object other) {...} // invalid
}

A declaração de resultados em um erro em tempo de IComparable.CompareTo compilação porque IComparable não está listada na lista de classes base de Shape e não é uma interface base de ICloneable. Do mesmo modo, nas declarações

class Shape : ICloneable
{
    object ICloneable.Clone() {...}
}

class Ellipse : Shape
{
    object ICloneable.Clone() {...} // invalid
}

A declaração de in ICloneable.Clone resulta em um erro em tempo de Ellipse compilação porque ICloneable não está listada explicitamente na lista de classes base de Ellipse.

Exemplo final

O nome de membro qualificado de uma implementação explícita de membro da interface deve fazer referência à interface na qual o membro foi declarado.

Exemplo: Assim, nas declarações

interface IControl
{
    void Paint();
}

interface ITextBox : IControl
{
    void SetText(string text);
}

class TextBox : ITextBox
{
    void IControl.Paint() {...}
    void ITextBox.SetText(string text) {...}
}

a implementação explícita do membro da interface do Paint deve ser escrita como IControl.Paint, não ITextBox.Paint.

Exemplo final

18.6.3 Singularidade das interfaces implementadas

As interfaces implementadas por uma declaração genérica de tipo devem permanecer únicas para todos os tipos construídos possíveis. Sem esta regra, seria impossível determinar o método correto para chamar certos tipos construídos.

Exemplo: Suponha que uma declaração de classe genérica tenha permissão para ser escrita da seguinte maneira:

interface I<T>
{
    void F();
}

class X<U ,V> : I<U>, I<V> // Error: I<U> and I<V> conflict
{
    void I<U>.F() {...}
    void I<V>.F() {...}
}

Se isso fosse permitido, seria impossível determinar qual código executar no seguinte caso:

I<int> x = new X<int, int>();
x.F();

Exemplo final

Para determinar se a lista de interfaces de uma declaração de tipo genérica é válida, as seguintes etapas são executadas:

  • Seja L a lista de interfaces especificadas diretamente em uma classe genérica, struct ou declaração Cde interface.
  • Adicione a L qualquer interface base das interfaces já em L.
  • Remova todas as duplicatas do L.
  • Se qualquer possível tipo construído criado a partir de C , após os argumentos de tipo serem substituídos em L, fazer com que duas interfaces em L sejam idênticas, então a declaração de C é inválida. As declarações de restrição não são consideradas ao determinar todos os tipos construídos possíveis.

Nota: Na declaração X de classe acima, a lista L de l<U> interfaces consiste em e I<V>. A declaração é inválida porque qualquer tipo construído com U e V sendo o mesmo tipo faria com que essas duas interfaces fossem tipos idênticos. Nota final

É possível que interfaces especificadas em diferentes níveis de herança unifiquem:

interface I<T>
{
    void F();
}

class Base<U> : I<U>
{
    void I<U>.F() {...}
}

class Derived<U, V> : Base<U>, I<V> // Ok
{
    void I<V>.F() {...}
}

Este código é válido mesmo que Derived<U,V> implemente ambos e I<U>I<V> . O código

I<int> x = new Derived<int, int>();
x.F();

invoca o método em Derived, uma vez que Derived<int,int>' efetivamente reimplementa I<int> (§18.6.7).

18.6.4 Aplicação de métodos genéricos

Quando um método genérico implementa implicitamente um método de interface, as restrições dadas para cada parâmetro de tipo de método devem ser equivalentes em ambas as declarações (depois de quaisquer parâmetros de tipo de interface serem substituídos pelos argumentos de tipo adequados), em que os parâmetros de tipo de método são identificados por posições ordinais, da esquerda para a direita.

Exemplo: No código a seguir:

interface I<X, Y, Z>
{
    void F<T>(T t) where T : X;
    void G<T>(T t) where T : Y;
    void H<T>(T t) where T : Z;
}

class C : I<object, C, string>
{
    public void F<T>(T t) {...}                  // Ok
    public void G<T>(T t) where T : C {...}      // Ok
    public void H<T>(T t) where T : string {...} // Error
}

o método C.F<T> implementa I<object,C,string>.F<T>implicitamente . Neste caso, não é necessário (nem permitido) especificar a restriçãoC.F<T>, T: object uma vez que object é uma restrição implícita em todos os parâmetros de tipo. O método C.G<T> implementa implicitamente porque as restrições correspondem às da interface, depois que os parâmetros de tipo de I<object,C,string>.G<T> interface são substituídos pelos argumentos de tipo correspondentes. A restrição para o método C.H<T> é um erro porque os tipos selados (string neste caso) não podem ser usados como restrições. Omitir a restrição também seria um erro, uma vez que as restrições de implementações de método de interface implícitas são necessárias para corresponder. Assim, é impossível implementar I<object,C,string>.H<T>implicitamente . Este método de interface só pode ser implementado usando uma implementação explícita de membro da interface:

class C : I<object, C, string>
{
    ...
    public void H<U>(U u) where U : class {...}

    void I<object, C, string>.H<T>(T t)
    {
        string s = t; // Ok
        H<T>(t);
    }
}

Nesse caso, a implementação explícita do membro da interface invoca um método público com restrições estritamente mais fracas. A atribuição de t a s é válida, uma vez que T herda uma restrição de T: string, mesmo que essa restrição não seja expressável no código-fonte. Exemplo final

Nota: Quando um método genérico implementa explicitamente um método de interface, não são permitidas restrições no método de implementação (§15.7.1, §18.6.2). Nota final

18.6.5 Mapeamento de interface

Uma classe ou struct deve fornecer implementações de todos os membros das interfaces listados na lista de classes base da classe ou struct. O processo de localização de implementações de membros da interface em uma classe ou struct de implementação é conhecido como mapeamento de interface.

O mapeamento de interface para uma classe ou struct C localiza uma implementação para cada membro de cada interface especificada na lista de classes base de C. A implementação de um determinado membro I.Mda interface, onde I é a interface na qual o membro M é declarado, é determinada examinando cada classe ou struct S, começando com C e repetindo para cada classe base sucessiva de C, até que uma correspondência seja localizada:

  • Se S contiver uma declaração de uma implementação explícita de membro da interface que corresponda e IM, então esse membro é a implementação de I.M.
  • Caso contrário, se S contiver uma declaração de um membro público não estático que corresponda ao M, então esse membro será a implementação do I.M. Se mais de um membro corresponder, não será especificado qual membro é a implementação do I.M. Esta situação só pode ocorrer se S for um tipo construído onde os dois membros declarados no tipo genérico têm assinaturas diferentes, mas os argumentos de tipo tornam suas assinaturas idênticas.

Um erro em tempo de compilação ocorre se as implementações não puderem ser localizadas para todos os membros de todas as interfaces especificadas na lista de classes base de C. Os membros de uma interface incluem os membros que são herdados das interfaces base.

Considera-se que os membros de um tipo de interface construído têm quaisquer parâmetros de tipo substituídos pelos argumentos de tipo correspondentes, conforme especificado no §15.3.3.

Exemplo: Por exemplo, dada a declaração de interface genérica:

interface I<T>
{
    T F(int x, T[,] y);
    T this[int y] { get; }
}

A interface I<string[]> construída tem os membros:

string[] F(int x, string[,][] y);
string[] this[int y] { get; }

Exemplo final

Para fins de mapeamento de interface, um membro A de classe ou struct corresponde a um membro B da interface quando:

  • A e B são métodos, e as listas de nomes, tipos e parâmetros de A e B são idênticas.
  • Ae B são propriedades, o nome e o tipo de e A são idênticos, e B tem os mesmos acessadores que A (B tem permissão para ter acessadores adicionais se não for uma implementação explícita de membro da A interface).
  • A e B são eventos, e o nome e o tipo de A e B são idênticos.
  • Ae B são indexadores, o tipo e as listas de parâmetros de e A são idênticos, e B tem os mesmos acessadores que A (B tem permissão para ter acessadores adicionais se não for uma implementação explícita de membro da A interface).

Implicações notáveis do algoritmo de mapeamento de interface são:

  • As implementações explícitas de membros da interface têm precedência sobre outros membros na mesma classe ou estrutura ao determinar a classe ou membro struct que implementa um membro da interface.
  • Nem membros não-públicos nem estáticos participam do mapeamento de interface.

Exemplo: No código a seguir

interface ICloneable
{
    object Clone();
}

class C : ICloneable
{
    object ICloneable.Clone() {...}
    public object Clone() {...}
}

o ICloneable.Clone membro de torna-se a implementação de em 'ICloneable' porque implementações explícitas de membros da CClone interface têm precedência sobre outros membros.

Exemplo final

Se uma classe ou struct implementa duas ou mais interfaces contendo um membro com o mesmo nome, tipo e tipos de parâmetro, é possível mapear cada um desses membros da interface em uma única classe ou membro struct.

Exemplo:

interface IControl
{
    void Paint();
}

interface IForm
{
    void Paint();
}

class Page : IControl, IForm
{
    public void Paint() {...}
}

Aqui, os Paint métodos de ambos IControl e IForm são mapeados para o Paint método em Page. É claro que também é possível ter implementações de membros de interface explícitos separados para os dois métodos.

Exemplo final

Se uma classe ou struct implementa uma interface que contém membros ocultos, então alguns membros podem precisar ser implementados por meio de implementações explícitas de membros da interface.

Exemplo:

interface IBase
{
    int P { get; }
}

interface IDerived : IBase
{
    new int P();
}

Uma implementação desta interface exigiria pelo menos uma implementação explícita de membro da interface e assumiria uma das seguintes formas

class C1 : IDerived
{
    int IBase.P { get; }
    int IDerived.P() {...}
}
class C2 : IDerived
{
    public int P { get; }
    int IDerived.P() {...}
}
class C3 : IDerived
{
    int IBase.P { get; }
    public int P() {...}
}

Exemplo final

Quando uma classe implementa várias interfaces que têm a mesma interface base, pode haver apenas uma implementação da interface base.

Exemplo: No código a seguir

interface IControl
{
    void Paint();
}

interface ITextBox : IControl
{
    void SetText(string text);
}

interface IListBox : IControl
{
    void SetItems(string[] items);
}

class ComboBox : IControl, ITextBox, IListBox
{
    void IControl.Paint() {...}
    void ITextBox.SetText(string text) {...}
    void IListBox.SetItems(string[] items) {...}
}

Não é possível ter implementações separadas para o IControl nomeado na lista de classes base, o IControl herdado por ITextBoxe o IControl herdado por IListBox. Na verdade, não há noção de uma identidade separada para essas interfaces. Em vez disso, as implementações de ITextBoxe IListBox compartilham a mesma implementação de IControl, e ComboBox é simplesmente considerado para implementar três interfaces, IControl, ITextBox, e IListBox.

Exemplo final

Os membros de uma classe base participam do mapeamento de interface.

Exemplo: No código a seguir

interface Interface1
{
    void F();
}

class Class1
{
    public void F() {}
    public void G() {}
}

class Class2 : Class1, Interface1
{
    public new void G() {}
}

O método F em Class1 é usado na Class2's implementação de Interface1.

Exemplo final

18.6.6 Herança da implementação da interface

Uma classe herda todas as implementações de interface fornecidas por suas classes base.

Sem reimplementar explicitamente uma interface, uma classe derivada não pode, de forma alguma, alterar os mapeamentos de interface que herda de suas classes base.

Exemplo: Nas declarações

interface IControl
{
    void Paint();
}

class Control : IControl
{
    public void Paint() {...}
}

class TextBox : Control
{
    public new void Paint() {...}
}

O Paint método em TextBox oculta o Paint método em Control, mas não altera o mapeamento de para , Control.Painte as chamadas para IControl.Paint instâncias de classe e instâncias de Paint interface terão os seguintes efeitos

Control c = new Control();
TextBox t = new TextBox();
IControl ic = c;
IControl it = t;
c.Paint();  // invokes Control.Paint();
t.Paint();  // invokes TextBox.Paint();
ic.Paint(); // invokes Control.Paint();
it.Paint(); // invokes Control.Paint();

Exemplo final

No entanto, quando um método de interface é mapeado em um método virtual em uma classe, é possível que as classes derivadas substituam o método virtual e alterem a implementação da interface.

Exemplo: Reescrever as declarações acima para

interface IControl
{
    void Paint();
}

class Control : IControl
{
    public virtual void Paint() {...}
}

class TextBox : Control
{
    public override void Paint() {...}
}

Os seguintes efeitos serão agora observados

Control c = new Control();
TextBox t = new TextBox();
IControl ic = c;
IControl it = t;
c.Paint();  // invokes Control.Paint();
t.Paint();  // invokes TextBox.Paint();
ic.Paint(); // invokes Control.Paint();
it.Paint(); // invokes TextBox.Paint();

Exemplo final

Como as implementações explícitas de membros da interface não podem ser declaradas virtuais, não é possível substituir uma implementação explícita de membro da interface. No entanto, é perfeitamente válido para uma implementação de membro de interface explícita chamar outro método, e esse outro método pode ser declarado virtual para permitir que as classes derivadas o substituam.

Exemplo:

interface IControl
{
    void Paint();
}

class Control : IControl
{
    void IControl.Paint() { PaintControl(); }
    protected virtual void PaintControl() {...}
}

class TextBox : Control
{
    protected override void PaintControl() {...}
}

Aqui, as classes derivadas de Control podem especializar a implementação de IControl.Paint substituindo o PaintControl método.

Exemplo final

18.6.7 Reimplementação da interface

Uma classe que herda uma implementação de interface tem permissão para reimplementar a interface incluindo-a na lista de classes base.

Uma reimplementação de uma interface segue exatamente as mesmas regras de mapeamento de interface que uma implementação inicial de uma interface. Assim, o mapeamento de interface herdado não tem qualquer efeito sobre o mapeamento de interface estabelecido para a re-implementação da interface.

Exemplo: Nas declarações

interface IControl
{
    void Paint();
}

class Control : IControl
{
    void IControl.Paint() {...}
}

class MyControl : Control, IControl
{
    public void Paint() {}
}

O fato de que Control o MAPS IControl.Paint ON Control.IControl.Paint não afeta a reimplementação no MyControl, que mapeia IControl.Paint para MyControl.Paint.

Exemplo final

As declarações de membro público herdadas e as declarações de membro de interface explícitas herdadas participam do processo de mapeamento de interface para interfaces reimplementadas.

Exemplo:

interface IMethods
{
    void F();
    void G();
    void H();
    void I();
}

class Base : IMethods
{
    void IMethods.F() {}
    void IMethods.G() {}
    public void H() {}
    public void I() {}
}

class Derived : Base, IMethods
{
    public void F() {}
    void IMethods.H() {}
}

Aqui, a implementação de em IMethods mapeia os métodos de Derived interface em Derived.F, Base.IMethods.G, Derived.IMethods.H, e Base.I.

Exemplo final

Quando uma classe implementa uma interface, ela implicitamente também implementa todas as interfaces base dessa interface. Da mesma forma, uma re-implementação de uma interface também é implicitamente uma re-implementação de todas as interfaces base da interface.

Exemplo:

interface IBase
{
    void F();
}

interface IDerived : IBase
{
    void G();
}

class C : IDerived
{
    void IBase.F() {...}
    void IDerived.G() {...}
}

class D : C, IDerived
{
    public void F() {...}
    public void G() {...}
}

Aqui, a re-implementação de IDerived também re-implementa IBase, mapeando IBase.F em D.F.

Exemplo final

18.6.8 Classes abstratas e interfaces

Como uma classe não abstrata, uma classe abstrata deve fornecer implementações de todos os membros das interfaces listados na lista de classes base da classe. No entanto, uma classe abstrata tem permissão para mapear métodos de interface em métodos abstratos.

Exemplo:

interface IMethods
{
    void F();
    void G();
}

abstract class C : IMethods
{
    public abstract void F();
    public abstract void G();
    }

Aqui, a implementação de IMethods mapas F e G em métodos abstratos, que devem ser substituídos em classes não abstratas que derivam de C.

Exemplo final

Implementações explícitas de membros da interface não podem ser abstratas, mas implementações explícitas de membros da interface são naturalmente permitidas para chamar métodos abstratos.

Exemplo:

interface IMethods
{
    void F();
    void G();
}

abstract class C: IMethods
{
    void IMethods.F() { FF(); }
    void IMethods.G() { GG(); }
    protected abstract void FF();
    protected abstract void GG();
}

Aqui, classes não abstratas que derivam de seriam obrigadas C a substituir FF e GG, fornecendo assim a implementação real de IMethods.

Exemplo final