Это вопрос? Итак, насколько велика грех - не использовать это соглашение при разработке проекта С#? Это соглашение широко используется в библиотеке классов .NET. Тем не менее, я не поклонник, по меньшей мере, не только по астральным причинам, но я не думаю, что он вносит какой-либо вклад. Например, IPSec является интерфейсом PSec? Является ли IIOPConnection интерфейсом IOPConnection, я обычно перехожу к определению, чтобы все равно узнать.
Библиотеки классов Java существовали без этого в течение многих лет, я не чувствую, что когда-либо пытался прочитать код без него. Кроме того, должен ли интерфейс быть не самым примитивным описанием? Я имею в виду IList <T> как интерфейс для List <T> в С#, не лучше ли иметь List <T> и LinkedList <T> или ArrayList <T> или даже CopyOnWriteArrayList <T> ? Классы описывают реализацию? Я думаю, что я получаю больше информации здесь, чем от List <T> в С#.
Разница между Java и С# заключается в том, что Java позволяет вам легко отличить, реализуете ли вы интерфейс или расширяете класс, так как он имеет соответствующие ключевые слова implements и extends.
Поскольку С# имеет только :, чтобы выразить реализацию или расширение, я рекомендую следовать стандарту и поставить я перед именем интерфейса.
Плохая практика и в моем опыте. Причины, по которым ваши дополнительные:
С уважением, в вашем посте вы только рассматриваете свои потребности (я, я, я), а не потребности читателей вашего кода. Если вы являетесь магазином с одним человеком, то достаточно справедливым, но если ваш код когда-нибудь будет прочитан другими, тогда подумайте, что они будут ожидать, что интерфейсы будут иметь префикс я - это так, как в .NET. слишком много людей привыкли к этому сейчас.
Кроме того, это поможет, если вы используете более читаемые имена для классов. Что такое PSec? Как я могу определить, является ли IPSec интерфейсом, когда я даже не могу сказать, что такое PSec? Если вместо этого PSec был переименован, например, PersonalSecurity, то IPersonalSecurity гораздо более вероятно будет интерфейсом.
Использование я для интерфейсов противоречит всей точке интерфейса imo, что это соединитель, в который вы можете подключить различные конкретные реализации к зависимостям.
Объекту, который использует базу данных, нужен DataStore, а не IDataStore, и он должен быть настроен на то, получает ли он DatabaseDataStore или FileSystemDataStore или что-то в нем подключенное (или MockDataStore для тестирования).
Прочитайте этот и продолжайте движение. Если вы используете Java, следуйте соглашениям об именах Java.
Я думаю, что основная причина I-префикса заключается не в том, что те, кто его использует, могут видеть в нем интерфейс, но тот, кто реализует/выводит из существующих классов и интерфейсов, может легче видеть его интерфейс или базовый класс.
Другим преимуществом является то, что он предотвращает такие глупые вещи, как (если моя память Java служит мне правильно):
List foo = new List(); // Why does it fail?
Третье преимущество - рефакторинг. Если вы перемещаете объекты и читаете код, вы можете увидеть, где вы забыли код по интерфейсу. "Метод, принимающий что-то с типом, не префикс I? Исправьте его!".
Я использовал его даже в Java и нашел его весьма полезным, но это всегда зависит от рекомендаций для вашей компании/команды. Следуйте за ними, как бы глупо они ни казались, когда-нибудь вы будете счастливы, что они существуют.
Спросите себя: если моя IDE может дать мне некоторый намек на текст (например, другой цвет, подчеркивание, курсив...), что тип был интерфейсом, я бы все еще беспокоился?
Похоже, вы называете типы, подобные этому, так что вы можете сказать от имени что-то о частях определения, отличных от имени.
Я бы сказал, что не соблюдение этого соглашения приведет вас к черту .NET. Это соглашение, которое почти так же важно для меня, как использование self в методах экземпляра в Python.
Лучшие практики переопределяют соглашение, по-моему, на мой взгляд. Хотя мне лично не нравится это соглашение, использование его не противоречит лучшей практике, которая существует дольше, чем я об этом думаю.
Я бы посмотрел на это больше с точки зрения того, как это делают другие люди в этом случае. Поскольку 99% общего мира будут предваряться "я", это достаточно хорошо, чтобы сохранить эту лучшую практику. Если вам нужно привлечь подрядчика или нового разработчика, вы должны быть в состоянии сосредоточиться на коде и не должны объяснять/защищать выбранные вами варианты.
Это было достаточно долго и достаточно укоренилось, что я не ожидаю, что он изменится в моей жизни. Это всего лишь один из тех "неписаных правил", которые лучше определяются как "неписаная лучшая практика", которая, вероятно, переживет меня.
Это не грех как таковой, лучший опыт. Это делает вещи намного более удобочитаемыми. Кроме того, подумайте об этом. IMyClass - это интерфейс к MyClass. Это просто имеет смысл и прекращает ненужную путаницу. Также помните синтаксис : и implements/extends. Наконец, вы можете обойти все это, просто проверив всплывающие подсказки/перейдите в VS, но для чистой читаемости стандарт, на мой взгляд, важен.
Не то, что я знаю, но я уверен, что они существуют.
Не видели, но я уверен, что они существуют.
Посмотрите на BCL. В библиотеках базового класса у вас есть IList < > , IQueryable, IDisposable. Если вы не добавили его с помощью "я", как люди узнают его как интерфейс, отличный от определения?
В любом случае, только мои 2 цента
существуют соглашения, чтобы помочь всем нам. Если есть шанс, что другой разработчик .net будет работать с вами, тогда да, следуйте за соглашением.
Одна идея состоит в том, что за частью "I" может следовать глагол, указывающий, какие классы реализуют интерфейс; например, ISaveXmlData, образуя приятное человеческое имя.
Ключевая вещь - согласованность - так долго вы придерживаетесь того, чтобы иметь префикс для всех интерфейсов или вообще ничего, это вопрос предпочтения.
Я использую префикс я для интерфейсов на работе, поскольку существующий код уже использует его для соглашения об именах для каждого интерфейса. Я нахожу более интуитивно понятным, чтобы быстро определить, реализует ли класс интерфейс или другой класс, просто просматривая префикс я в имени базового класса.
С другой стороны, некоторые из старых проектов на работе не используют это соглашение об именах, и это делает код немного менее читаемым, но может быть просто, что я использую префикс.
Вы можете выбрать все имена в своей программе, как вам нравится, но это хорошая идея для хранения именования конверсий, если вы не будете только читать программу.
Использование интерфейсов хорош не только при разработке собственных классов и интерфейсов. В некоторых случаях вы делаете другие акценты в своей программе, в которой вы используете интерфейсы. Например, вы можете написать код типа
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 class ( но с OleDbDataReader, OracleDataReader, OdbcDataReader и т.д.). С другой стороны, ваша программа будет работать как можно быстрее.
Обновлено (на основе вопросов от комментариев):
Преимущество, как я уже писал, состоит в том, что вы отделите некоторые части кода, которые работают с IDataReader. Например, вы можете определить delegate T ReadRowFromDataReader<T> (IDataReader dr, ...) и использовать его внутри блока while (dr.Read ()). Таким образом, вы пишете код, который более общий, как код, работающий с SqlDataReader напрямую. Внутри блока while (dr.Read ()) вы вызываете rowReader (dr, ...). Ваши различные реализации строк считывания кода данных могут быть помещены в метод с сигнатурой ReadRowFromDataReader<T> rowReader и поместить его в качестве фактического параметра.
Таким образом, вы можете написать более независимый код, работающий с базой данных. В первый раз, вероятно, использование общего делегата выглядит немного сложным, но весь код будет очень легко читать. Я хочу еще раз подчеркнуть, что вы действительно получаете некоторые преимущества использования интерфейсов в этом случае, только если вы отделите некоторые части кода от другого метода. Если вы не разделяете код, единственным преимуществом, которое вы получаете, является: вы получаете части кода, которые написаны более независимыми, и вы могли бы копировать и проделывать эти части в другой программе.
Использование имен, начинающихся с "I", упрощает понимание того, что теперь мы работаем с чем-то более общим, как с одним классом.
Я не вижу веских оснований для этого. "Расширяет" vs 'tools' уже говорит вам, имеете ли вы дело с классом или интерфейсом в тех случаях, когда это действительно имеет значение. Во всех остальных случаях вся идея состоит в том, что вам все равно.
По моему мнению, самая большая причина, по которой "я" часто префиксируется, заключается в том, что IDE для Java (Eclipse) и .NET(V Studio) не дают абсолютно ясного представления о том, что класс, на который вы смотрите, на самом деле является интерфейсом, Браузер пакетов в eclipse показывает один и тот же значок, пока вы не разберете файл класса, а шрифт объявления интерфейса не отличается от класса.
Пример будет, если я наберу:
ISomeInterface s = factory.create();
ISomeInterface должен по крайней мере иметь какую-то модификацию шрифта, чтобы показать, что его интерфейс (например, курсив или подчеркивание).
Другая большая причина в мире Java заключается в том, что префикс для людей с "я" заключается в том, что в Eclipse упрощается делать "Ctrl-Shift-R" и искать только интерфейсы.
Это важно в мире Java/ Spring, где вам нужны интерфейсы в качестве ваших соавторов, если вы планируете использовать любую магию AOP или некоторые другие динамические прокси.
Чем у вас неприятный выбор либо префикса вашего интерфейса с "я" , либо суффикса вашего класса реализации с "Impl", как ListImpl. Я ненавижу суффикс классов с помощью "Impl", чтобы интерфейс и бетон отличались именем и префиксом префикса "I".
В общем, я стараюсь избегать создания большого количества интерфейсов.
В моем собственном коде я бы никогда не префикс "I". Я только даю несколько причин, почему люди делают это, что для старой последовательности кода.
Я придерживаюсь соглашения только потому, что должен, если я должен использовать любые интерфейсы в BCL и поддерживать согласованность.
Мне тоже не нравится это соглашение.