Почему свойства не могут быть прочитаны только?

Question

Этот вопрос возник в комментариях this answer. Невозможность иметь свойства readonly была предложена в качестве потенциальной причины использовать поля вместо свойств.

Например:

class Rectangle 
{ 
    private readonly int _width; 
    private readonly int _height; 

    public Rectangle(int width, int height) 
    { 
     _width = width; 
     _height = height; 
    } 

    public int Width { get { return _width; } } 
    public int Height { get { return _height; } } 
} 

Но почему вы не можете просто сделать это?

public int Width { get; readonly set; } 

Edit (осветление): Вы можете достичь этой функциональности в первом примере. Но почему вы не можете использовать автоматически реализованное сокращение свойств, чтобы сделать то же самое? Это также было бы менее беспорядочно, поскольку вам не приходилось напрямую обращаться к полям в вашем конструкторе; весь доступ будет через собственность.

Answer 1

Потому что язык этого не позволяет.

Это может показаться легкомысленным ответ: в конце концов, разработчики языка могли заявили, что если вы использовали readonly на автоматическую собственности, то это будет означать «свойство настраиваемое, но только в конструкторе».

Но функции не предоставляются бесплатно. (Эрик Ганннерс выражает это как «Каждая функция начинается с minus 100 points».) Чтобы реализовать автоматические свойства только для чтения, потребовалось бы дополнительное усилие компилятора для поддержки модификатора readonly для свойства (оно применимо только к полям), чтобы создать соответствующую поддержку и преобразовать sets свойства в присвоения поля поддержки. Это небольшая работа, чтобы поддержать то, что пользователь мог бы сделать достаточно легко, объявив поле для чтения в режиме readonly и создав однострочный getter, и эта работа будет стоить с точки зрения не реализации других функций.

Итак, совершенно серьезно, ответ заключается в том, что либо разработчики языка, либо разработчики никогда не думали об этой идее, или, скорее, они думали, что было бы неплохо иметь, но решили, что есть лучшие места для проведения их конечных ресурсов. Нет никаких технических ограничений, которые препятствуют разработчикам и разработчикам языка предоставлять предлагаемую вами функцию: причины больше касаются экономики разработки программного обеспечения.

Answer 2

Если вы хотите сделать недвижимость «только для чтения» в том, что касается функциональности, вы делаете это, предоставляя только метод get, как указано в сообщении.

public int Width { get { return _width; } } 
public int Height { get { return _height; } } 

Компилятор будет даже ссылаться на них как «только на чтение», если вы попытаетесь написать им.

Имея дополнительный срок readonly для имущества, столкнулся бы с предоставлением метода set. Мне кажется, что это плохой синтаксис, т. Е. Как человек, читающий его (или компилятор, если на то пошло) знает, что имеет преимущество: readonly или set?

Кроме того, как пояснялось в ответе, на который вы ссылаетесь, readonly применяется только к полям и лимитам, записывающим эти поля в экземпляр класса. Со свойствами вы не можете писать им (я не думаю) даже внутри конструктора, если у них есть только метод get.

Answer 3

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

Идентификаторы get и set необходимы для автоматических свойств, и нет смысла для свойства, доступного только для чтения, иметь set.

Вы можете задать регулярное свойство как свойство только для чтения, только Определяя get - однако, даже если требование для обоих get и set для автоматических свойств не существует - свойство только для чтения не может быть автоматически определяется, потому что вам нужно знать поле поддержки, чтобы иметь возможность устанавливать его значение внутри (т. е. через конструктор).

Я полагаю, что в генерации кода может быть шаблон/макрос или что-то определенное в VS, но оно не может быть частью самого языка.

Answer 4

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

public bool Property {get; private set;} 

сеттер по-прежнему определяется, но она больше не видна за пределами класса, в котором определяется свойство. В стороне, иногда полезно определить сеттер как внутренний, чтобы свойства можно было легко установить из одной сборки, но не из внешних вызывающих.

Answer 5

Я думаю, что в основном проблема заключается в том, что свойства - это просто синтаксический сахар для поля с дополнительными методами getter/setter. Автоматические свойства генерируют поле поддержки так, чтобы они требовали «setter», или не было бы способа установить значение поля поддержки. Поскольку свойства действительно сопоставляются с методами, а не с полями, нет смысла делать их readonly.

Даже если разрешено, readonly может применяться только к автоматическим свойствам. Для традиционных свойств вы можете поместить произвольный код как в getter, так и в setter. Даже если установщик мог быть вызван только в конструкторе класса, геттер все же мог бы изменить значение, основанное на любой логике, которую вы решили вставить в нее. Это полностью противоречило бы концепции readonly, что потребовало бы разных правил синтаксиса и поддержки автоматических/традиционных свойств. Поскольку существует механизм - использование традиционных свойств только с определенным геттером и поле для чтения только для чтения, как в ссылочном вопросе, - я не вижу смысла в том, чтобы сбрасывать синтаксис свойств и потенциально создавать путаницу для чего-то с довольно простой и простой реализацией используя существующие языковые конструкции.

Answer 6

Если Свойс есть отдельный набор, то это только для чтения от внешнего мира, а именно:

string _name; 
public string Name 
{ 
    get{ return _name; } 
    private set { _name = value; } 
} 

Или это может быть сделано только для чтения, если он не имеет сеттер вообще, то есть:

string _name; 
public string Name 
{ 
    get{ return _name; } 
}