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

Question

Каковы недостатки такого кода:

public class Class1
{
   public object Property1
   {

        set 
        {
             // Check some invariant , and null

             // throw exceptions if not satisfied

             // do some more complex logic

             //return value 
        }

   }
}

Answer 1

Условие состоит в том, что если вы выполняете чрезмерную логику, которая занимает много времени и / или имеет побочные эффекты, которые логически не вытекают из установки свойства, у вас будет довольно запутанный класс дизайн.

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

В конце концов, все зависит от того, что означает «сделать более сложную логику».

Answer 2

Сложно ответить на вопрос, поскольку "сложная логика" очень расплывчата.

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

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

Answer 3

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

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

Это, как всегда, практические правила, и обстоятельства могут диктовать, что они не соблюдаются. Хорошим примером являются свойства типов, сгенерированных через Linq to SQL. Если у вас ленивый поиск дочерних свойств, тогда его оценка действительно вызывает чтение из базы данных. Это компенсируется, но простота использования, удобочитаемость и согласованность получаемых объектов - это одна из тех вещей, которые уравновешивают конкурирующие правила.

Остерегайтесь правил, которые ДОЛЖНЫ или НИКОГДА. Иногда такие правила существуют и являются разумными, но на самом деле они необычны.

Answer 4

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

if(obj.Prop.Equals(otherObj.Prop))
{
    Console.WriteLine(obj.Prop);
    Log.CreateEntry(obj.Prop);
}

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

Свойство никогда не должно изменять объект. Свойство всегда должно возвращать один и тот же объект, если его значение не изменилось. Особенно, если создание объекта стоит дорого (например, возвращая новый StreamReader при каждом вызове)

Answer 5

Для ясности кода бизнес-логика должна быть отделена от установщиков свойств. Несложные проверки вменяемости могут и должны часто проводиться в собственности. Но все, что специфично для приложения или не подразумевается непосредственно в типе, должно быть абстрагировано. Для наилучшей ОО-практики вы бы хотели, чтобы любая логика, которая применяется только к этому объекту, была частью этого объекта, а любая сложная логика, которая относится к тому, как вы СДЕЛАНЫ с этим объектом, должна быть в той части кода, которая связана с обработкой объекта.

Answer 6

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

То же самое относится и к их установке, не ожидается, что присвоение значения вызовет некоторую дорогостоящую операцию.

Answer 7

Чтобы код был понятен, лучше, если вы сможете get точно то, что у вас есть set.

За исключением "некоторой сложной логики", которую мы пока не видим, этот код не выглядит как большой беспорядок.