Jakie jest uzasadnienie konwencji nazewnictwa „I” dla interfejsów w .NET?

Wiem, że konwencja „ja” istnieje od czasu COM, ale nigdy nie zrozumiałam, dlaczego nie została ponownie rozpatrzona, jak każda inna konwencja nazewnictwa przed .NET.

Jeśli chodzi o zużycie, jedyną rzeczą, która oddziela interfejs od, powiedzmy, klasy abstrakcyjnej, jest to, że można je wielokrotnie dziedziczyć. Ale wszystko po Visual Studio 2003 wyświetlało podpisy typu w etykietach narzędzi, więc jest tak bezużyteczne, jak wszystkie inne węgierskie notacje, które zostały odrzucone.

Pomyślałem również, że może to być tak, że możesz mieć podstawową implementację interfejsu o tej samej nazwie, np. MessageDziedziczenie IMessage, ale większość bibliotek .NET zdecydowała się na dodanie słowa „Base” na końcu (np. System.Collections.ReadOnlyCollectionBase) Zamiast - i to ma bardziej semantyczny sens.

Interoperacja COM wydaje się być kolejnym możliwym powodem - ale nie jest tak, że generowane przez nią klasy otoki są całkowicie idiomatyczne .NET, więc wątpię, aby była to uwaga estetyczna.

W jednym z moich nowych projektów całkowicie zapomniałem o konwencji i wydaje mi się, że jest w porządku. Czy czegoś brakuje?

Myślę, że może to być jedyny przypadek, w którym przydatne są prefiksy.

Klasy i interfejsy naprawdę mają inną semantykę, a ponieważ oba są typami, łatwo je mieszać.
Kiedy widzę deklarację klasy, mogę natychmiast stwierdzić, z czego się wywodzi i co implementuje :

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

Trudniej byłoby zrozumieć, jak wyglądała ta definicja

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

A jak byś zadzwonił ListClass? Oczywiście nie chodzi tylko o ListBaseto, że można go używać samodzielnie.
Musimy więc albo rozwiązać problem, który właśnie wynaleźliśmy, albo dostosować prefiks oddzielający klasy od interfejsów, co zrobili projektanci .NET Framework.

Ponadto osobiście uważam, że jest to przydatne, gdy mogę stwierdzić na podstawie podpisu metody, że działa z interfejsami.

public void PrintLines (IEnumerable<string> source)

To jak sygnał dla mojej głowy: hej, mogę to zaimplementować! Mogę nakarmić metodę, która pasuje do umowy.

Oczywiście można argumentować, że nie jest to takie ważne, ale jest to jedna z tych małych rzeczy, które sprawiają, że prefiks jest dla mnie tego wart. Jest to szczególnie przydatne, gdy piszesz dużo kodu z kontenerami IoC, gdy stale pracujesz z interfejsami i potrzebujesz łatwo rozróżnić oba.

Nawiasem mówiąc, nie tylko interfejsy mają prefiksy w systemie typu .NET. Nie zapomnij o ogólnych parametrach typu:

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

Jest to kolejna sytuacja, w której niezwykle przydatne jest rozróżnienie klas i innego rodzaju typów.

Nie sądzę, żebyś niczego nie przegapił, to tylko historyczny nawyk.

Zgadzam się również z tobą i porzuciłem „ja” w kilku małych i średnich projektach bez żadnego szkodliwego efektu.

Myślę, że jedynym powodem, zgodnie z wytycznymi Microsoft dotyczącymi nazewnictwa interfejsów i klas , jest to, że czasami masz konflikty między nazwą interfejsu a klasą, która go implementuje. Wraca to do faktu, że interfejsy to w rzeczywistości szkielet, a nie mięso, a klasa implementująca to tak naprawdę mięso (realizacja planu). Zatem IAnimal opisuje tylko to, co zwierzę powinno mieć , podczas gdy Zwierzę może ci powiedzieć, co ma .

Jednak osobiście całkowicie się z tobą zgadzam w kwestii, że moglibyśmy po prostu użyć Animal Base dla interfejsu i Animal dla klasy.

Z drugiej strony czasami dwie rzeczy są tak bardzo sprzeczne, że zespół decyduje się na konwencję, aby zapobiec dalszym konfliktom, pomimo już podjętych decyzji. Na przykład w programie ASP.NET MVC zarówno widoki częściowe , jak i układy (strony wzorcowe) są jak zwykły widok , a jednocześnie obsługują inne funkcje. Dlatego Microsoft, pomimo podkreślania, że ​​nie należy używać podkreślenia w nazewnictwie, sugeruje podkreślanie układów i widoków częściowych z podkreśleniem.