Qual è il ragionamento alla base della convenzione di denominazione del prefisso "I" per le interfacce in .NET?

Question

Qual è il ragionamento alla base della convenzione di denominazione del prefisso "I" per le interfacce in .NET?

#1 da (11 voti)
#2 da (6 voti)
#3 da (2 voti)

10

So che la convenzione "I" è in circolazione dalla COM, ma non ho mai capito perché non è stata riconsiderata come ogni altra convenzione di denominazione prima di .NET.

Consumo saggio, l'unica cosa che separa un'interfaccia da, diciamo, una classe astratta, è che possono essere moltiplicati per ereditarietà. Ma tutto dopo Visual Studio 2003 ha mostrato le firme dei tipi in tooltip, quindi è inutile come tutte le altre notazioni ungheresi che sono state scartate.

Ho anche pensato che potrebbe essere così che tu possa avere un'implementazione di base dell'interfaccia con lo stesso nome, ad es. Message eredita IMessage , ma la maggior parte delle librerie .NET è andata per aggiungere la parola "Base" alla fine (ad esempio System.Collections.ReadOnlyCollectionBase ) invece - e questo ha più senso della semantica.

L'interoperabilità COM sembra essere un'altra ragione possibile - ma non è come se le classi wrapper che genera fossero perfettamente idiomatiche .NET, quindi dubito che quella fosse una considerazione estetica.

In uno dei miei progetti più recenti ho completamente rinunciato alla convenzione, e mi sento bene. C'è qualcosa che mi manca?

naming .net

posta Rei Miyasaka 15.09.2011 - 08:20

fonte

3 risposte

Leggi altre domande sui tag naming .net

Stima dei costi del software [chiusa] Qual è una buona alternativa alla variabile name per un linguaggio che ha solo riferimenti o etichette immutabili?

score 11 · Answer 1

Penso che questo potrebbe essere l'unico caso in cui i prefissi sono utili.

Classi e interfacce hanno davvero una semantica diversa, e poiché entrambi sono tipi, sono facili da mescolare.
Quando vedo una dichiarazione di classe, posso immediatamente capire che cosa deriva da e cosa implementa :

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

Sarebbe più difficile capire se la definizione fosse simile a

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

E come chiameresti ListClass ? Chiaramente non è solo ListBase perché è utilizzabile da solo.
Quindi, o dobbiamo risolvere un problema che abbiamo appena inventato, o adattare un prefisso che separa le classi dalle interfacce, che è ciò che i progettisti di .NET Framework hanno fatto.

Inoltre, personalmente lo trovo utile quando posso dire dalla firma del metodo che funziona con le interfacce.

public void PrintLines (IEnumerable<string> source)

È come un segnale alla mia testa: hey, Posso implementarlo! Posso alimentare il metodo che corrisponde al contratto.

Ovviamente si può sostenere che non è così importante, ma questa è una di quelle piccole cose che ne fanno il valore per me. È particolarmente utile quando si scrive un sacco di codice con contenitori IoC quando si lavora costantemente con le interfacce e si ha bisogno di distinguere facilmente tra i due.

A proposito, non solo le interfacce hanno prefissi nel sistema di tipo .NET. Non dimenticare i parametri di tipo generico:

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

Questa è un'altra situazione in cui è estremamente utile essere in grado di distinguere tra classi e un altro tipo di tipi.

score 6 · Answer 2

6

Non penso che manchi qualcosa, è solo un'abitudine storica.

Sono d'accordo con te e ho anche lasciato cadere l''io' su un paio di progetti di piccole e medie dimensioni senza alcun effetto dannoso.

risposta data 15.09.2011 - 08:58

fonte

score 2 · Answer 3

Penso che l'unica ragione, secondo le Linee guida per la denominazione di Microsoft in merito a interfacce e classi , sia che, a volte hai conflitti tra il nome dell'interfaccia e la classe che lo implementa. Questo risale al fatto che le interfacce sono in realtà lo scheletro, non la carne, e la classe implementatore è in effetti la carne (realizzando il progetto). Quindi, IAnimal sta solo descrivendo ciò che un animale dovrebbe avere , mentre Animal può dirti ciò che ha .

Tuttavia, personalmente sono completamente d'accordo con te sul fatto che potremmo semplicemente utilizzare Animal Base per l'interfaccia e Animale per la classe.

D'altra parte, a volte due cose sono in conflitto così tanto che una squadra decide di fornire una convenzione per prevenire ulteriori conflitti, nonostante le decisioni già prese. Ad esempio, in ASP.NET MVC, sia Viste parziali e Layout (pagine mastro), sono come normali Visualizza , mentre servono diverse funzionalità. Pertanto Microsoft, nonostante enfatizzi di non utilizzare il carattere di sottolineatura nella denominazione, suggerisce di sottolineare Layout e Viste parziali con un carattere di sottolineatura.