PrepBro
← Назад к вопросам

Можно ли изменять данные в get методе?

1.6 Junior🔥 201 комментариев
#REST API и микросервисы

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI22 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Можно ли изменять данные в get методе?

Краткий ответ

Технически можно, но НЕЛЬЗЯ делать это! Изменение данных в getter нарушает принцип наименьшего удивления (Principle of Least Surprise) и нарушает контракт метода, приводя к багам и неопредсказуемому поведению.

Почему getter не должен изменять состояние?

1. Нарушение контракта

Геттер по определению — это читающий метод, который не должен иметь побочных эффектов:

public class User {
    private int loginCount = 0;
    private LocalDateTime lastLogin;
    
    // ✗ ПЛОХО: getter изменяет состояние
    public String getName() {
        loginCount++;                    // изменение данных!
        lastLogin = LocalDateTime.now(); // побочный эффект!
        return name;
    }
    
    // ✓ ХОРОШО: getter только читает
    public String getName() {
        return name;
    }
    
    // Для побочных эффектов - отдельный метод
    public void recordLogin() {
        loginCount++;
        lastLogin = LocalDateTime.now();
    }
}

Означение getter вызывается непредсказуемо часто:

  • В IDE при просмотре объекта в отладчике
  • При сериализации
  • В логировании
  • При проверке условий
User user = new User();

// Сколько раз вызовется getName()?
if (user.getName().equals("John")) {
    // ...
}

// В отладчике просто наведёшь мышку на переменную - вызовется getter!
// Это изменит состояние! Отладка станет невозможной.

2. Проблемы с потокобезопасностью

public class CachedData {
    private String cachedValue;
    private long cacheTime;
    private static final long CACHE_TTL = 60_000; // 1 минута
    
    // ✗ ОПАСНО: изменение кеша в getter без синхронизации
    public String getValue() {
        if (System.currentTimeMillis() - cacheTime > CACHE_TTL) {
            cachedValue = fetchFromSource(); // Race condition!
            cacheTime = System.currentTimeMillis();
        }
        return cachedValue;
    }
    
    // Несколько потоков вызовут getValue() одновременно:
    // Thread 1: читает cacheTime, видит что кеш старый
    // Thread 2: читает cacheTime, видит что кеш старый
    // Thread 1: перезаписывает cachedValue
    // Thread 2: перезаписывает cachedValue  <- inconsistent state!
    // Оба потока делают дорогую операцию fetchFromSource()
}

3. Невозможность использования в потоках обработки

User user = new User();

// Stream операции предполагают, что getter не меняет состояние
List<String> names = users.stream()
    .map(User::getName)      // вызовется getName()
    .filter(name -> name.length() > 3)
    .collect(toList());

// Если getName() изменяет состояние - результат непредсказуем!
// Порядок обработки в stream может быть параллельным

4. Проблемы с кешированием и оптимизацией JVM

public class Counter {
    private int value = 0;
    
    // ✗ ПЛОХО: getter с побочным эффектом
    public int getValue() {
        return ++value;  // изменяет состояние
    }
}

// JVM оптимизирует чтение одного поля
Counter counter = new Counter();
int a = counter.getValue();  // возвращает 1, value = 1
int b = counter.getValue();  // возвращает 2, value = 2
int c = counter.getValue();  // возвращает 3, value = 3

// Но если JVM поймёт, что getValue() только читает,
// она может кешировать результат и не вызывать метод заново!
// Поведение станет непредсказуемым

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

Пример 1: Ленивая инициализация

public class User {
    private String email;
    private Email emailObject; // дорогой объект
    
    // ✗ ПЛОХО: инициализация в getter
    public Email getEmail() {
        if (emailObject == null) {
            emailObject = new Email(email);  // изменение состояния!
        }
        return emailObject;
    }
    
    // ✓ ХОРОШО: явный метод инициализации
    public void initializeEmail() {
        if (emailObject == null) {
            emailObject = new Email(email);
        }
    }
    
    public Email getEmail() {
        return emailObject;
    }
    
    // ИЛИ использовать synchronized для потокобезопасности
    public synchronized Email getEmailSafely() {
        if (emailObject == null) {
            emailObject = new Email(email);
        }
        return emailObject;
    }
}

Пример 2: Логирование и метрики

public class BankAccount {
    private BigDecimal balance;
    private int accessCount = 0;
    
    // ✗ ПЛОХО: логирование в getter
    public BigDecimal getBalance() {
        accessCount++;                  // изменение!
        log.info("Balance accessed {} times", accessCount);
        return balance;
    }
    
    // ✓ ХОРОШО: отдельные методы для логирования
    public BigDecimal getBalance() {
        return balance;
    }
    
    public int getAccessCount() {
        return accessCount;
    }
    
    // Или использовать AOP/Decorator для перехвата вызовов
    @Monitored  // аннотация AOP
    public BigDecimal getBalance() {
        return balance;
    }
}

Пример 3: Слежение за изменениями (Observer Pattern)

public class ObservableValue<T> {
    private T value;
    private List<Consumer<T>> listeners = new ArrayList<>();
    
    // ✗ ПЛОХО: триггер событий в getter
    public T getValue() {
        listeners.forEach(l -> l.accept(value));  // изменение состояния!
        return value;
    }
    
    // ✓ ХОРОШО: явные методы для подписки и уведомления
    public T getValue() {
        return value;
    }
    
    public void setValue(T newValue) {
        this.value = newValue;
        notifyListeners();  // явное уведомление
    }
    
    private void notifyListeners() {
        listeners.forEach(l -> l.accept(value));
    }
    
    public void subscribe(Consumer<T> listener) {
        listeners.add(listener);
    }
}

Исключения: когда можно менять данные в getter

1. Ленивая инициализация с синхронизацией (Lazy Initialization)

public class ExpensiveResource {
    private volatile byte[] largeArray;
    
    public byte[] getLargeArray() {
        if (largeArray == null) {
            synchronized (this) {
                if (largeArray == null) {  // Double-checked locking
                    largeArray = new byte[10_000_000];
                }
            }
        }
        return largeArray;
    }
}

2. Кеширование с явным контрактом

public interface CachedData<T> {
    T getOrCompute();  // контракт явно указывает на возможные побочные эффекты
}

public class ComputedValue implements CachedData<Integer> {
    private Integer cached;
    
    @Override
    public Integer getOrCompute() {
        if (cached == null) {
            cached = expensiveComputation();
        }
        return cached;
    }
}

3. Метрики и мониторинг (через AOP)

// Используй Aspect-Oriented Programming вместо прямого изменения в getter
@Aspect
public class MonitoringAspect {
    @Around("@annotation(Monitored)")
    public Object monitor(ProceedingJoinPoint pjp) throws Throwable {
        metrics.incrementAccessCount();
        long start = System.currentTimeMillis();
        try {
            return pjp.proceed();
        } finally {
            metrics.recordDuration(System.currentTimeMillis() - start);
        }
    }
}

public class User {
    @Monitored
    public String getName() {
        return name;  // getter не знает о мониторинге
    }
}

Лучшие практики

public class GoodExample {
    private String value;
    private LocalDateTime lastModified;
    private int readCount = 0;
    
    // ✓ Чистый getter - только читает
    public String getValue() {
        return value;
    }
    
    // ✓ Явный setter для изменения
    public void setValue(String newValue) {
        this.value = newValue;
        this.lastModified = LocalDateTime.now();
    }
    
    // ✓ Отдельный метод для логирования доступа
    public String getValueWithLogging() {
        readCount++;
        return value;
    }
    
    // ✓ Query методы без побочных эффектов
    public int getReadCount() {
        return readCount;
    }
    
    public LocalDateTime getLastModified() {
        return lastModified;
    }
}

Принципы Command Query Responsibility Segregation (CQRS)

Этот принцип явно разделяет:

  • Queries (getters) - читают состояние, БЕЗ побочных эффектов
  • Commands (setters) - изменяют состояние
public class CQRSExample {
    private String state;
    
    // Query - только читает
    public String getState() {
        return state;
    }
    
    // Command - изменяет
    public void setState(String newState) {
        this.state = newState;
        // побочные эффекты здесь
    }
}

Итог

❌ НЕ делай в getter:

  • Изменение полей объекта
  • Побочные эффекты
  • Побочные вызовы методов
  • Логирование, которое влияет на состояние
  • Инициализацию (кроме ленивой с синхронизацией)

✅ Делай в getter:

  • Только читай данные
  • Возвращай значение
  • Для побочных эффектов - создавай отдельные методы

Это делает код предсказуемым, потокобезопасным и легким в тестировании.

Можно ли изменять данные в get методе? | PrepBro