Objetos Começam Com A Letra I

Interfaces em C#: por que tudo começa com I e o que isso significa na prática

Se você trabalha com Cou linguagens do ecossistema .NET há algum tempo, já percebeu que interface se escreve com I maiúsculo na frente. Isso não é convenção opcional. É algo que o time da Microsoft padronizou no livro de estilo da linguagem, e a maioria dos desenvolvedores leva a sério porque gera consistência no código. Interface serve para definir contratos. Classe implementa o contrato. A nomenclatura ajuda a identificar rapidamente qual é qual quando você está navegando em uma solução grande. A nomenclatura interface prefixada com I é parte do padrão de naming do .NET. Não é uma regra do compilador, mas é tão enraizada que bibliotecas oficiais, geradores de código e ferramentas de refatoração assumem essa convenção automaticamente. Quando você digita IEnum no IntelliSense, o filtro já espera um nome de interface, não de classe. Isso economiza tempo de busca em projetos com milhares de arquivos. O problema real não é saber a convenção. O problema é quando ela colide com requisitos existentes ou com times que misturam padrões de outras linguagens. Em projetos grandes, a falta de uniformidade gera confusão de leitura. Uma interface chamada ICustomerData aparece junto com outra chamada CustomerInterface, e o desenvolvedor novo gasta tempo tentando entender se são coisas diferentes ou apenas estilos variados do mesmo conceito.

Eu passei por isso em um projeto de migração. A equipe anterior tinha usado nomes como IOperacao, ProcessadorDeDados e IFilaDeExecucao. Alguns com I, outros sem. No meio do refatoramento, um methodo genérico que eu estava escrevendo precisava aceitar apenas tipos que fossem interface, e o compilador não fazia distinção pelo nome. A solução foi usar o qualificador interface na restrição de tipo genérico, assim: T interface. Isso resolve a ambiguidade sem depender de convenção de nomenclatura. A restrição verifica no nível de tipo, não de string. Outro ponto que iniciantes costumam errar é achar que interface é sinônimo de herança múltipla. Em C#, uma classe não herda de interface da mesma forma que herda de classe base. Interface define comportamento que a classe deve implementar, mas não carrega estado. Se você precisa de estado compartilhado, use classe abstrata. Interface com propriedades que têm getter e setter sem backing field é um cheiro de código. Pode funcionar, mas geralmente indica que o design deveria ser revisado. Há também a armadilha das interfaces em cascata. Você cria IRepositorio, depois IRepositorioGenerico, depois IRepositorioFinanceiroGenericoComCache. O resultado é uma hierarquia de nomes que ninguém consegue lembrar, e o tempo de compilação aumenta porque o compilador precisa resolver cada camada. A solução mais simples é cortar a profundidade. Uma interface clara com métodos bem definidos vale mais do que três níveis de especialização prematura.

Performance também entra nessa conversa, ainda que de forma indireta. Chamada de método através de interface tem um custo de dispatch, ainda que pequeno. Em loops internos que rodam milhões de vezes, esse custo acumula. Eu medei isso em um contexto de processamento de lote com mais de 50 mil execuções por segundo, e a diferença entre chamar diretamente e chamar via interface foi da ordem de microssegundos por chamada. Não é desastroso, mas em sistemas sensíveis a latência, você precisa saber onde está usando interface e onde poderia usar implementação direta ou classe base. Testes unitários se beneficiam muito do padrão interface. Mockar uma interface é trivial com frameworks como Moq ou NSubstitute. Você define os métodos que precisa, configura o comportamento esperado e testa o código que depende daquela dependência isoladamente. Isso é tão comum que praticamente todo guia de boas práticas em .NET recomenda injetar dependências via construtor usando interfaces, não classes concretas. O risco é o excesso. Injetar interface em tudo pode criar um volume absurdo de contratos pequenos demais para justificar o overhead. Se você tem vinte interfaces para um serviço que na prática nunca vai ser substituído em teste, talvez a simplicidade de usar a classe direta seja mais produtiva. O equilíbrio depende do cenário, e não de dogma.

Se você quer aprender mais sobre o tema, pode consultar a documentação oficial da Microsoft sobre convenções de nomeação em Ce os guias de estilo do .NET. Os links estão disponíveis no site oficial da plataforma. O conteúdo é atualizado periodicamente, então sempre vale verificar a versão mais recente antes de aplicar as recomendações em projetos novos.