Как избежать использования одного и того же идентификатора для имен классов и имен свойств?

Question

Вот несколько примеров классов и свойств, имеющих один и тот же идентификатор:

public Coordinates Coordinates { get; set; }
public Country Country { get; set; }
public Article Article { get; set; }
public Color Color { get; set; }
public Address Address { get; set; }
public Category Category { get; set; }

Эта проблема возникает чаще при использовании POCO с Entity Framework, поскольку Entity Framework использует имя свойства для отношений.

Так что же делать? Использовать нестандартные имена классов?

public ClsCoordinates Coordinates { get; set; }
public ClsCountry Country { get; set; }
public ClsArticle Article { get; set; }
public ClsColor Color { get; set; }
public ClsAddress Address { get; set; }
public ClsCategory Category { get; set; }

Юк

Или использовать более информативные имена свойств?

public Coordinates GeographicCoordinates { get; set; }
public Country GeographicCountry { get; set; }
public Article WebArticle { get; set; }
public Color BackgroundColor { get; set; }
public Address HomeAddress { get; set; }
public Category ProductCategory { get; set; }

Меньше, чем идеал, но я могу жить с этим, я полагаю.

или просто жить с ним?

Какие у вас лучшие практики?

Answer 1

Это иногда называют проблемой «Color Color» - и мой совет - просто жить с этим.

Спецификация языка C # была разработана для того, чтобы это не было проблемой. Из раздела 7.5.4.1 спецификации C # 3:

В членском доступе формы E.I, если E является одним идентификатором, и если значение E как простого имени (§7.5.2) является константой, полем, свойством, локальным переменная или параметр с тем же введите как значение E как имя типа (§3.8), тогда оба возможных значения E допускаются. Два возможные значения Е. Я никогда не неоднозначный, так как я должен быть обязательно член типа E в обоих случаях. Другими словами, правило просто разрешает доступ к статическим членам и вложенные типы Е, где в противном случае ошибка времени компиляции произошло.

(за примером.)

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

Это происходит в самой платформе - например, HttpWebRequest.CookieContainer имеет тип CookieContainer, и существуют различные типы со свойством Evidence типа Evidence.

Answer 2

Я стараюсь использовать более описательные имена свойств.

Изменение имени класса похоже на то, что оно побеждает цель, поскольку большинство разработчиков недооценивают использование хороших и описательных имен переменных / свойств.

Как в вашем примере, например, Адрес acan будет

public Address HomeAddress { get; set; } 
public Address PostalAddress { get; set; } 
public Address CompanyAddress { get; set; } 

и т.д.. Вы можете видеть, куда я иду с этим.

Answer 3

Лично я не стесняюсь, чтобы имя класса и имя свойства совпадали, если имена действительно применимы. Например, в классе Address наличие свойства с именем Country, которое типизируется как класс с именем Country, имеет смысл, и на самом деле нет никакого имени для свойства, которое не является избыточным. Я стараюсь избегать коллизий, используя описательные имена свойств, но иногда имя для свойства и его тип являются лучшими именами для использования, а использование чего-либо еще уменьшает ясность, а не улучшает ее.

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

Answer 4

Я думаю, что название свойства должно просто описывать, что это такое. Когда это Apple, просто назовите ее Apple.

Зачем кому-то, только для удобства чтения, использовать венгров в именах классов. Это уменьшает читаемость имени класса.

При доступе к свойству вы можете использовать это ключевое слово, чтобы предотвратить случайное неправильное чтение свойства как класса:

class Food
{
    public Apple Apple
    {
        get;
        set;
    }

    public void DoIt()
    {
        this.Apple = new Apple();
    }
}

class Apple
{
}

См. SA1101 of StyleCop "Проверяет, что вызовы локальных участников имеют префикс 'this.' нотации. "