Net framework 5, а также среды Visual Studio 2012 и C#

Осторожный подход к определению свойств
Лично мне свойства не нравятся и я был бы рад, если бы в Microsoft решили убрать 
их поддержку из .NET Framework и сопутствующих языков программирования. 
Причина в том, что свойства выглядят как поля, являясь по сути методами. Это 
порождает немыслимую путаницу. Столкнувшись с кодом, который вроде бы об-
ращается к полю, разработчик привычно предполагает наличие множества условий, 
которые далеко не всегда соблюдаются, если речь идет о свойстве.
‰
Свойства могут быть доступны только для чтения или только для записи, в то 
время как поля всегда доступны и для чтения, и для записи. Определяя свойство, 
лучше всего создавать для него оба метода доступа (
get
и 
set
).

---

269
Свойства.без.параметров
‰
Свойство, являясь по сути методом, может выдавать исключения, а при обра-
щениям к полям исключений не бывает.
‰
Свойства нельзя передавать в метод в качестве параметров с ключевым словом 
out
или 
ref
, в частности, следующий код не компилируется:
using System;
public sealed class SomeType { 
private static String Name { 
get { return null; } 
set {} 
}
static void MethodWithOutParam(out String n) { n = null; }
public static void Main() {
// При попытке скомпилировать следующую строку
// компилятор вернет сообщение об ошибке:
// error CS0206: A property or indexer may not
// be passed as an out or ref parameter.
MethodWithOutParam(out Name);
}
}
‰
Свойство-метод может выполняться довольно долго, в то время как обращения 
к полям выполняются моментально. Часто свойства применяют для синхрони-
зации потоков, но это может привести к приостановке потока на неопределенное 
время, поэтому свойства не следует использовать для этих целей — в такой си-
туации лучше задействовать метод. Кроме того, если предусмотрен удаленный 
доступ к классу (например, если он наследует от 
System.MarshalByRefObject
), 
вызов свойства-метода выполняется очень медленно, поэтому предпочтение сле-
дует отдать методу. Я считаю, что в классах, производных от 
MarshalByRefObject
, 
никогда не следует использовать свойства.
‰
При нескольких вызовах подряд свойство-метод может возвращать разные 
значения, а поле возвращает одно и то же значение. В классе 
System.DateTime
есть неизменяемое свойство 
Now
, которое возвращает текущие дату и время. При 
каждом последующем вызове свойство возвращает новое значение. Это ошибка, 
и в компании Microsoft охотно исправили бы этот класс, превратив 
Now
в метод. 
Другой пример подобной ошибки — свойство 
Environment.TickCount
.
‰
Свойство-метод может порождать видимые побочные эффекты, невозможные 
при доступе к полю. Иначе говоря, порядок определения значений различных 
свойств типа никак не должен влиять на поведение типа, однако в действитель-
ности часто бывает не так.
‰
Свойству-методу может требоваться дополнительная память или ссылка на 
объект, не являющийся частью состояния объекта, поэтому изменение возвра-

---

270
Глава.10 .Свойства
щаемого объекта никак не сказывается на исходном объекте; при запросе поля 
всегда возвращается ссылка на объект, который гарантированно относится 
к состоянию исходного объекта. Свойство, возвращающее копию, — источник 
путаницы для разработчиков, причем об этом часто забывают упомянуть в до-
кументации.
Я считаю, что разработчики используют свойства намного чаще, чем следовало 
бы. Достаточно внимательно изучить список различий между свойствами и поля-
ми, чтобы понять: есть очень немного ситуаций, в которых определение свойства 
действительно полезно, удобно и не запутывает разработчика. Единственная при-
влекательная черта свойств — упрощенный синтаксис, все остальное — недостатки, 
в числе которых потеря в производительности и читабельности кода. Если бы я 
участвовал в разработке .NET Framework и компиляторов, я бы вообще отказался от 
свойств, вместо этого я предоставил бы разработчикам полную свободу реализации 
методов 
GetXxx
и 
SetXxx
. Позже создатели компиляторов могли бы предоставить 
особый упрощенный синтаксис вызова этих методов, но только при условии его 
отличия от синтаксиса обращения к полям, чтобы программист четко понимал, что 
выполняется вызов метода!