Was ist der Grund für die Namenskonvention "I" für Schnittstellen in .NET?

Ich weiß, dass es die "I" -Konvention seit COM gibt, aber ich habe nie verstanden, warum sie nicht wie jede andere Namenskonvention vor .NET überdacht wurde.

In Bezug auf den Verbrauch ist das einzige, was eine Schnittstelle beispielsweise von einer abstrakten Klasse unterscheidet, dass sie mehrfach vererbt werden können. Aber alles nach Visual Studio 2003 hat Typensignaturen in QuickInfos angezeigt, sodass es genauso nutzlos ist wie alle anderen ungarischen Notationen, die verworfen wurden.

Ich dachte auch, dass es so sein könnte, dass Sie eine grundlegende Implementierung der Schnittstelle mit demselben Namen haben können, z. B. Messageerben IMessage, aber die meisten .NET-Bibliotheken haben System.Collections.ReadOnlyCollectionBasestattdessen das Wort "Base" am Ende hinzugefügt (z. B. ) - und das macht semantischer Sinn.

COM-Interop scheint ein weiterer möglicher Grund zu sein - aber es ist nicht so, dass die von ihm generierten Wrapper-Klassen vollkommen idiomatisch .NET sind, daher bezweifle ich, dass dies eine ästhetische Überlegung war.

In einem meiner neueren Projekte habe ich ganz auf die Konvention verzichtet und es fühlt sich gut an. Fehlt mir etwas?

Ich denke, dies ist möglicherweise der einzige Fall, in dem Präfixe nützlich sind.

Klassen und Schnittstellen haben wirklich unterschiedliche Semantiken und sind, da beide Typen sind, leicht zu verwechseln.
Wenn ich eine Klassendeklaration sehe, kann ich sofort erkennen, woraus sie stammt und was sie implementiert :

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

Es wäre schwieriger zu verstehen, wenn die Definition so aussehen würde

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

Und wie würden Sie anrufen ListClass? Natürlich nicht nur, ListBaseweil es für sich allein verwendbar ist.
Wir müssen also entweder ein Problem lösen, das wir gerade erfunden haben, oder ein Präfix anpassen, das Klassen von Schnittstellen trennt, wie es .NET Framework-Designer getan haben.

Ich persönlich finde es auch nützlich, wenn ich anhand der Methodensignatur erkennen kann, dass es mit Schnittstellen funktioniert.

public void PrintLines (IEnumerable<string> source)

Es ist wie ein Signal an meinen Kopf: Hey, ich kann das umsetzen! Ich kann die Methode füttern, was auch immer dem Vertrag entspricht.

Natürlich kann man argumentieren, dass es nicht so wichtig ist, aber dies ist eines dieser kleinen Dinge, die das Präfix für mich wert machen. Dies ist besonders nützlich, wenn Sie viel Code mit IoC-Containern schreiben, wenn Sie ständig mit Schnittstellen arbeiten und leicht zwischen beiden unterscheiden müssen.

Übrigens haben nicht nur die Schnittstellen Präfixe im System vom Typ .NET. Vergessen Sie nicht die generischen Typparameter:

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

Dies ist eine andere Situation, in der es äußerst nützlich ist, zwischen Klassen und anderen Arten von Typen unterscheiden zu können.

Ich glaube nicht, dass du etwas vermisst, es ist nur eine historische Gewohnheit.

Ich stimme Ihnen ebenfalls zu und habe das Ich bei einigen kleinen bis mittleren Projekten ohne nachteilige Auswirkungen fallen gelassen.

Ich denke, der einzige Grund gemäß den Namensrichtlinien von Microsoft für Schnittstellen und Klassen ist, dass manchmal Konflikte zwischen dem Namen der Schnittstelle und der Klasse auftreten, die diese implementiert. Dies geht auf die Tatsache zurück, dass Schnittstellen tatsächlich das Skelett und nicht das Fleisch sind und die Implementiererklasse tatsächlich das Fleisch ist (Realisierung der Blaupause). Daher beschreibt IAnimal nur, was ein Tier haben sollte , während Animal Ihnen sagen kann, was es hat .

Ich persönlich stimme Ihnen jedoch in dem Punkt vollkommen zu, dass wir einfach Animal Base für die Benutzeroberfläche und Animal für die Klasse verwenden könnten .

Andererseits widersprechen sich manchmal zwei Dinge so sehr, dass ein Team beschließt, trotz bereits getroffener Entscheidungen eine Konvention vorzusehen, um weitere Konflikte zu verhindern. In ASP.NET MVC sind beispielsweise sowohl Teilansichten als auch Layouts (Masterseiten) wie eine normale Ansicht , bieten jedoch unterschiedliche Funktionen. Daher schlägt Microsoft trotz der Betonung, bei der Benennung keinen Unterstrich zu verwenden, vor, Layouts und Teilansichten mit einem Unterstrich zu unterstreichen.