Зачем ставить перед именами интерфейсов C# букву «I»

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

Например, если у вас есть:

public class Dog : IPet, IMammal
{
    ....

Просто прочитав его, я могу с уверенностью предположить, что IPet и IMammal, вероятно, являются интерфейсами.

.NET CLR допускает наследование одного класса. Итак, если у меня есть базовый класс... я могу наследовать от него только один класс. Давайте изменим интерфейс IPet на базовый класс. Теперь наш пример становится

public class Dog : Pet, IMammal
{
    ....

Я наследую от класса Pet и реализую интерфейс IMmmal.

Если бы мы сделали то, что вы предлагаете, и убрали букву «Я», то получили бы вот это:

public class Dog : Pet, Mammal
{
    ....

От какого класса я наследую? Какой интерфейс я реализую? Это сбивает с толку, верно? (К вашему сведению... вы должны всегда ставить базовый класс первым, поэтому вы можете возразить по этому поводу... но если вы настаиваете на удалении буквы I из префикса имен интерфейсов, я сомневаюсь, что вы также следуете этой практике)

Как вы можете видеть, это соглашение об именах легко говорит мне многое о моем объекте, и мне не нужно исследовать его дальше. Я легко вижу, что я наследую, а что реализую.

Мне также это нравится, потому что я могу прочитать это как «I verb-behavior», как в «ICanSave» или «IDoDoubleEntry» и т. д.

Я думаю, что соглашение об именах IInterface глупо. Это пример венгерской нотации, и я присоединяюсь к школе мысли, которая презирает венгерскую нотацию. Если у вас есть интерфейс только с одной реализацией с таким же именем, рассмотрите возможность того, что это запах кода.

Тем не менее, я все еще использую его, потому что в этом случае IInterface рекомендуется Microsoft, а «стандарт лучше, чем лучше».

Почему это не функция синтаксической подсветки вместо венгерской нотации? Почему бы IDE просто не выделять курсивом идентификаторы, относящиеся к интерфейсам, если так важно различать классы и интерфейсы. Я ненавижу ставить «» или «m» перед полями, «C» перед классами и т. д. Хуже того, это побуждает программистов писать очень плохие API, такие как:

public class List : IList

вместо более разумного:

public class LinkedList : List
public class ArrayList : List
public class HashList : List

Даже авторы общих классов .NET попали в эту ловушку. Имя класса НИКОГДА не должно быть именем интерфейса, в котором удалена только буква «I». Имя класса всегда должно сообщать пользователю, чем класс отличается от других возможных реализаций интерфейса(ов). Я голосую за отказ от глупого «я» только по этой причине.

Кроме того, когда я использую intellisense, я хочу сгруппировать вещи по функциональным областям, а не по классу или интерфейсу. Я никогда не думаю: «Мне нужен интерфейс, а не класс». Я всегда думаю: «Мне нужно что-то, что делает X».

На самом деле я считаю полезным избегать конфликтов имен, я мог бы, например, создать конкретный класс с именем Fred, который реализует IFred.

Мне всегда казалось забавным использовать глаголы для поведенческих интерфейсов. Это отход от соглашения об именовании классов с использованием существительных, но позволяет классу «говорить» о своем поведении.

class Dog: IBark

Это не очень хорошо работает для структурных интерфейсов, таких как интерфейсы WCF, но нам не нужно все время развлекаться.

чтобы ответить на ваш вопрос, подумайте о I как о «орудиях». Итак...

class DogDataService : Dog, IDataService

этот класс обслуживания наследуется от Dog и реализует IDataService

Я все еще не совсем отвечаю на ваш вопрос, но I полезен, потому что вы получаете коллизии имен между пространством имен, классом и интерфейсом.

namespace DataService
interface DataService
class DataService: DataService

так что мы в конечном итоге с

namespace DataServices
interface IDataService
class DataService : IDataService

Я думаю, на самом деле, это соглашение о здравомыслии.

Если вы рассмотрите два «афоризма о передовом опыте»,

четкость превыше всего

и

шум — это плохо

между ними есть конфликт. Вопрос в том, когда ясность становится шумом?

Для меня более шумно (но одинаково четко) писать Person person = new PersonImpl(), чем IPerson person = new Person().

Либо так, либо добавить "Impl" в реализацию интерфейса (аргх). У меня нет проблем с «Я», это самое простое и понятное имя для интерфейса.

Конвенция «я» кажется старой условностью, которая не актуальна сегодня. Текущий редактор кода дает много информации об используемом типе, поэтому утверждать, что легче идентифицировать интерфейс, все равно что просить, чтобы пространство имен имело префикс «N», потому что вы хотите быть уверены, что не перепутаете его с конкретный класс (префикс с "C"?).

Конвенция не означает, что это хорошая конвенция. Иногда это просто потому, что люди используют его...

Возьмем, к примеру, генератор документации C#: ему все равно... если ваш интерфейс не имеет префикса "I", вы все равно увидите свой интерфейс в интерфейсной части вашей документации. Вы действительно думаете, что наличие префикса «I» для всех ваших интерфейсов в разделе интерфейса вашей документации является важной информацией и помогает вам лучше идентифицировать интерфейсы?

Необходимость различать интерфейс и класс на самом деле указывает на недостаток дизайна. В хорошо спроектированном приложении это всегда будет понятно. Подкласс всегда должен быть специализацией, а классы могут специализироваться только на одном предмете и никогда больше.

Класс должен иметь единственную причину существования. Ни в коем случае не следует помещать второстепенные роли в базовый класс. Например.:

public class XmlConfigurationFile : ConfigurationFile, IDisposable
{
}

public class YamlConfigurationFile : ConfigurationFile, IDisposable
{
}

Первый — это файл конфигурации, специализированный на Xml, второй — на Yaml. Они тоже одноразовые, но это не так важно. Вы не создали эти два класса из-за разных процессов утилизации.

Сравните это с:

public class XmlConfigurationFile : IDisposable, ConfigurationFile
{
}

Это скажет вам, что основная цель XmlConfigurationFile заключается в том, что он одноразовый. То, что вы можете использовать его как способ представления файлов конфигурации, хорошо, но второстепенно.

Проблема начинается, когда вы создаете классы, у которых есть несколько причин существования:

public class MyConfigurationFile : XmlConfigurationFile, YamlConfigurationFile
{
}

Даже если XmlConfigurationFile и YamlConfigurationFile были бы интерфейсами, это все равно указывает на плохой дизайн. Как ваш файл конфигурации может быть Xml и Yaml одновременно?

Если вы прочитаете приведенные примеры (здесь и в других местах), люди всегда изо всех сил пытаются найти хороший пример того, когда I-префикс имеет значение. Один из ответов здесь:

public class Dog : Pet, Mammal
{
}

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

public class Dog : Mammal, Pet
{
}

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

Я думаю, что ваши классы должны рассказать вам правильную историю об архитектуре и предметной области вашего приложения. Требование, чтобы интерфейс имел префикс «I», является техническим требованием и не поможет вам лучше рассказать историю вашего приложения.

Как только вы начнете писать небольшие, специализированные, одноцелевые классы, необходимость знать, реализует ли он или расширяет, автоматически исчезнет.

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

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

Венгерская нотация вывела соглашения об именах на совершенно новый уродливый уровень, который описывал тип переменной, независимо от того, была ли она указателем и т. д. У многих из нас, кто столкнулся с большим количеством кода с венгерской нотацией, начались нервные подергивания и словесные заикания.

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

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

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

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

Обоснование

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

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

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

Далее, если учесть, что фреймворки Mocking, такие как Moq, позволяют определять реализации интерфейса на -fly, нам не нужно тратить усилия на то, чтобы назвать конкретный класс двойной реализации теста.

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

Кажется, я придерживаюсь традиционного соглашения из венгерской нотации. В Руководстве по именованию интерфейсов говорится: "Префикс интерфейса имена с буквой I, чтобы указать, что тип является интерфейсом». В Руководстве по проектированию фреймворка также говорится: "Префиксировать имена интерфейсов буквой I, чтобы указать, что тип является интерфейсом».

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

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

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

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