Как избегать использования того же идентификатора для Имен Свойства и Имен классов?
Вот являются некоторые примером классов и свойств, совместно использующих тот же идентификатор:
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; }
Эта проблема происходит более часто при использовании ПОСТЕПЕННО с Платформой Объекта, поскольку Платформа Объекта использует Название Свойства Отношений.
Таким образом, что сделать? Использовать нестандартные имена классов?
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; }
Меньше, чем идеал, но может жить с ним, я предполагаю.
Или ПРОСТО ЖИВИТЕ С IT?
Кто Вы лучшие практики?
4 ответа
Это иногда известно как проблема "Color Color" - и мой совет просто жить с этим.
Спецификация языка C# была разработана таким образом, чтобы эта проблема не возникала. Из раздела 7.5.4.1 спецификации C# 3:
В доступе к члену формы E.I, если E является единственным идентификатором, и если значение E как простого имени (§7.5.2) является константа, поле, свойство, локальная переменная или параметр с тем же типом, что и значение E как имя типа (§3.8), то оба возможных значения E разрешены. Два возможные значения E.I никогда не являются двусмысленными, поскольку I обязательно должен быть членом типа E в обоих случаях. Другими словами, правило просто разрешает доступ к статическим членам и вложенным типам E там, где ошибка компиляции в противном случае произошла бы.
(Далее следует пример.)
Очевидно, что когда вы можете предоставить более описательное имя свойства, это замечательно - но довольно часто лучшим именем действительно является то же самое, что и свойство.
Это происходит в самом фреймворке - например, HttpWebRequest.CookieContainer имеет тип CookieContainer, и есть различные типы со свойством Evidence типа Evidence.
Я лично не стесняюсь совпадать имя класса и имя свойства, если имена действительно применимы. Например, в классе Address наличие свойства с именем Country , которое набирается как класс с именем Country , имеет смысл, и на самом деле нет никакого имени для свойства, которое не избыточный. Я стараюсь избегать коллизий, используя описательные имена свойств, но иногда имя свойства и его тип - лучшие имена для использования, а использование чего-либо еще снижает ясность, а не улучшает ее.
Я настоятельно рекомендую не использовать венгерский префикс в классах. Это просто ужасно.
Я стараюсь использовать более описательные имена свойств.
Изменение имени класса как будто сводит на нет цель, поскольку большинство разработчиков склонны недооценивать использование хороших и описательных имен переменных/свойств.
Как в вашем примере, например, адрес может быть
public Address HomeAddress { get; set; }
public Address PostalAddress { get; set; }
public Address CompanyAddress { get; set; }
и т.д. Вы можете понять, к чему я веду.
Я думаю, что название свойства должно просто описывать, что это такое. Когда это Apple, просто назовите его Apple.
Зачем кому-то просто для удобства чтения свойств использовать венгерские названия классов. Это снижает удобочитаемость имени класса.
При доступе к свойству вы можете использовать ключевое слово This для предотвращения случайного неправильного чтения свойства как класса:
class Food
{
public Apple Apple
{
get;
set;
}
public void DoIt()
{
this.Apple = new Apple();
}
}
class Apple
{
}
См. SA1101 в StyleCop «Проверяет, что вызовы локальных членов имеют префикс 'this'. обозначение. "