Почему класс не имеет статического или постоянного свойства и свойства экземпляра с тем же именем?

Question

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

public class SomeGridRow 
{ 
    public string Code { get;set; } 
    public string Description { get;set; } 

    public const string Code = "Code"; 
} 

Очевидно, что это дает ошибку:

The type 'SomeGridRow' already contains a definition for 'Code'

Почему CLR не справляется с двумя свойствами одного и того же имени, которые на мой взгляд являются отдельными?

string code = gridRow.Code;   // Actual member from instantiated class 
string codeField = SomeGridRow.Code; // Static/Const 

Я сейчас только с помощью дочернего класса под названием Fields в пределах своих входов, так что я могу использовать SomeGridRow.Fields.Code. Это немного грязно, но это работает.

Answer 1

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

public class SomeGridRow 
{ 
    public string Code { get;set; } 
    public const string Code = "Code"; 
    public void MyMethod() { 
    var thing = Code; //what would this reference? 
    } 
} 

так как это:

public class SomeGridRow 
{ 
    public string Code { get;set; } 
    public void MyMethod() { 
    var thing = Code; //what would this reference? 
    } 
} 

И это:

public class SomeGridRow 
{ 
    public const string Code = "Code"; 
    public void MyMethod() { 
    var thing = Code; //what would this reference? 
    } 
} 

являются допустимыми способами доступа к свойствам, ул атичный или нет. Он не отвечает: «Почему я не могу?» вопрос, но больше того, почему это не допускается ... это было бы слишком неоднозначным ИМО.

Answer 2

Возможно, это возможно, но дизайнеры C# хотели избежать двусмысленностей, которые могут возникнуть в результате использования (злоупотребления?) Функций языка.

Такой код окажется запутанным и неоднозначным для пользователей (мне нужен экземпляр или вызов статического метода?) Какой из них прав?).

Answer 3

В дополнение к точкам, уже сделанным о двусмысленности, я бы сказал, что именование должно быть восстановлено в таком случае.

Если две переменные/поля, имеющие одно и то же имя в одном контексте, класс i.e, но разные значения, скорее напоминают проблему с именами.

Если они точно такие же, вам не нужны 2 поля.

Если они немного разные, у вас должны быть более точные имена.

Answer 4

В некоторых других языках с аналогичным синтаксисом можно получить доступ к статическому элементу через экземпляр. Таким образом, вы можете получить доступ как к string.Empty, так и к "abc".Empty.

C# не допускает этого (хотя он делает вид внутри класса или производного класса, поскольку вы можете опустить имя класса для статического члена и можете опустить для члена экземпляра), в первую очередь, чтобы избежать путаница (я нахожу ее более удобной, чем путаница tbh, но это только я, мне нравится переключаться с ошибкой, так что я знаю).

Введя более строгое правило, позволяющее допускать меньшую двусмысленность, было бы контрпродуктивным разрешить новое правило свободного доступа на оборотной стороне, которое допускало больше. Подумайте, сколько «почему я должен использовать this с имуществом X, но не свойство Y?«вопросы, которые были бы у SO, если бы это было разрешено (нам нужно было бы заставить , чтобы свойство X было понятным, мы имели в виду член экземпляра).