Должно ли свойство иметь то же имя, что и его тип?

Ответ 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 - это имя класса.