"Getters не должны включать в себя большое количество логики". Правда или ложь?

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

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

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

PS. Из-за языковых различий, я ожидаю, что в этом будет много разных мыслей...

Ответ 1

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

Ответ 2

Из MSDN:

Рекомендации по использованию свойств

Использовать метод, когда:
[...]

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

И также:

Выбор между свойствами и методами

Использовать метод, а не свойство в следующих ситуациях.

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

Ответ 3

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

Ответ 4

В целом, очень немногие из моих методов настолько дороги с точки зрения времени, что это имеет значение на основе рекомендаций, опубликованных Томасом. Но дело в том, что в общем случае призыв к геттеру не должен влиять на это состояние класса. У меня нет проблем с написанием getter, который на самом деле запускает вычисление при вызове.

Ответ 5

В общем, я пишу короткие, эффективные. Но у вас могут быть сложные - вам нужно подумать о том, как будет использоваться геттер. И если это внешний API, у вас нет никакого контроля над тем, как он используется - так стремитесь к эффективности.

Ответ 6

Я бы согласился с этим. Полезно иметь рассчитанные свойства, например, для таких вещей, как Age, основанный на DateOfBirth. Но я бы избегал сложной логики, например, нужно перейти в базу данных, чтобы вычислить значение свойства объекта. Используйте метод в этом случае.

Ответ 7

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

Но нет никаких ожиданий, установленных для вашей производительности получателя (возможно, попробуйте упомянуть об этом в документации кашля), поскольку это может быть попытка получить свежие значения из медленного источника. Другие, конечно же, рассматривают getter для простых объектов, но поскольку ваш объект может быть прокси-сервером для вашего backend-объекта, я действительно вижу не слишком точные ожидания производительности, поскольку он помогает сделать код более читабельным и более удобным.

Таким образом, мой ответ будет "зависит от", в основном, от уровня абстракции вашего объекта (короткая логика для объекта низкого уровня, поскольку значение, вероятно, должно быть рассчитано на уровне сеттера, длинные для верхнего уровня).