🔒 Раздел 13 · Вопрос #15

Можно ли наследоваться от иммутабельного класса

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

🔒 Иммутабельность 📄 Исходный Markdown

🟢 Junior Level

30-секундный ответ

С точки зрения синтаксиса компилятора Java, вы можете унаследоваться от класса, если разработчик забыл объявить его как final. Однако с точки зрения архитектуры и безопасности это грубейшая ошибка проектирования и критический антипаттерн.

Если класс не защищён от наследования:

  1. Класс-наследник может добавить собственные мутабельные поля и сеттеры.
  2. Класс-наследник может переопределить геттеры базового класса, возвращая динамически изменяемые или поддельные значения.
  3. В результате ссылка базового «иммутабельного» типа будет указывать на мутабельный объект, полностью разрушая потокобезопасность и предсказуемость программы.

Наглядный пример: Взлом неизменяемости через наследование

// ❌ ОШИБКА ДИЗАЙНА: разработчик забыл ключевое слово final
public class CurrencyAmount {
    private final long cents;

    public CurrencyAmount(long cents) {
        this.cents = cents;
    }

    public long getCents() {
        return cents;
    }
}

// 💥 Наследник превращает "иммутабельный" класс в бомбу замедленного действия:
public class MutableCurrencyAmount extends CurrencyAmount {
    private long extraBonusCents = 0;

    public MutableCurrencyAmount(long cents) {
        super(cents);
    }

    public void setExtraBonusCents(long bonus) {
        this.extraBonusCents = bonus; // Добавили сеттер!
    }

    @Override
    public long getCents() {
        // Ломаем инвариант детерминированности: значение меняется на лету!
        return super.getCents() + extraBonusCents;
    }
}

Наглядная аналогия из жизни

Представьте государственный паспорт:

  • Настоящий паспорт — строго неизменяемый документ.
  • Если разрешить свободное «наследование» паспорта, любой гражданин сможет вклеить в него дополнительные страницы с самодельными печатями и предъявлять фальшивку в банке под видом государственного документа.

🟡 Middle Level

Нарушение принципа подстановки Лисков (LSP)

Принцип подстановки Барбары Лисков (Liskov Substitution Principle — LSP) требует, чтобы любой подкласс мог использоваться вместо своего суперкласса без нарушения контракта и ожидаемого поведения программы.

Когда вызывающий код принимает параметр типа CurrencyAmount, он рассчитывает на инварианты неизменяемости:

  1. Вызов getCents() является чистой идемпотентной функцией и вернёт одно и то же число сегодня, завтра и через миллион вызовов.
  2. Объект можно безопасно передавать десяткам параллельных рабочих потоков без синхронизации и барьеров памяти.
  3. Значения hashCode() и equals() стабильны во времени — объект можно использовать как ключ HashMap.

Если в метод передать MutableCurrencyAmount:

  • Потоки получают состояние гонки (Data Race).
  • Кэши и коллекции HashMap безвозвратно теряют ключи из-за рассинхронизации хэш-кода.
  • Контракт LSP грубо нарушен.

2 законные альтернативы наследованию

1. Композиция вместо наследования (Effective Java, Item 18)

Вместо расширения чужого класса включите неизменяемый объект как приватное финальное поле:

public final class AuditedCurrencyAmount {
    private final CurrencyAmount amount; // Композиция
    private final String auditComment;

    public AuditedCurrencyAmount(CurrencyAmount amount, String auditComment) {
        this.amount = Objects.requireNonNull(amount);
        this.auditComment = Objects.requireNonNull(auditComment);
    }

    public CurrencyAmount getAmount() { return amount; }
    public String getAuditComment() { return auditComment; }
}

2. Приватный конструктор и статические фабрики

Если требуется создать семейство классов внутри пакета, но запретить внешнее наследование:

public class SecureToken {
    private final String value;

    // Конструктор закрыт: сторонний код не может вызвать super()
    private SecureToken(String value) {
        this.value = value;
    }

    public static SecureToken of(String value) {
        return new SecureToken(value);
    }
}

🔴 Senior Level

Запечатанные иерархии (Sealed Classes, Java 17+, JEP 409)

Если бизнес-архитектура действительно требует полиморфизма и дерева типов для неизменяемых структур (например, алгебраические типы данных ADT), в современном Java используют sealed интерфейсы и классы:

// Корневой контракт жестко ограничивает круг разрешенных реализаций:
public sealed interface OrderEvent permits OrderCreated, OrderCancelled, OrderShipped {}

// Все реализации объявляются как final или record (неявно final):
public record OrderCreated(String orderId, long timestamp) implements OrderEvent {}
public record OrderCancelled(String orderId, String reason) implements OrderEvent {}
public record OrderShipped(String orderId, String trackingNumber) implements OrderEvent {}

Преимущества:

  • Защита от чужих наследников: сторонний модуль или злоумышленник не имеет права создать свой подкласс MaliciousOrderEvent.
  • Exhaustive Pattern Matching (Java 21+): компилятор выполняет проверку исчерпываемости ветвей switch без блока default.

Оптимизации JIT C2: Class Hierarchy Analysis (CHA) и девиртуализация

Объявление класса как final напрямую влияет на машинный код, генерируемый компилятором HotSpot C2:

  • Когда метод вызывается у non-final класса, компилятор транслирует его в инструкцию invokevirtual.
  • C2-компилятор использует подсистему Class Hierarchy Analysis (CHA), чтобы проверить, сколько подклассов загружено в JVM.
  • Если класс объявлен как final, компилятор знает на 100%, что полиморфизм исключён. Он выполняет девиртуализацию (Devirtualization): вызов превращается в прямой безусловный переход (direct jump) или полный инлайнинг (inlining) тела метода.
  • Если же класс не final и у него появляются подклассы, JVM вынуждена использовать полиморфные таблицы виртуальных методов (vtable) или инлайн-кэши (Monomorphic/Polymorphic Inline Caches), что увеличивает нагрузку на конвейер процессора и ветвления (Branch Misprediction).

4 Tricky Questions

1. Как Class Hierarchy Analysis (CHA) в HotSpot C2 оптимизирует вызовы методов у final классов по сравнению с нефинальными?

Ответ: Для нефинальных классов компилятор C2 выполняет оптимистическую мономорфную девиртуализацию: если в данный момент в JVM загружен ровно один класс и нет активных подклассов, компилятор инлайнит метод, но устанавливает точку деоптимизации (uncommon trap). Если в рантайме динамически загрузится новый класс (через ClassLoader.loadClass()), наследующий данный метод, JVM будет вынуждена сбросить машинный код (deoptimization), вернуться в режим интерпретатора и перекомпилировать метод с полиморфным вызовом через таблицу vtable. Если класс объявлен как final, возможность появления подклассов исключена на уровне спецификации языка. Компилятор C2 навсегда инлайнит метод без установки точек деоптимизации, устраняя накладные расходы на виртуальный вызов и проверку загрузки классов.

2. Может ли абстрактный класс (abstract class) участвовать в проектировании иммутабельных структур данных? Как при этом защититься от внешних мутабельных подклассов?

Ответ: Да, абстрактный класс может содержать общее неизменяемое состояние и поведение (например, abstract class AbstractImmutableList<E>). Чтобы защититься от внешних мутабельных подклассов, используют паттерн Package-Private конструктора:

public abstract class AbstractDataNode {
    private final String id;

    // Пакетно-приватный конструктор: доступен только внутри этого пакета!
    AbstractDataNode(String id) {
        this.id = id;
    }
    public String getId() { return id; }
}

Код из внешних пакетов физически не сможет вызвать конструктор базового класса через super(), поэтому наследование извне пакета блокируется. В Java 17+ более элегантным и типобезопасным решением является public sealed abstract class ... permits SubA, SubB.

3. Что произойдёт, если класс-наследник переопределит методы equals() и hashCode(), включив в них мутабельные поля? Как это ломает HashSet?

Ответ: Если наследник добавит изменяемое поле state и переопределит hashCode() = super.hashCode() + state.hashCode(), то при модификации поля state хэш-код объекта изменится. Если этот объект уже был помещён в HashSet или в качестве ключа в HashMap:

  • Корзина (bucket), в которую он был положен изначально, рассчитывалась по старому хэш-коду.
  • При последующем вызове set.contains(obj) хэш-код вычисляется заново, и HashSet начинает искать объект в совершенно другой корзине.
  • Метод contains(obj) вернёт false, а метод remove(obj) не сможет его удалить. Объект навсегда зависнет в памяти кучи как скрытая утечка памяти.

4. Почему в Java разрешалось наследоваться от java.util.Date, и к каким уязвимостям безопасности в Java Security Manager это приводило?

Ответ: Класс java.util.Date был спроектирован в Java 1.0 без модификатора final и содержит мутабельные методы (setTime). Историческая уязвимость в SecurityManager: если системный код принимал Date validUntil для проверки срока действия сертификата или цифровой подписи, злоумышленник мог передать экземпляр вредоносного подкласса MaliciousDate extends Date:

  • Во время проверки прав метод getTime() возвращал корректную дату из прошлого (Time-of-Check).
  • В момент фактического выполнения операции подкласс возвращал дату из будущего или мутировал своё состояние (Time-of-Use). Именно поэтому во всей современной библиотеке java.time (JSR-310: LocalDate, Instant, ZonedDateTime) все без исключения классы объявлены строго как final.

🎯 Шпаргалка для интервью

Главное о наследовании от иммутабельных классов

  • Золотое правило: иммутабельный класс всегда обязан быть закрыт от наследования.
  • Как закрыть класс:
    1. Модификатор final у класса (стандартное решение).
    2. private конструкторы + статические фабричные методы.
    3. package-private конструктор (разрешает подклассы только внутри своего пакета).
    4. sealed класс/интерфейс (Java 17+, явный список наследников через permits).
  • Чем опасно наследование: подкласс может добавить сеттеры, переопределить геттеры, сломать контракт hashCode/equals и нарушить принцип LSP.
  • Производительность: final класс позволяет HotSpot C2 компилятору агрессивно инлайнить методы через девиртуализацию (CHA).

Красные флаги на собеседовании (Чего говорить нельзя)

  • ❌ «Наследоваться от иммутабельного класса абсолютно нормально, если не создавать в подклассе сеттеры» — подкласс может переопределить геттеры или добавить мутабельные поля.
  • ❌ «Модификатор final у классов — это плохой стиль, ограничивающий возможности ООП» — для классов значений (Value Objects) и неизменяемых типов final является обязательным требованием надёжности.
  • ❌ «В Java 17 Record может наследоваться от другого класса» — нет, record неявно наследуется от java.lang.Record и всегда является строго final.

Связанные вопросы