Должны свойства в C# выполнять большую работу?
Когда свойство читается из или присвоено, нельзя было бы ожидать, что это выполнит большую работу. Когда setSomeValue(...) и getSomeValue(...) методы используются вместо этого, не нужно быть, это удивило это, что-то нетривиальное могло бы продолжаться под капотом. Однако теперь, когда C# дал мировые Свойства, кажется глупым использовать методы получателя и методы установщика вместо этого. Каково Ваше взятие на этом? Я должен отметить этот Q как общественную Wiki?
Спасибо.
Править:
В моем случае не дорого звонить, но это инициировало установку связанного свойства в другом классе и возможно записи короткого сообщения к файлу журнала (если URL является пробелом). Так слишком много работы для свойства? Какова альтернатива.
10 ответов
Однако теперь, когда C # дал миру Свойства, кажется глупым использовать вместо них методы получения и установки .
Прежде чем думать о том, насколько дорогими должны быть свойства, я бы посоветовал вам подумать о том, лучше ли представить концепцию, которую вы моделируете, как «свойство чего-то». В языке существуют свойства для выражения атрибуции других сущностей - если SomeValue логически не является свойством того типа, к которому оно принадлежит, то вам следует вместо этого рассмотреть возможность использования методов получения / установки.
Должны ли свойства в C # выполнять много работы?
С другой стороны, это помогает сделать свойства недорогими, когда это возможно. Большинство разработчиков ожидают, что свойства будут эффективными оболочками для некоторого внутреннего состояния того типа, к которому они принадлежат. Нарушение этого ожидания затрудняет для разработчиков написание хорошо работающего кода, использующего это свойство. Например, если свойство используется в качестве условия цикла for , оно будет оцениваться на каждой итерации - если это дорого ... ну, это может быть плохо.
К свойствам также часто обращаются в отладчике - вы не хотите, чтобы свойства выполняли дорогостоящую логику, поскольку это может препятствовать отладке. Получатели свойств, которые выполняют операции с побочными эффектами (например, запросы к базе данных), также обычно являются плохой практикой, поскольку они могут вводить heisenbugs при проверке поведения приложения в отладчике.
Какая альтернатива.
Вы также можете прочитать этот ответ , который дает некоторые хорошие общие рекомендации по проектированию свойств. Я бы также посоветовал вам прочитать Выбор между свойствами и методами в рекомендациях по проектированию .NET на MSDN.
Иногда имеет смысл создать свойство, доступное только для чтения (без установщика), но в котором существует один или несколько отдельных методов, которые устанавливают внутреннее состояние, связанное с этим свойством. Использование этой идиомы зависит от того, отображаются ли операции над вашим объектом семантически как «изменение состояния» или «выполнение действий» . Когда дело обстоит позже, я предпочитаю использовать методы (а не средства задания свойств), чтобы выразить такое поведение.
Общее правило гласит, что свойства не должны быть дорогими для вызова. Если они дороги для вызова, сделайте вместо них геттер. Этому не всегда можно следовать, вам определенно нужно использовать суждение.
Точное количество слишком большой работы является спорным. Лучший ответ - свойства скорее должны выполнять меньше работы, чем больше :)
Одна вещь, которую Get Properties никогда не должны делать - это изменять состояние объекта.
"Должны" ли они? Это спорный вопрос.
Они, конечно, могут, и нет "много" причин не делать этого. Переполнение стека - одна из веских причин избегать выполнения большого объема работы внутри аксессора свойства, но если ваш код читабелен, а намерения легко передаются, нет жесткого и быстрого правила, которое говорит, что этого делать не следует.
, не стоит удивляться тому, что под капотом может происходить что-то нетривиальное
, потому что Properties - это просто синтаксический сахар над точно такими же Set ... и Get ... методы (которые производит компилятор при создании IL) - нет никакой разницы. Если вы хотите реализовать какую-то логику в SetFoobar - сделайте это и в Foobar {set {...}} тоже
Человек, использующий созданный вами класс, не имеет представления о его реализации. Он может использовать User.ID снова и снова, не зная, что каждый из них является вызовом БД.
Видите ли, в 99% случаев свойства - это не более чем переменные с лишней строкой кода в лучшем случае, поэтому разработчики обращаются с ними именно так. Считается хорошей практикой рефакторить свойство в метод, если оно дорого в любом случае. Вы никогда не знаете, что скрывает метод, и (хорошие) разработчики экономят на вызове методов, когда они могут кэшировать результаты предыдущих вызовов.
Свойства на самом деле просто синтаксический сахар . Я предпочитаю делать их очень простыми и не вкладывать в них много кода. Однако для этого нет никаких технических причин. В конце концов, это просто выполняемые функции. Когда вы их используете, вам нужно спросить, что будет наиболее удобным в обслуживании и интуитивно понятным для тех, кто придет после вас.
Как пользователь класса, я ожидаю, что свойства будут недорогими - потому что, как следует из названия, они просто получают / устанавливают стоимость объекта. Напротив, когда я вызываю метод объекта, я знаю, что он « что-то сделает » и может быть дорогостоящим.
Одна вещь, которая всегда должна быть верной для свойств, - это то, что средство получения свойств не должно иметь побочных эффектов . Например. средство получения свойства должно возвращать одно и то же значение, даже если я вызываю его 10 раз подряд. Это лучше всего видно, когда вы видите такое использование свойства:
int result = obj.SomeNumber + obj.SomeNumber;
// I expect SomeNumber to return the same value on both calls
Я думаю, что лучшее правило - это то, что они не должны бросать ecxeptions, а также не должны иметь побочных эффектов. Например, если вы продолжаете вызывать getter, и больше ничего не меняется, возвращаемое значение не должно меняться. Обратите внимание, что 'DateTime.Now' не следует этому правилу, но, возможно, следовало бы.