Гибкие тела конструкторов в Java 25
→ Одна из самых заметных фич, введённых в Java 25.
→ Основная идея: ослабить строгие правила, согласно которым super(...) или this(...) обязательны как первая инструкция в конструкторе.
→ А что, если нужно что-то сделать с аргументами перед передачей их суперклассу?
Допустим, мы хотим проверить число перед вызовом super(). Раньше это было невозможно, так как Java строго требовала, чтобы первой строкой любого конструктора был вызов другого конструктора в том же классе (this(...)) или конструктора суперкласса (super(...)).
В приведённом примере:
→ До Java 25, если конструктору PositiveNumber нужно было передать val в его суперкласс BaseNumber (который требует val в конструкторе), super(val) должен был быть первой строкой. Любой код перед super() приводил к ошибке: "super() должен быть первой инструкцией".
→ Отложенная проверка: В примере мы не могли проверить val до его использования для инициализации BaseNumber, что нарушало принцип "fail-fast". Если val = -1, BaseNumber всё равно инициализировался с -1, прежде чем PositiveNumber мог бы выбросить ошибку.
→ Неуклюжие обходные пути: Чтобы проверить аргумент заранее, приходилось использовать менее читаемые схемы (например, super(staticMethodForValidation(val))) или сложную делегацию конструкторов.
⇒ С Java 25
→ Теперь Java 25 понимает, что подготовительная работа, такая как проверка аргументов, логически относится к обязанностям конструктора и может (и должна) выполняться до инициализации состояния суперкласса.
→ Настоящая проверка "fail-fast": Если val = -1, IllegalArgumentException выбрасывается до вызова super(val), конструктор BaseNumber не выполняется с некорректным значением, и создание объекта прерывается на раннем этапе.
→ Более безопасное создание объектов: Суперкласс инициализируется только с корректными, предварительно обработанными аргументами, что делает объекты более надёжными и безопасными.
👉 Java Portal
→ Одна из самых заметных фич, введённых в Java 25.
→ Основная идея: ослабить строгие правила, согласно которым super(...) или this(...) обязательны как первая инструкция в конструкторе.
→ А что, если нужно что-то сделать с аргументами перед передачей их суперклассу?
Допустим, мы хотим проверить число перед вызовом super(). Раньше это было невозможно, так как Java строго требовала, чтобы первой строкой любого конструктора был вызов другого конструктора в том же классе (this(...)) или конструктора суперкласса (super(...)).
В приведённом примере:
→ До Java 25, если конструктору PositiveNumber нужно было передать val в его суперкласс BaseNumber (который требует val в конструкторе), super(val) должен был быть первой строкой. Любой код перед super() приводил к ошибке: "super() должен быть первой инструкцией".
→ Отложенная проверка: В примере мы не могли проверить val до его использования для инициализации BaseNumber, что нарушало принцип "fail-fast". Если val = -1, BaseNumber всё равно инициализировался с -1, прежде чем PositiveNumber мог бы выбросить ошибку.
→ Неуклюжие обходные пути: Чтобы проверить аргумент заранее, приходилось использовать менее читаемые схемы (например, super(staticMethodForValidation(val))) или сложную делегацию конструкторов.
⇒ С Java 25
→ Теперь Java 25 понимает, что подготовительная работа, такая как проверка аргументов, логически относится к обязанностям конструктора и может (и должна) выполняться до инициализации состояния суперкласса.
→ Настоящая проверка "fail-fast": Если val = -1, IllegalArgumentException выбрасывается до вызова super(val), конструктор BaseNumber не выполняется с некорректным значением, и создание объекта прерывается на раннем этапе.
→ Более безопасное создание объектов: Суперкласс инициализируется только с корректными, предварительно обработанными аргументами, что делает объекты более надёжными и безопасными.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤2