Почему префикс C # имен интерфейсов с «I»

Полное противоположное, соглашение о присвоении имен ясно определяет интерфейс.

, Например, если Вы имеете:

public class Dog : IPet, IMammal
{
    ....

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

CLR.NET допускает наследование единого класса. Так, если у меня есть базовый класс.. Я могу только наследовать один класс от него. Позволяет изменяют интерфейс IPet на базовый класс.. наш пример теперь становится

public class Dog : Pet, IMammal
{
    ....

, я наследовался Любимому классу и реализую интерфейс IMammal.

, Если мы сделали это, что Вы предлагаете и удалили букву "I", у нас есть это:

public class Dog : Pet, Mammal
{
    ....

, Какой является классом, которому я наследовался? Который является интерфейсом, который я реализую? Это получает запутывающее право? (К вашему сведению.. Вы, как предполагается, помещаете базовый класс всегда сначала, таким образом, Вы могли оспорить ту точку зрения..., но если Вы требуете удалять букву I из добавления префикса имен интерфейса, я сомневаюсь, что Вы применяете ту практику также)

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

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

Однако я все еще использую его, потому что в этом случае IInterface рекомендуется Microsoft, и "стандарт лучше, чем лучше".

Скорее всего, для создания его легко идентифицирующимся в intellisense так как все интерфейсы нанесут удар вместе. Подобный тому, как я снабжаю префиксом все свои средства управления UI btn, ТБ, lb. Когда удары intellisense во всем собраны в группу вместе в одной легкой группе.

Мне также нравится он причина, я могу считать его как "Я поведение глагола" как в "ICanSave" или "IDoDoubleEntry" и т.д.

Это делает его легко идентифицирующимся как интерфейс.

Это - или это, или добавьте "Impl" к реализации интерфейса (argh). У меня нет проблемы с "I", это является самым простым и большая часть простого именования для интерфейса.

На самом деле я нахожу полезным постараться не называть столкновения, я мог бы, например, создать реальный класс по имени Fred, который реализует IFred

Соглашения о присвоении имен предлагают преимущество сообщения Вам что-то об объекте перед использованием его. Соглашения о присвоении имен широко много лет использовались, идя полностью назад в настойчивость Фортрана, что целочисленные значения были ограничены (если я помню правильно) к именам переменной как "i" и "j".

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

имена интерфейса Добавления префикса с я относительно низкое влияние, безопасный способ определить тот объект.

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

class Dog: IBark

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

чтобы ответить на ваш вопрос, подумайте о I как о «реализации» Итак ...

class DogDataService : Dog, IDataService

этот служебный класс наследуется от Dog и реализует IDataService

Я все еще не отвечаю на ваш вопрос, но I полезен, потому что вы получаете коллизии имен между пространством имен, классом и интерфейсом.

namespace DataService
interface DataService
class DataService: DataService

поэтому мы получаем

namespace DataServices
interface IDataService
class DataService : IDataService

Я думаю, что на самом деле это соглашение здравомыслия.

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

Во-первых, я считаю, что префикс I, а затем описание неверен, потому что это означает, что реализации могут иметь более короткое имя. IList (intf) -> Список. Это анти-шаблон, поскольку все мы знаем, что при создании следует использовать intf и, вероятно, только конкретные типы. Не огорчай меня, это обобщение, но исходная посылка возникает редко. Название реализации должно описывать, как она реализует intf или что она делает. Подумайте intf List, LinkedList, который реализует List с использованием связанного списка. Кого волнует, длиннее ли это, поскольку мы должны использовать List большую часть времени.Если у нас есть класс, реализующий множество intf, мы, вероятно, не должны включать все intf, поскольку тени являются реальной целью класса. В случае, если что-то удалено без intf, имеет смысл. Например, люди зовут меня по имени, а не по имени, а не по имени, брат или сестра, разработчик и т. Д. Использование моего имени - это лучшее, наиболее информативное имя. Я полагаю, что если класс подразумевается как простой intf, тогда назовите его Default Intf, что делает его единственной реализацией Intf по умолчанию. Имена классов должны быть понятны человеку и должны быть почти короткими фразами, описывающими их назначение. Коды префиксов и т. Д. Не очень хороши, поскольку мы общаемся словами, а не кодами. Компьютеры не знают, какие классы называются, поэтому остается то, что мы называем вещи так, чтобы имена помогали нам и нашим коллегам.