Должны ли свойства в C # выполнять большую работу?

Question

Когда свойство читается или присваивается, нельзя ожидать, что оно выполнит большую работу.Когда вместо этого используются методы setSomeValue(...) и getSomeValue(...), не следует удивляться, что под капотом может происходить что-то нетривиальное.Однако теперь, когда C # дал миру Properties , кажется глупым использовать вместо этого методы getter и setter.Что вы думаете об этом?Должен ли я отметить этот вопрос как вики сообщества?

Спасибо.

РЕДАКТИРОВАТЬ:

В моем случае это не такдорого вызывать, но это вызывает установку связанного свойства в другом классе и, возможно, запись короткого сообщения в файл журнала (если URL пуст).Это слишком много работы для собственности?Какая альтернатива.

Answer 1

Однако теперь, когда C # дал миру свойства, кажется глупым использовать вместо этого методы получения и установки.

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

Должны ли свойства в C # выполнять большую работу?

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

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

Какая альтернатива.

Вы также можете прочитать этот ответ , в котором приведены некоторые общие рекомендации по проектированию недвижимости.Я бы также посоветовал вам прочитать Выбор между свойствами и методами в руководстве по проектированию .NET для MSDN.

Иногда имеет смысл создать свойство, доступное только для чтения (без установщика)но там, где существует один или несколько отдельных методов, которые устанавливают внутреннее состояние, связанное с этим свойством.Использование этой идиомы зависит от того, будут ли операции над вашим объектом семантически представлены как «изменение состояния» или «выполнение действия» .Когда это происходит позже, я склонен использовать методы (а не установщики свойств) для выражения этого поведения.

Answer 2

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

Answer 3

Точная сумма слишком много работы спорно. Лучший ответ заключается в том, что свойства должны скорее выполнять меньше работы, чем больше работы:)

Одна вещь, которую Get Properties никогда не должна делать , - это изменение состояния объекта.

Answer 4

Человек, использующий созданный вами класс, понятия не имеет, что такое реализация.Он мог бы использовать User.ID снова и снова, не зная, что каждый из них является вызовом БД.
Видите ли, в 99% случаев свойства - это не более чем переменные, в лучшем случае с дополнительной строкой кода, поэтому разработчики считаютих как таковых.Хорошей практикой считается рефакторинг свойства в метод, если он каким-либо образом дорог.Вы никогда не знаете, что скрывает метод, и (хорошие) разработчики экономят на вызове методов, когда они могут кэшировать результаты предыдущих вызовов.

Answer 5

Вместо этого используются

методы, не следует удивляться, что под капотом может происходить что-то нетривиальное

из-за свойств является просто синтаксическим сахаром над точно такими же методами Set ... и Get ... (которые создаются компилятором при создании IL) - никакой разницы нет. Если бы вы реализовали некоторую логику в SetFoobar - сделайте это в Foobar {set {...}} тоже

Answer 6

Как пользователь класса, Я ожидаю, что свойства будут недорогими - потому что, как следует из названия, они просто получают / устанавливают значение объекта.Напротив, когда я вызываю метод для объекта, я осознаю, что он будет « делать что-то » и может быть дорогим.является то, что свойство-геттер не должно иметь побочных эффектов .Например, свойство-получатель должно возвращать одно и то же значение, даже если я назову его 10 раз подряд.Это лучше всего видно, когда вы видите это использование свойства:

int result = obj.SomeNumber + obj.SomeNumber;
// I expect SomeNumber to return the same value on both calls

Answer 7

Я думаю, что лучшее правило, которое следует соблюдать, это то, что они не должны выбрасывать выражения, а также не имеют побочных эффектов. Например, если вы продолжаете вызывать метод получения, и ничто другое не меняет, возвращаемое значение не должно меняться. Обратите внимание, что ‘DateTime.Now‘ не следует этому правилу, но, вероятно, должно иметь.

Answer 8

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

Answer 9

«Должны» они? Это мягкий вопрос.

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

Answer 10

нет, свойства не должны выполнять много работы ...