«Геттеры не должны включать большое количество логики».Правда или ложь?

Question

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

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

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

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

Answer 1

От MSDN :

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

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

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

А также :

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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