Что хотят услышать интервьюеры:

Да, технически можно, но это плохая практика, если логика тяжёлая или имеет побочные эффекты. Геттер должен быть простым, предсказуемым и быстрым. Дополнительная бизнес-логика внутри него часто ухудшает читаемость, тестируемость и может приводить к неожиданным багам.

Определение:

Метод получения значения свойства — это точка доступа к данным объекта. В нём допустимы простые вычисления, валидация или ленивое получение значения, если это не меняет состояние системы неожиданным образом. Если же внутри начинается сложная бизнес-логика, вызовы внешних сервисов, запись в БД или изменение других полей, такой геттер становится неявным источником побочных эффектов и нарушает принцип очевидности.

Пример использования:

Допустимо: вычислить отображаемое имя на основе уже загруженных данных.

class User:
    def __init__(self, first_name, last_name):
        self.first_name = first_name
        self.last_name = last_name

    @property
    def full_name(self):
        return f"{self.first_name} {self.last_name}"

Нежелательно: в геттере ходить в БД или считать скидку по сложным правилам.

class Order:
    @property
    def total(self):
        # плохо: скрытая бизнес-логика и возможные побочные эффекты
        discount = get_discount_from_service(self.user_id)
        return self.items_sum - discount

Пояснение кода:

В первом примере full_name — это удобное вычисляемое свойство: оно не меняет состояние объекта и зависит только от уже имеющихся полей. Такой подход обычно приемлем.

Во втором примере total выглядит как обычное свойство, но фактически может:

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

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

Ключевые моменты:

Геттер должен быть простым, быстрым и предсказуемым.
Допустимы только лёгкие вычисления без побочных эффектов.
Сложная бизнес-логика в геттере ухудшает поддержку и тестирование.
Запросы к БД, сети, файловой системе и изменение состояния лучше выносить в методы.
Если поведение важное и неочевидное, его нужно делать явным через название метода.

Можно ли вставлять дополнительную бизнес-логику внутри метода получения значения свойства?