Для использования 'меня' снабжают префиксом для интерфейсов или не к

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

Разница между Java и C # заключается в том, что Java позволяет легко различать, реализуете ли вы интерфейс или расширяете класс, поскольку у него есть соответствующие ключевые слова реализует и расширяет .

Поскольку C # имеет только : для выражения реализации или расширения, я рекомендую следовать стандарту и ставить I перед именем интерфейса.

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

• Вся цель интерфейсов состоит в том, чтобы абстрагироваться от деталей реализации. Поэтому не имеет значения, вызываете ли вы метод с помощью IParam или Param.
• Разработанные инструменты имеют собственные возможности отмечать интерфейсы значком.
• Если ваш глаз ищет в среде IDE имя, наиболее важной частью является начало строки. Может быть, ваши классы отсортированы по алфавиту, и теперь у вас есть блок с похожими именами, все начинающиеся с I ... вместе. Они похожи друг на друга, но было бы полезно их легко различать. Использование приставки I. Эргономично.
• Еще больше раздражает: ImplList, ImplThat, AFoo для абстрактного Foo, AImplFooBar для абстрактного Foo, который реализует Bar? SSomething как Singleton или SMath для статического класса? Прекрати! :)

Я бы сказал, что несоблюдение этого соглашения приведет вас в ад .NET. Это соглашение почти так же важно для меня, как использование self в методах экземпляра в Python.

Посмотрите на BCL. В библиотеках базовых классов у вас есть IList <>, IQueryable, IDisposable. Если вы не добавите перед ним букву «I», как люди узнают, что это интерфейс, отличный от перехода к определению?

В любом случае, только мои 2 цента

На мой взгляд, основная причина того, что "I" часто ставится префиксом, заключается в том, что IDE для Java (Eclipse) и .NET (V Studio) не очень ясно дают понять, что класс, на который вы смотрите, на самом деле является интерфейсом. . Обозреватель пакетов в eclipse показывает тот же значок, пока вы не развернете файл класса, а шрифт объявления интерфейса не будет отличаться от шрифта класса.

Примером может быть, если я наберу:

ISomeInterface s = factory.create();

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

Другая важная причина, по которой в мире Java люди используют префикс с «I», заключается в том, что в Eclipse проще использовать «Ctrl-Shift-R» и искать только интерфейсы.

Это важно в мире Java / Spring, где вам нужны интерфейсы в качестве ваших соавторов, если вы планируете использовать какую-либо магию АОП или некоторые другие динамические прокси.

Затем у вас есть неприятный выбор: либо добавить к интерфейсу префикс «I», либо добавить к классу реализации суффикс «Impl», например ListImpl. Я ненавижу суффикс классов с «Impl», чтобы интерфейс и конкретный объект различались по имени, и префикс префикса «I».

В общем, я стараюсь избегать большого количества интерфейсов.

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

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

В данном случае я бы посмотрел на это с точки зрения того, как это делают другие люди. Поскольку 99% обычного мира будут начинать с «я», этого достаточно, чтобы сохранить эту передовую практику. Если вам нужно привлечь подрядчика или нанять нового разработчика, вы должны иметь возможность сосредоточиться на коде и вам не придется объяснять / защищать свой выбор.

Он существует достаточно давно и достаточно прочно укоренился, поэтому я не ожидаю, что он изменится в течение моей жизни. Это просто одно из тех «неписаных правил», лучше определенное как «неписаные передовые методы», которые, вероятно, меня переживут.

1. Это не грех как таковой, это лучшая практика . Это в целом делает вещи более читаемыми. Также подумайте об этом. IMyClass - это интерфейс к MyClass . Это просто имеет смысл и избавляет от ненужной путаницы. Также помните синтаксис : по сравнению с реализует / расширяет . Наконец, вы можете обойти все это, просто проверив всплывающие подсказки / перейдите в VS, но для чистой читаемости, на мой взгляд, важен стандарт.

2. Не знаю, но я уверен, что они существуют.

3. Не видел, но уверен, что они есть.

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

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

SqlDataReader dr = cmd.ExecuteReader (CommandBehavior.SequentialAccess);
if (!dr.HasRows) {
    // ...
}
while (dr.Read ()) {
    string name = dr.GetString (0);
    // ...
}

или

IDataReader dr = cmd.ExecuteReader (CommandBehavior.SequentialAccess);
if (!dr.HasRows) {
    // ...
}
while (dr.Read ()) {
    string name = dr.GetString (0);
    // ...
}

, последний будет выглядеть так же, но если вы используете IDataReader вместо SqlDataReader , вам будет проще поместите некоторые части, которые работают с dr, в метод, который работает не только с классом SqlDataReader (но и с OleDbDataReader , OracleDataReader , OdbcDataReader так далее). С другой стороны, ваша программа продолжает работать так же быстро, как и раньше.

Обновлено (на основе вопросов из комментариев):

Как я писал ранее, преимущество в том, что вы разделите некоторые части своего кода , которые работают с IDataReader . Например, вы можете определить делегат T ReadRowFromDataReader (IDataReader dr, ...) и использовать его внутри блока while (dr.Read ()) . Таким образом, вы пишете код, который является более общим, как код, работающий напрямую с SqlDataReader . Внутри блока while (dr.Read ()) вы вызываете rowReader (dr, ...) . Ваши различные реализации кода чтения строк данных можно поместить в метод с сигнатурой ReadRowFromDataReader rowReader и поместить его как фактический параметр.

Таким образом, вы можете писать более независимый код, работающий с базой данных. В первый раз, вероятно, использование универсального делегата выглядит немного сложным, но весь код будет действительно легко читать. Хочу еще раз подчеркнуть, что действительно некоторые преимущества использования интерфейсов в этом случае вы получите только в том случае, если вы разделите некоторые части кода в другом методе . Если вы не разделяете код, единственное преимущество, которое вы получаете: вы получаете части кода, которые написаны более независимыми, и вы можете легче копировать и изменять эти части в другой программе.

Использование имен, начинающихся с «I», упрощает понимание того, что теперь мы работаем с чем-то более общим, как с одним классом.

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

Еще одно преимущество состоит в том, что он предотвращает такие глупые вещи, как (если моя память Java меня правильно обслуживает):

List foo = new List(); // Why does it fail?

Третье преимущество - это рефакторинг. Если вы перемещаетесь по объектам и читаете код, вы можете увидеть, где вы забыли код за интерфейсом. «Метод, принимающий что-то с типом без префикса I? Исправить!».

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

Прочтите это и двигайтесь дальше. Если вы используете Java, следуйте соглашениям об именах Java.

Одна идея состоит в том, что за частью «I» может следовать глагол, указывающий, какие классы, реализующие интерфейс, делают; например ISaveXmlData , образуя красивое имя на человеческом языке.

С уважением, в вашем сообщении вы рассматриваете только ваши потребности (я, я, я), а не потребности читатели вашего кода. Если вы работаете с одним человеком, то это будет справедливо, но если ваш код когда-либо прочитают другие, то имейте в виду, что они будут ожидать, что интерфейсы будут иметь префикс I - именно так оно и есть в .Net, и слишком многие люди привыкли к тому, что сейчас это изменится.

Также было бы полезно, если бы вы использовали более читаемые имена для классов. Что такое PSec? Как я могу определить, является ли IPSec интерфейсом, если я даже не могу сказать, что такое PSec? Если вместо этого PSec был переименован, например, в PersonalSecurity, то IPersonalSecurity, скорее всего, был бы интерфейсом.

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

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

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

Я не вижу никакой веской причины делать это. 'Extends' vs 'implements' уже говорит вам, имеете ли вы дело с классом или интерфейсом в тех случаях, когда это действительно важно. Во всех остальных случаях идея заключается в том, что вам все равно.

Использование I для интерфейсов противоречит всему смыслу интерфейса имо, что это соединитель, к которому вы можете подключать различные конкретные реализации для зависимостей.

Объект, использующий базу данных, нуждается в DataStore, а не в IDataStore, и это должно зависеть от конфигурации, подключать ли к нему DatabaseDataStore или FileSystemDataStore или что-то еще (или MockDataStore для тестирования).

Спросите себя: может ли моя IDE дать мне подсказку в тексте (например, другим цветом, подчеркиванием, курсивом ...), что тип был интерфейсом, я бы все еще беспокоился?

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

Я придерживаюсь конвенции только потому, что должен, если хочу использовать какие-либо интерфейсы в BCL и сохранить последовательность.

Мне тоже не нравится эта конвенция.