Які міркування, що стоять за умовою іменного префікса "I" для інтерфейсів у .NET?

Я знаю, що конвенція "Я" існує вже з часів COM, але я ніколи не розумів, чому вона не була переглянута, як і будь-яка інша конвенція про іменування раніше .NET має.

Єдине, що відокремлює інтерфейс від, скажімо, абстрактного класу, - це те, що вони можуть множитися у спадок. Але все після того, як Visual Studio 2003 показав підписи типів у підказках, тому це так само марно, як і всі інші угорські позначення, які були відкинуті.

Я також подумав, що це може бути так, що ви можете мати базову реалізацію інтерфейсу з тим же ім'ям, наприклад, Messageуспадковувати IMessage, але більшість бібліотек .NET пішли на додавання слова "Base" в кінці (наприклад System.Collections.ReadOnlyCollectionBase) замість цього - і це має більш смисловий сенс.

COM interop, здається, є ще однією можливою причиною - але це не так, якби класи, які він створює, абсолютно ідіоматичні. NET, тому я сумніваюся, що це було естетичним аспектом.

В одному з моїх нових проектів я повністю відмовився від конвенції, і це почувається просто чудово. Щось мені не вистачає?

Я думаю, що це, можливо, єдиний випадок, коли префікси корисні.

Класи та інтерфейси дійсно мають різну семантику, і тому що обидва - це типи, їх легко змішувати.
Коли я бачу декларацію класу, я можу враз сказати, з чого він походить і що він реалізує :

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

Було б важче зрозуміти, як таке визначення виглядало

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

А як би ти подзвонив ListClass? Зрозуміло, що це не тільки ListBaseтому, що воно є корисним самостійно.
Отже, ми або повинні вирішити проблему, яку ми тільки що винайшли, або адаптувати префікс, який відокремлює класи від інтерфейсів, що і зробили дизайнери .NET Framework.

Також особисто мені здається корисним, коли з підпису методу можу сказати, що він працює з інтерфейсами.

public void PrintLines (IEnumerable<string> source)

Це як сигнал в голову: ага, я можу це реалізувати! Я можу подати метод, що відповідає договору.

Звичайно, можна стверджувати, що це не так важливо, але це одна з тих дрібниць, які роблять префікс вартим для мене. Це особливо корисно при написанні великої кількості коду з контейнерами IoC, коли ви постійно працюєте з інтерфейсами і вам потрібно легко розмежувати їх.

До речі, не тільки в інтерфейсах є префікси в системі типу .NET. Не забувайте про параметри загального типу:

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

Це ще одна ситуація, коли надзвичайно корисно вміти розмежовувати класи та інші типи.

Я не думаю, що вам нічого не вистачає, це лише історична звичка.

Я погоджуюсь і з вами, і також я кинув "Я" на пару малих та середніх проектів без згубного ефекту.

Я думаю, що згідно з Посібниками з питань іменування Microsoft щодо інтерфейсів та класів , єдиною причиною є те, що іноді виникають конфлікти між назвою інтерфейсу та класом, що реалізує це. Це повертається до того, що інтерфейси - це насправді скелет, а не м'ясо, а клас реалізатора насправді є м'ясом (реалізуючи план). Таким чином, IAnimal описує лише те, що має мати тварина , тоді як Animal може сказати вам, що має .

Однак я особисто повністю з вами погоджуюся з тим, що ми могли просто використовувати Animal Base для інтерфейсу, а Animal - для класу.

З іншого боку, іноді дві речі настільки суперечать один одному, що команда вирішує створити конвенцію для запобігання подальшим конфліктам, незважаючи на вже прийняті рішення. Наприклад, в ASP.NET MVC як часткові перегляди, так і макети (головні сторінки) подібно до звичайного перегляду , хоча вони виконують різні функціональні можливості. Таким чином, Microsoft, незважаючи на те, що не використовувати підкреслення в іменуванні, пропонує підкреслити макети та часткові перегляди за допомогою підкреслення.