Qual é o raciocínio por trás da convenção de nomenclatura de prefixo "I" para interfaces no .NET?

Eu sei que a convenção "I" existe desde COM, mas nunca entendi por que ela não foi reconsiderada como todas as outras convenções de nomenclatura anteriores ao .NET.

Em termos de consumo, a única coisa que separa uma interface de, digamos, uma classe abstrata, é que elas podem ser multiplicadas por herança. Mas tudo depois do Visual Studio 2003 mostrou assinaturas de tipo nas dicas de ferramentas, por isso é tão inútil quanto todas as outras notações húngaras que foram descartadas.

Eu também pensei que poderia ser para que você pudesse ter uma implementação básica da interface com o mesmo nome, por exemplo , Messageherdar IMessage, mas a maioria das bibliotecas do .NET optou por adicionar a palavra "Base" no final (por exemplo System.Collections.ReadOnlyCollectionBase) - e isso faz mais sentido semântico.

A interoperabilidade COM parece ser outro motivo possível - mas não é como se as classes de wrapper que ele gerasse fossem .NET perfeitamente idiomáticas, então duvido que essa tenha sido uma consideração estética.

Em um dos meus projetos mais recentes, perdi completamente a convenção e ela parece bem. Tem algo que estou perdendo?

Eu acho que esse pode ser o único caso em que prefixos são úteis.

Classes e interfaces realmente têm semânticas diferentes e, como ambos são tipos, são fáceis de misturar.
Quando vejo uma declaração de classe, posso dizer instantaneamente do que deriva e do que implementa :

public sealed class ActivityCollection : List<Activity>, 
    IList<Activity>, ICollection<Activity>, IEnumerable<Activity>, 
    IList, ICollection, IEnumerable

Seria mais difícil entender se a definição parecesse

public sealed class ActivityCollection : ListClass<Activity>, 
    List<Activity>, Collection<Activity>, Enumerable<Activity>, 
    List, Collection, Enumerable

E como você ligaria ListClass? Claramente, não é apenas ListBaseporque é utilizável por si só.
Portanto, precisamos resolver um problema que acabamos de inventar ou adaptar um prefixo que separa as classes das interfaces, o que os designers do .NET Framework fizeram.

Além disso, pessoalmente acho útil quando posso dizer pela assinatura do método que ele funciona com interfaces.

public void PrintLines (IEnumerable<string> source)

É como um sinal para minha cabeça: ei, eu posso implementar isso! Eu posso alimentar o método conforme o contrato.

É claro que se pode argumentar que não é tão importante, mas essa é uma daquelas pequenas coisas que fazem o prefixo valer a pena para mim. É especialmente útil ao escrever muito código com contêineres IoC quando você trabalha constantemente com interfaces e precisa diferenciar facilmente entre os dois.

A propósito, não apenas as interfaces têm prefixos no sistema de tipos .NET. Não se esqueça dos parâmetros de tipo genérico:

public delegate TResult Func<in T, out TResult>(
    T arg
)

Essa é outra situação em que é extremamente útil poder diferenciar classes e outro tipo de tipos.

Não acho que você esteja perdendo nada, é apenas um hábito histórico.

Também concordo com você e também reduzi o 'eu' em alguns projetos de pequeno a médio porte, sem efeito prejudicial.

Penso que o único motivo, de acordo com as Diretrizes de Nomenclatura da Microsoft sobre Interfaces e Classes , é que, às vezes, há conflitos entre o nome da interface e a classe que a implementa. Isso remonta ao fato de que as interfaces são, de fato, o esqueleto, não a carne, e a classe implementadora é de fato a carne (percebendo o modelo). Assim, o IAnimal está apenas descrevendo o que um animal deve ter , enquanto o Animal pode lhe dizer o que possui .

No entanto, eu pessoalmente concordo totalmente com você no ponto em que poderíamos simplesmente usar o Animal Base para a interface e o Animal para a classe.

Por outro lado, às vezes duas coisas são tão conflitantes que uma equipe decide oferecer uma convenção para evitar conflitos adicionais, apesar das decisões já tomadas. Por exemplo, no ASP.NET MVC, exibições parciais e layouts (páginas mestras), são exatamente como uma exibição normal , enquanto servem funcionalidades diferentes. Assim, apesar de enfatizar a não utilização de sublinhado na nomeação, a Microsoft sugere sublinhar layouts e vistas parciais com um sublinhado.