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

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

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

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

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

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

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

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

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

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

Из книги Framework Design Guidelines:

Interfaces representing roots of a hierarchy (e.g. IList) should also use nouns or noun phrases. Interfaces representing capabilities should use adjectives and adjective phrases (e.g. IComparable, IFormattable).

Также из аннотаций по именованию интерфейсов:

KRZYSZTOF CWALINA: One of the few prefixes used is “I” for interfaces (as in ICollection), but that is for historical reasons. In retrospect, I think it would have been better to use regular type names. In a majority of the cases developers don’t care that something is an interface and not an abstract class, for example.

BRAD ABRAMS: On the other hand, the “I” prefix on interfaces is a clear recognition of the influence of COM (and Java) on the .NET Framework. COM popularized, even institutionalized, the notation that interfaces begin with “I.” Although we discussed diverging from this historic pattern we decided to carry forward the pattern as so many of our users were already familiar with COM.

JEFFREY RICHTER: Personally, I like the “I” prefix and I wish we had more stuff like this. Little one-character prefixes go a long way toward keeping code terse and yet descriptive. As I said earlier, I use prefixes for my private type fields because I find this very useful.

BRENT RECTOR Note: this is really another application of Hungarian notation (though one without the disadvantages of the notation's use in variable names).

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

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

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

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

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

public class CustomerImpl implements Customer

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

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

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

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

Мое главное предположение состоит в том, что самое главное - поддерживать читаемость в доменной части реализации. Следовательно:

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

  public class StackOverflowAnswerGenerator { }

• Если у вас есть одно поведение и множество возможных реализаций, тогда нет проблем, и вы можете просто отбросить «Я» и получить:

  public interface StackOverflowAnswerGenerator {}

  public class StupidStackOverflowAnswerGenerator : StackOverflowAnswerGenerator {}

  public class RandomStackOverflowAnswerGenerator : StackOverflowAnswerGenerator {}

  public class GoogleSearchStackoverflowAnswerGenerator : StackOverflowAnswerGenerator {}

  //...

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

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

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

  namespace StackOverflowAnswerMachine.Interfaces 
  {
    public interface StackOverflowAnswerGenerator {}
  }
  
  namespace StackOverflowAnswerMachine 
  { 
    public class StackOverflowAnswerGenerator : Interfaces.StackOverflowAnswerGenerator
  {}
  
  }
  

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

  namespace StackOverflowAnswerMachine 
  {
    public interface StackOverflowAnswerGenerator {}
  }
  
  namespace StackOverflowAnswerMachine.Implementations 
  { 
    public class StackOverflowAnswerGenerator : StackOverflowAnswerMachine.StackOverflowAnswerGenerator 
  {}
  
  }
  

Хотя я думаю, что последняя возможность является наиболее чистой, ее единственный недостаток состоит в том, что, хотя using StackOverflowAnswerMachine; дает вам доступ ко всем объектам домена, вы должны префикс всех интерфейсов домена, чтобы не путать их с их реализациями. Это может показаться чем-то не очень удобным, но в чистом дизайне обычно класс не использует многие другие объекты домена, и в основном вам нужно использовать префикс только в объявлении поля и списке параметров конструктора. Итак, это моя текущая рекомендация.

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