.NET Разработчик

День четыреcта пятый. #MoreEffectiveCSharp
6. Убедитесь, что свойства ведут себя как данные
Свойства ведут себя двояко. Снаружи они похожи на простой доступ к данным, однако изнутри это методы. Такое поведение может вызвать соблазн создать свойство, выполняющее некоторую работу перед выдачей результата. Однако имейте в виду, что клиенты класса ждут от свойств некоторого определённого поведения:
1. Последующие вызовы аксессора (get) без каких-либо промежуточных действий должны приводить к тому же результату (понятно, что это не относится к случаю изменения свойства другими потоками).
2. Аксессор свойства не будет выполнять большую работу. Доступ к данным никогда не должен быть дорогой операцией. Аналогично, методы доступа к набору свойств, вероятно, будут выполнять некоторую проверку, но их вызов не должен быть дорогим. Например, в цикле
for(int i=0;i<arr.Length;i++)
если бы свойство Length считало количество элементов на каждой итерации, такой простой цикл выполнялся бы в квадратичное время, и никто бы его не использовал.

Соответствовать таким ожиданиям клиентов не сложно:
1. Используйте автосвойства.
2. Реализуйте проверку значения свойства в мутаторе (set), а не в аксессоре (get). Таким образом она будет выполняться 1 раз при записи, а не при каждом чтении значения.
3. Простые математические расчёты (расстояние до точки по координатам или площадь фигуры) никак не влияют на производительность, поэтому их можно безболезненно включить в аксессор.

Однако, если расчёт значения дорог, нужно продумать доступ к нему:

// Плохая реализация
public class MyType {
  public string Name => GetFromDB();
}

Пользователи не ожидают, что доступ к свойству потребует обращения к базе данных. Поэтому API нужно изменить. Есть несколько способов:
1. Получение однократно и сохранение в кэше

public class MyType {
  private string name;
  public string Name => (name != null) ? 
    name : GetFromDB();
}

*GetFromDB в этом случае устанавливает значение name.
2. Аналогичный способ с использованием типа Lazy<T>:

public class MyType {
  private Lazy<string> lazyName;
  public MyType() {
    lazyName = new Lazy<string>(() => GetFromDB());
  }
  public string Name => lazyObjectName.Value;
}

Это хорошо работает, когда свойство Name требуется только изредка. Вы не извлекаете значение, если оно не нужно. Но первый обратившийся к нему «страдает за всех». Если к свойству обращаются часто, можно рассмотреть вариант получения значения в конструкторе сразу при создании экземпляра.

3. Предыдущие примеры предполагают, что значение в БД никто не изменяет. В противном случае, если требуется как получать, так и изменять значение в БД, доступ лучше реализовать через методы с понятными именами (например, LoadFromDatabase и SaveToDatabase), чтобы клиентам был очевиден объём работы, требующийся для этого.

Наконец, имейте в виду, что отладчики могут автоматически вызывать методы доступа к свойству для отображения значения при отладке. Если аксессор выбрасывает исключение, занимает много времени или изменяет внутреннее состояние приложения, это усложнит ваши сеансы отладки. В этом случае в Visual Studio можно использовать трюк «Определение значения без побочных эффектов».

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 6.

1.38K viewsedited 06:59