Логика в получении части имущества. Хорошая практика?

Question

При привязке данных xaml к некоторым данным я часто использую часть свойства get для выполнения некоторой логики. Например, для подведения итогов списка или проверки, если что-то положительно.

Например:

public List<SomeClass> ListOfSomeClass{get;set;}

public double SumOfSomeClass
{
  get
  {
    return ListOfSomeClass.Sum(s => s.Totals);
  }
}

public bool SumPositive
{
  get
  {
    if(SumOfSomeClass >= 0)
      return true;
    else
      return false;
  }
}

Таким образом, я могу связываться с SumPositive и SumOfSomeClass. Это считается хорошей практикой? Даже если это станет более сложным, чем это? Или лучше вызвать метод и вернуть результат? А как насчет звонков в другой класс или даже в базу данных?

Answer 1

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

Answer 2

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

Answer 3

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

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

Я считаю, что свойства должны быть свободны от побочных эффектов для объекта, для которого они вызываются. Гораздо труднее гарантировать, что они не влияют на более широкую среду - даже относительно тривиальное свойство может вытянуть данные в память или, по крайней мере, изменить кэш процессора или состояние виртуальной машины.

Answer 4

Пожалуйста, измените этот геттер на:

public bool SumPositive
{
  get
  {
     return SumOfSomeClass >= 0;
  }
}

Вы уже используете логическое выражение, нет необходимости явно возвращать true или false

Answer 5

Для базовых вычислений вне полей или других свойств в коллекции было бы приемлемо сделать это внутри свойства Get. Как и все остальные, истинная логика никогда не должна делаться в геттере.

Answer 6

Я не вижу прямой проблемы (если список не очень большой), но я бы лично использовал метод myInstance.SomeList.Sum(), если это возможно (.net> = 2.0).

Answer 7

Наличие сложной логики в методах получения / установки не является хорошей практикой. Я рекомендую переместить сложную логику в отдельные методы (например, GetSumOfXYZ ()) и использовать memoization в средствах доступа к свойствам.

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

Answer 8

Я говорю да, но попробуйте сохранить в закрытой переменной результаты ListOfSomeClass.Sum (s => s.Totals). Особенно, если вы используете его более одного раза.

Answer 9

Я бы осторожно вставил любую логику в получатель свойства. Чем дороже это сделать, тем опаснее. Другие разработчики ожидают, что получатель вернет значение сразу же, как и получение значения из переменной-члена. Я видел много случаев, когда разработчик использовал свойство на каждой итерации цикла, думая, что он просто возвращает значение, в то время как свойство фактически выполняет большую работу. Это может привести к серьезному замедлению выполнения кода.

Answer 10

Я думаю, что есть некоторый уровень логики, который ожидается в Getter и Setters, в противном случае у вас просто есть некий извилистый способ объявить своих участников публичными.