Почему префикс C # имен интерфейсов с «I»

Question

В чем смысл этого соглашения об именах?

Я не вижу никакой пользы. Дополнительный префикс просто загрязняет API.

Мое мышление согласуется с ответом Конрада на этот связанный вопрос ; выбранный ответ , о котором я чаще всего спрашиваю здесь.

Answer 1

Это делает его легко идентифицируемым как интерфейс.

Answer 2

TL; DR - извлечение interface IFoo из class Foo является обычным явлением в отделении SOLID, особенно для целей модульного тестирования

Для меня двойное соглашение класса Foo, реализующего интерфейс IFoo (особенно если оба находятся в одной сборке), выражает определенное намерение, что:

• Связь по зависимости Foo всегда должна быть непрямой через соответствующий интерфейс IFoo (и, вероятно, будет внедрена через контейнер IoC)
• Первоначальный проект IFoo является проприетарным, не подлежащим повторному использованию интерфейсом, специально предназначенным для того, чтобы классы, зависящие от Foo, могли макетировать эту зависимость во время модульного тестирования.
• Помимо вышесказанного, читателю не нужно выводить какой-либо дополнительный интеллект при проектировании интерфейса IFoo
• И наоборот, если на более позднем этапе потребуется несколько конкретных классов реализации IFoo, то надлежащий дизайн сегрегации интерфейса необходимо будет перестроить в иерархию.

Обоснование

Для того, чтобы иметь возможность макетировать или заглушать класс, общепринятая лучшая практика в модульном тестировании - разделять зависимости между классами только через интерфейсы. Эта развязка интерфейса будет также выполняться с классами, которые в противном случае никогда не имели бы требований к дизайну для полиморфизма (то есть существовала бы только одна такая реализация, если бы не было необходимости в модульном тестировании).

Как следствие, рефакторинг и повторное использование этих интерфейсов (например, Принцип разделения интерфейсов SOLID) не часто применяется к таким «поддельным» интерфейсам - часто есть 1: 1 корреляция между открытыми методами, свойствами и событиями класса 'mockable' (Foo) и его развязанным интерфейсом IFoo (аналогично автоматическим интерфейсам COM-эпохи в VB ).

Такие инструменты, как VS и Resharper, могут сделать извлечение таких открытых символов из класса в отдельный интерфейс тривиальным, как запоздалая мысль.

Кроме того, если учесть, что платформы Mocking, такие как Moq, позволяют определять реализации интерфейса «на лету» , нам не нужно тратить усилия на присвоение имени конкретному классу двойной реализации реализации.

Answer 3

Соглашения об именах дают вам возможность рассказать вам кое-что об объекте перед его использованием. Соглашения об именах широко использовались в течение многих лет, вплоть до того, что Фортран настаивал на том, что целочисленные значения были ограничены (если я правильно помню) именами переменных, такими как «i» и «j».

Нотация Hungariation перенесла соглашения об именах на совершенно новый уродливый уровень, который описывал тип переменной, независимо от того, был ли это указатель и т. Д. Многие из нас, которые подвергались воздействию большого количества кода с помощью венгерской нотации, развили нервные подергивания и словесные заикания.

Префикс имен интерфейсов с I - это сравнительно малоэффективный и безопасный способ идентификации этого объекта.

Answer 4

Это просто соглашение об именах, так что все будут знать, если это интерфейс или что-то еще, это не обязательно, ни компилятором, ни IDE, но все интерфейсы, которые я видел за всю свою жизнь, начинаются с буквы I

Answer 5

Со всеми аргументами о соглашениях об именах и присвоении имен переменных и методов, которые фактически описывают то, что они делают ... почему бы просто не назвать ваши интерфейсы (например, PetInterface, PlayerInterface и т. Д.) И покончить с префиксом Я "все вместе. Так что для того, чтобы вы набрали дополнительные 9 букв, по крайней мере «I» удаляется, и мы знаем, что это не класс, потому что он говорит «Interface».

Answer 6

Мне кажется традиционная конвенция из венгерской нотации. Руководство по именованию интерфейсов гласит «Префикс имен интерфейсов буквой I, чтобы указать, что тип является интерфейсом». Руководство по проектированию платформы также говорит: «СЛЕДУЕТ префиксировать имена интерфейсов буквой I, чтобы указать, что тип является интерфейсом».

Это просто соглашение по кодированию, так что трудно определить, хорошо это или плохо. Важными вещами является последовательность.

Answer 7

Скорее всего, это сделает его легко идентифицируемым в intellisense, поскольку все интерфейсы будут объединяться. Аналогично тому, как я добавляю префиксы ко всем моим элементам управления пользовательским интерфейсом с помощью btn, tb, lb. Когда пики intellisense во всем объединяются в одну простую группу.

Answer 8

Во-первых, я считаю, что префикс I, а затем описание неверен, поскольку это означает, что реализации могут иметь более короткое имя. IList (intf) -> Список. Это анти-паттерн, так как мы все знаем, что мы должны использовать intf и, возможно, только конкретные типы при создании. Не сердитесь на меня, это обобщение, но предпосылка исчисляется лишь редко. Имя реализации должно описывать, как он реализует intf или что он делает. Подумайте о intf List, LinkedList, который реализует List, используя связанный список. Кому интересно, если это дольше, так как мы должны использовать List большую часть времени. Если у нас есть класс, реализующий много intf, мы, вероятно, не должны включать все intf как тени для реального назначения класса. В случае, если что-то удалено без intf, имеет смысл. Например, ppl называет меня по имени, а не Person, Sibling, разработчик и т. Д., Используя мое имя, является лучшим наиболее описательным именем. Я полагаю, если класс подразумевает простой intf, тогда назовите его Default Intf, что делает его обязательным, это реализация Intf по умолчанию. Имена классов должны быть в конце понятными для человека и почти короткой фразой, описывающей их назначение. Префиксные коды и т. Д. Не очень хороши, поскольку мы общаемся со словами, а не с кодами. Компьютеры понимают, как называются классы, и почему остается то, что мы называем вещи так, чтобы имена помогали нам и нашим коллегам.