Должно ли свойство иметь то же имя, что и его тип?
Я иногда видел код, написанный следующим образом:
public class B1
{
}
public class B2
{
private B1 b1;
public B1 B1
{
get { return b1; }
set { b1 = value; }
}
}
то есть. класс B2 имеет свойство "B1", которое также имеет тип "B1".
Мой интуитивный инстинкт подсказывает мне, что это не очень хорошая идея, но есть ли какие-либо технические причины, по которым вам следует избегать предоставления свойства с тем же именем, что и его класс?
(я использую .net 2.0, если это имеет значение).
Ответы
Ответ 1
Это хорошо. Канонический пример здесь
public Background {
public Color Color { get; set; }
}
Есть редкие проблемы (угловые случаи), которые появляются здесь, но недостаточно, чтобы избежать этого устройства. Честно говоря, я считаю это устройство весьма полезным. Мне не понравилось бы не в состоянии сделать следующее:
class Ticker { ... }
public StockQuote {
public Ticker Ticker { get; set; }
}
Я не хочу говорить Ticker StockTicker
или Ticker ThisTicker
и т.д.
Ответ 2
Руководство Microsoft Naming Guideline для участников:
Подумайте о том, чтобы дать свойство того же имени, что и его тип.
Если у вас есть свойство, которое строго типизировано для перечисления, имя свойства может быть таким же, как имя перечисление. Например, если у вас есть перечисление с именем CacheLevel
, свойство, возвращающее одно из его значений, также может быть с именем CacheLevel
.
Хотя я признаю, что существует небольшая двусмысленность, рекомендуют ли они это только для Enums или для свойств в целом.
Ответ 3
Только сегодня Эрик рассказал о проблеме "Цветной цвет".
http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx
Лично я мог бы избежать этого, если это возможно.
Ответ 4
Я могу думать только об одном недостатке. Если вы хотите сделать что-то вроде этого:
public class B1
{
public static void MyFunc(){ ; }
}
public class B2
{
private B1 b1;
public B1 B1
{
get { return b1; }
set { b1 = value; }
}
public void Foo(){
B1.MyFunc();
}
}
Вам нужно будет использовать:
MyNamespace.B1.MyFunc();
Хорошим примером этого является обычное использование в программировании Winforms, где класс System.Windows.Forms.Cursor перекрывается с свойством System.Windows.Forms.Form.Cursor, поэтому ваши события формы должны обращаться к статическим членам, используя полное пространство имен.
Ответ 5
Там нет особых технических проблем. Это может повредить или улучшить читаемость. Фактически, некоторые библиотеки Microsoft обладают такими свойствами (в частности, с параметрами enum
это обычно имеет смысл).
Ответ 6
Другая информация имеет внутренние типы.
Я все время сталкиваюсь с этим:
public class Car {
public enum Make {
Chevy,
Ford
};
// No good, need to pull Make out of the class or create
// a name that isn't exactly what you want
public Make Make {
get; set;
}
}
Ответ 7
Это может быть немного запутанным, когда имя свойства и его тип совпадают, но кроме этого это не проблема.
Если имя имеет смысл, обычно лучше, чтобы имя и тип были одинаковыми. Если вы можете подумать о более лучшем имени, вы должны, конечно, использовать это, но вы не должны пытаться составить имя любой ценой, чтобы избежать этой ситуации.
Ответ 8
Этот общий шаблон является одной из причин, почему я всегда использую this
при обращении к члену экземпляра внутри класса. например всегда
this.SomeMethod(this.SomeProperty);
и никогда
SomeMethod(SomeProperty);
В большинстве случаев нет никакой реальной двусмысленности, но я нахожу, что это помогает прояснить ситуацию. Кроме того, теперь вы знаете, где определяется свойство/метод.
Ответ 9
Я даю то же имя, что и их тип, за исключением случая: мои методы и свойства являются "lowerCase"; и поэтому у меня не было бы проблемы, с которой MiffTheFox имеет.
public class B1
{
public static void myFunc(){ ; }
}
public class B2
{
private B1 m_b1;
public B1 b1
{
get { return m_b1; }
set { m_b1 = value; }
}
public void Foo()
{
B1.myFunc(); //this is Ok, no need to use namespace
}
}
Итак, для меня m_b1
- это данные члена, b1
- свойство (или локальная переменная или параметр), а b1
- это имя класса.