Можно ли менять значение переменной effectively final внутри объекта?

Ответ на вопрос об effectively final переменных

Можно ли менять значение effectively final переменной?

Нет, нельзя менять значение effectively final переменной ни в каком контексте, включая внутри объекта. Это ключевое ограничение Java, которое требует понимания концепции и её целей.

Что такое effectively final?

Effectively final - это переменная, которая:

• Не объявлена как final, но
• Никогда не изменяется после инициализации

Java компилятор автоматически определяет такие переменные и применяет те же ограничения, что и для явно объявленных final.

public void demo() {
    int x = 10;  // effectively final - не меняется дальше
    
    // Использование в lambda (разрешено)
    Runnable r = () -> System.out.println(x);  // ✅ OK
    
    // Попытка изменить (запрещено)
    x = 20;  // ❌ ОШИБКА: Variable used in lambda expression should be final or effectively final
}

Почему это ограничение существует?

1. Семантика замыканий (Closures)

public class CounterExample {
    public static void main(String[] args) {
        int counter = 0;  // effectively final
        
        Runnable r1 = () -> System.out.println("Counter: " + counter);
        Runnable r2 = () -> System.out.println("Another: " + counter);
        
        // Проблема: какое значение должны видеть lambdas?
        // counter = 5;  // ❌ ОШИБКА!
        
        r1.run();  // Counter: 0
        r2.run();  // Another: 0
    }
}

Если бы переменная была изменяемой, возникало бы множество проблем:

• Какое значение захватить - текущее или будущее?
• Что будет, если переменную изменить после создания lambda?
• Разные потоки видят разные значения?

2. Захват значения, а не ссылки

Java захватывает значение переменной, а не её ссылку:

public void example() {
    int value = 10;  // effectively final
    
    // Lambda захватывает значение 10
    Function<Integer, Integer> add = (x) -> x + value;
    
    System.out.println(add.apply(5));  // 15
    
    // Если бы мы могли изменить value, что происходит с lambda?
    // value = 20;  // ❌ Не разрешено
}

Случай 1: Переменная - объект (mutable object)

Здесь часто возникает путаница:

public void mutableObjectExample() {
    List<String> list = new ArrayList<>();  // effectively final
    list.add("Hello");  // ✅ РАЗРЕШЕНО - меняем содержимое объекта
    
    Runnable r = () -> System.out.println(list);  // ✅ OK
    
    // Но переассигнить переменную нельзя:
    // list = new ArrayList<>();  // ❌ ОШИБКА!
}

Ключевая разница:

• ✅ Менять содержимое объекта (list.add(), obj.setName()) - разрешено
• ❌ Менять саму переменную (переассигнить) - запрещено

Случай 2: Поле класса (field) vs Локальная переменная

В методе (локальная переменная):

public void localVarExample() {
    int x = 10;  // effectively final
    
    // Использование в lambda
    Supplier<Integer> supplier = () -> x * 2;  // ✅ OK
    
    // Изменение не допускается
    x = 20;  // ❌ ОШИБКА при использовании в lambda!
}

Поле класса - NO effectively final:

public class Example {
    private int value = 10;  // Поле класса, НЕ effectively final
    
    public void method() {
        // Используем в lambda
        Runnable r = () -> System.out.println(this.value);  // ✅ OK
        
        // Меняем поле
        this.value = 20;  // ✅ РАЗРЕШЕНО! Это не effectively final
        
        r.run();  // Выведет 20
    }
}

Почему разница?

• Lambda захватывает this (ссылку на объект)
• this.value вычисляется каждый раз
• Если значение поля меняется, lambda видит новое значение

Случай 3: Параметры метода

Параметры по умолчанию effectively final:

public void parameterExample(int value) {
    // value - effectively final в контексте lambda
    
    Runnable r = () -> System.out.println(value);  // ✅ OK
    
    // Но если попытаться изменить параметр:
    // value = 20;  // ❌ ОШИБКА!
}

Обойти ограничение? Да, есть способ!

Обёртка в изменяемый контейнер:

public void workaround() {
    // Вместо простой переменной используем массив или контейнер
    int[] valueHolder = {10};  // effectively final переменная
    
    Runnable r = () -> System.out.println("Value: " + valueHolder[0]);
    
    // Изменяем содержимое, не саму переменную
    valueHolder[0] = 20;  // ✅ РАЗРЕШЕНО
    
    r.run();  // Value: 20
}

// Или через класс-обёртку:
public class MutableInt {
    public int value;
    
    public MutableInt(int value) {
        this.value = value;
    }
}

public void wrapperExample() {
    MutableInt num = new MutableInt(10);  // effectively final переменная
    
    Runnable r = () -> System.out.println("Num: " + num.value);
    
    num.value = 20;  // ✅ РАЗРЕШЕНО
    r.run();  // Num: 20
}

Практический пример: Event Listener

public class EventListenerExample {
    public static void main(String[] args) {
        List<Runnable> listeners = new ArrayList<>();
        
        int eventId = 100;  // effectively final
        String eventName = "CLICK";  // effectively final
        
        // Добавляем listener
        listeners.add(() -> {
            System.out.println("Event: " + eventName + " (" + eventId + ")");
        });
        
        // Запускаем
        for (Runnable listener : listeners) {
            listener.run();  // Event: CLICK (100)
        }
        
        // Если попытаться изменить переменные:
        // eventId = 200;  // ❌ ОШИБКА
        // eventName = "SCROLL";  // ❌ ОШИБКА
    }
}

Взаимодействие с внутренними классами

Внутренний класс тоже требует effectively final:

public void innerClassExample() {
    int value = 10;  // effectively final
    
    class InnerClass {
        public void print() {
            System.out.println(value);  // ✅ Захватывает значение
        }
    }
    
    // value = 20;  // ❌ ОШИБКА - нарушает effectively final
    
    new InnerClass().print();  // 10
}

Резюме

• effectively final - переменная, не изменяемая после инициализации
• Нельзя менять - ни в lambda, ни во внутренних классах
• Разница в контекстах:
  • Локальные переменные: effectively final
  • Поля класса: можно менять
  • Содержимое объекта: можно менять
• Причина: Семантика замыканий и предсказуемость кода
• Обход: использовать массивы или объекты-обёртки
• Best Practice: избегать сложной логики с обёртками, использовать поля класса если нужна изменяемость