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

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

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

/ РЕДАКТИРОВАНИЕ: я хотел бы указать, что вышеупомянутое обоснование предложило мне отбрасывать I префикс для частных проектов. Однако после проверки одного из них против набора правила FxCop, я быстро вернулся к использованию I. Непротиворечивость побеждает здесь, даже при том, что глупая непротиворечивость является эльфом небольших умов.

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

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

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

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

Все о стиле и удобочитаемости. Добавление префикса Интерфейсов с "I" является просто соглашением о присвоении имен и инструкцией по стилю, которая завоевала популярность. Сами компиляторы не могли заботиться меньше.

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

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

Для.NET книга Руководства по проектированию Платформы Microsoft абсолютно рекомендует это, и да, это в значительной степени стандартно. Я никогда не видел, что сделанный иначе, и создать новую конвенцию только служил бы для смущения людей.

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

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

public class CustomerImpl implements Customer

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

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

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

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