O conceito de interfaces à moda da linguagem Go, conhecido como tipagem estrutural, permite que um tipo T satisfaça uma interface I sem uma declaração explícita. Basta que os métodos públicos de T correspondam completamente aos requisitos da interface I. Esta abordagem, por vezes referida como "Duck Typing estático", tem seus defensores, mas também apresenta desafios significativos, especialmente quando comparada com a implementação explícita de interfaces encontrada em linguagens como C#.

Para entender melhor essas distinções, é fundamental definir o que realmente constitui uma interface. Além de ser um mero conjunto de assinaturas de membros (métodos, propriedades, etc.), uma interface estabelece um contrato de comportamento. Considere, por exemplo, uma interface hipotética para aceso a dados:

public interface IDataSource {
    int RecordCount { get; }
    bool IsCacheable { get; }
    void RetrieveChunk(byte[] buffer, int startIndex, int length);
}

Neste exemplo, IDataSource não apenas especifica que deve haver uma propriedade RecordCount, mas implicitamente sugere que a obtenção desse valor deve ser uma operação eficiente (por exemplo, O(1)). Da mesma forma, RetrieveChunk pode implicar que a operação é segura para o estado interno da fonte de dados e não causará efeitos colaterais indesejados. É essa garantia de comportamento e desempenho que permite que o código "orientado a interfaces" opere com confiança, selecionando algoritmos apropriados sem preocupações ocultas com a performence.

Essa perspectiva ajuda a explicar algumas decisões de design de bibliotecas, como a do .NET. Por exemplo, LinkedList<T>, apesar de ser uma coleção, não implementa IList<T>. Isso ocorre porque o acesso por índice (this[int index]) em uma lista ligada tem complexidade O(N), o que violaria a expectativa implícita de acesso rápido (O(1)) que a interface IList<T> geralmente impõe. Embora tanto List<T> quanto LinkedList<T> implementem ICollection<T>, esta última interface oferece um contrato mais genérico onde a performance de operações como Count é consistente, permitindo o uso seguro de um subconjunto de membros.

Em contraste, a biblioteca padrão do Java historicamente apresentou o List, que é implementado tanto por ArrayList quanto por LinkedList. O problema surge com o método get(int index): em ArrayList, é O(1), enquanto em LinkedList, é O(N). Se um método é projetado para operar em uma interface List e depende do acesso por índice para performance, ele pode sofrer uma degradação drástica ao receber uma LinkedList, transformando uma complexidade esperada de O(N) em O(N2) para certas operações. Essa inconsistência nos "contratos" de desempenho esvazia o propósito da programação orientada a interfaces.

O problema se agrava com a tipagem estrutural, onde a ausência de declaração explícita impede a distinção semântica. Considere as seguintes interfaces:

public interface IActivator {
    void Invoke();
}

public interface IExecutor {
    void Invoke();
}

Em inglês, "Invoke" pode significar tanto "ativar" quanto "executar". Se um objeto MyComponent possui um método Invoke() que serve para "ativar um sensor", mas é inadvertidamente usado onde se espera um IExecutor para "executar uma tarefa de processamento", a semântica é completamente distorcida. Em C#, a implementação explícita de interfaces oferece uma solução elegante:

public class DualFunctionComponent : IActivator, IExecutor {
    void IActivator.Invoke() {
        Console.WriteLine("Sensor ativado.");
    }

    void IExecutor.Invoke() {
        Console.WriteLine("Tarefa de processamento executada.");
    }
}

Aqui, um único componente pode implementar ambas as interfaces com o mesmo nome de método, mas com comportamentos e contextos distintos, eliminando a ambiguidade. Isso cnotrasta com abordagens que dependem puramente da assinatura, onde a intenção do design pode ser perdida.

É possível, em linguagens como C#, criar mecanismos para mimetizar a tipagem estrutural. Poderíamos desenvolver um utilitário que, em tempo de execução, converte dinamicamente um objeto para uma interface, desde que seus métodos correspondam. Por exemplo:

public class MyService {
    public void Start() { Console.WriteLine("Serviço iniciado."); }
}

public interface IRunnable {
    void Start();
}

// Em algum lugar do código, usaríamos um mecanismo dinâmico:
// MyService service = new MyService();
// IRunnable runnable = DynamicConverter.As<IRunnable>(service);
// runnable.Start(); // Isso funcionaria, mas sem o contrato explícito

Tal conversor exigiria introspecção em tempo de execução (usando técnicas como System.Reflection.Emit ou Expression Trees para gerar código dinamicamente) e, idealmente, algum tipo de validação em tempo de compilação ou antes da execução para evitar falhas inesperadas. No entanto, mesmo com essa funcionalidade, a escolha de usar um mecanismo explícito para tal conversão, em vez de depender de uma inferência automática, mantém o controle e a intenção do desenvolvedor no centro do design do sistema. A capacidade de escolher entre a tipagem estrutural dinâmica (se implementada) e a tipagem explícita tradicional permite que o desenvolvedor selecione a abordagem mais adequada para a clareza, robustez e manutenção do código.