Существуют ли альтернативы ISomething/ISomething для интерфейсов?

Стандарт .NET для префикса имени интерфейса с I, кажется, становится широко распространенным и не ограничивается только .NET. Я столкнулся с большим количеством кода Java, который использует это соглашение (так что это не удивило бы меня, если бы Java использовала его до того, как С# сделал). Также Flex использует его и т.д. Помещение я в начале названия привносит венгерскую нотацию, и поэтому мне неудобно использовать его.

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

Ответ 1

Из книги "Руководства по дизайну каркаса":

Интерфейсы, представляющие корни иерархии (например, IList), также должны использовать существительные или существительные. Интерфейсы, представляющие возможности, должны использовать прилагательные и прилагательные фразы (например, IComparable, IFormattable).

Кроме того, из аннотаций по именованию интерфейса:

KRZYSZTOF CWALINA: один из немногих Используемые префиксы: "I" для интерфейсов (как в ICollection), но это для исторических причин. В ретроспективе я думаю, было бы лучше использовать регулярные имена типов. В большинстве разработчики приложений не заботятся о том, чтобы что-то является интерфейсом, а не абстрактный класс, например.

BRAD ABRAMS: С другой стороны, префикс "I" на интерфейсах является понятным признание влияния COM (и Java) в .NET Framework. COM популяризированный, даже институционализированный, нотация, с которой взаимодействуют интерфейсы с "I." Хотя мы обсуждали отклоняясь от этой исторической картины мы решили перенести так как многие наши пользователи уже знакомый с COM.

JEFFREY RICHTER: Лично мне нравится Префикс "I" , и я бы хотел, чтобы у нас было больше такие вещи. Маленький односимвольный префиксы имеют большой путь к сохранению код краткий и все же описательный. Насколько я сказал ранее, я использую префиксы для моего поля частного типа, потому что я нахожу это очень полезно.

BRENT RECTOR Примечание: это действительно другое применение Венгерская нотация (хотя одна без недостатки обозначений использовать в именах переменных).

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

Ответ 2

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

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

Одна небольшая точка данных: я работаю как с Java, так и с С# с достаточной суммой, и я регулярно обнаруживаю, что мне нужно проверить, какие типы на Java фактически являются интерфейсами, особенно в рамках коллекции..NET просто делает это простым. Может быть, это не беспокоит других людей, но это беспокоит меня.

+1 для IFoo от меня.

Ответ 3

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

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

/EDIT: Я хотел бы указать, что приведенные выше рассуждения побудили меня отказаться от префикса I для частных проектов. Однако, проверяя один из них на набор правил FxCop, я быстро вернулся к использованию I. Консистенция выигрывает здесь, хотя глупая консистенция - это хобгоблин маленьких умов.

Ответ 4

Все о стиле и читаемости. Префикс Интерфейсы с "I" - это просто соглашение об именах и руководство по стилю. Самим компиляторам было все равно.

Ответ 5

Стандарт кодирования для Symbian имеет интерфейсы (чистые абстрактные классы С++), обозначенные как M, а не I.

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

Ответ 6

Для .NET руководство по дизайну Microsoft Framework Design рекомендует это, и да, это очень стандартно. Я никогда не видел, чтобы это было сделано иначе, и создать новое соглашение могло бы только запутать людей.

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

Ответ 7

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

public class CustomerImpl implements Customer

Ответ 8

Вы попросили альтернативу, так вот вот я столкнулся:

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

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

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

Ответ 9

Мое основное предположение заключается в том, что самое главное - поддерживать читаемость в доменной части реализации. Поэтому:

Если у вас есть одно поведение и одна возможная реализация, просто не создавайте интерфейс:

открытый класс StackOverflowAnswerGenerator {}
Если у вас есть одно поведение и множество возможных реализаций, тогда нет проблем, и вы можете просто отказаться от "I" и иметь:

открытый интерфейс StackOverflowAnswerGenerator {}

открытый класс StupidStackOverflowAnswerGenerator: StackOverflowAnswerGenerator {}

открытый класс RandomStackOverflowAnswerGenerator: StackOverflowAnswerGenerator {}

открытый класс GoogleSearchStackoverflowAnswerGenerator: StackOverflowAnswerGenerator {}

//...
Реальная проблема возникает, когда у вас есть одно поведение и одна возможная реализация, но вам нужен интерфейс для описания его поведения (например, для удобного тестирования из-за соглашения в вашем проекте, используя некоторую библиотеку/фреймворк,...). Возможные решения, другие из префикса интерфейса:

a) Префикс или суффикс реализации (как указано в некоторых других ответах в этом разделе)

b) Используйте другое пространство имен для интерфейса:

пространство имен StackOverflowAnswerMachine.Interfaces { открытый интерфейс StackOverflowAnswerGenerator {} }

пространство имен StackOverflowAnswerMachine { Открытый класс StackOverflowAnswerGenerator: Interfaces.StackOverflowAnswerGenerator {} }

c) Используйте другое пространство имен для реализации:

пространство имен StackOverflowAnswerMachine { открытый интерфейс StackOverflowAnswerGenerator {} }

пространство имен StackOverflowAnswerMachine.Implementations { Открытый класс StackOverflowAnswerGenerator: StackOverflowAnswerMachine.StackOverflowAnswerGenerator {} }

В настоящее время я экспериментирую с последней возможностью. Обратите внимание, что в исходном файле реализации вы все равно можете использовать "StackOverflowAnswerMachine"; и имеют удобный доступ к объектам домена.

ОБНОВЛЕНИЕ: Хотя я все еще думаю, что последняя возможность - самая чистая, один недостаток заключается в том, что даже при использовании "StackOverflowAnswerMachine"; дает вам доступ ко всем объектам домена, которые вы должны префиксные интерфейсы домена, чтобы не путать их реализации. Это может показаться чем-то не очень удобным, но в чистом дизайне обычно класс не использует многие другие объекты домена, и в большинстве случаев вам нужно использовать префикс только в описании поля и списке параметров конструктора. Итак, это моя текущая рекомендация.

Клиенту функциональности домена не нужно знать, используют ли они интерфейс, абстрактный класс или конкретный класс. Если им нужно это знать, то в таком проекте есть какая-то серьезная проблема, потому что у него есть логика домена и инфраструктурные проблемы, смешанные на одном уровне абстракции. Поэтому я рекомендую " a" или " c".