🔍 Ответ на задачу про логические операторы

Давайте разберем работу логических операторов в данном коде на Java. У нас есть три логические переменные: a, b, и c, со значениями true, false, и false соответственно. В условии if используется комбинация операторов (логическое "ИЛИ") и && (логическое "И").

Стоит помнить, что оператор && имеет более высокий приоритет, чем оператор . Поэтому выражение b && c будет вычислено первым. Но поскольку b равно false, а c также false, это выражение дает в результате false.

Далее, выражение a false будет всегда истинным, так как a равно true. Следовательно, полное условие в if равно true, и будет выполнена первая ветка блока:

1

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

boolean a = true;
boolean b = false;
boolean c = false;

if (a || (b && c)) {
    System.out.println("1");
} else {
    System.out.println("2");
} 

Скобки вокруг выражения (b && c) четко определяют, что это будет вычислено в первую очередь. Это не только делает код более понятным, но и исключает возможность неправильной интерпретации, особенно если у вас большой и сложный условный оператор.

Используйте скобки в логических выражениях, чтобы код был читаемым как для вас, так и для вашей команды! Рекомендуется всегда группировать логические операции скобками, если существует вероятность появления неоднозначности.

✍️ Научитесь писать чистый и понятный код! Поддержите эту идею, поставив лайк, подписывайтесь на канал и оставляйте комментарии с вашими мыслями об использовании скобок в коде.

#java #logicaloperators #boolean #clean_code #java_interview_tasks

🔍 Ответ на задачу про Optional: Почему orElse может тормозить ваш код? 🐢

Использование Optional — это стандарт де-факто в современном Java-коде. Но знаете ли вы разницу между orElse() и orElseGet()? Ошибка здесь может привести к лишним вызовам методов и даже к падению производительности.

Задача: Что произойдет, если вызвать orElse() для метода, который делает тяжелую операцию (например, запрос в БД), даже если значение в Optional уже есть?
Объяснение: orElse(T other) принимает готовый объект. Это значит, что аргумент вычисляется до вызова метода orElse. Даже если Optional не пустой, getDefaultValue() будет выполнен! orElseGet(Supplier<? extends T> other) принимает лямбду (Supplier). Она выполняется только тогда, когда Optional действительно пуст (ленивые вычисления).

Вывод: В примере выше на консоль выведется "Вызов тяжелого метода!", хотя значение "Hello" уже есть. Если бы мы использовали optional.orElseGet(() -> getDefaultValue()), лишнего вызова бы не было.

⚡️ Не перепутайте:
Используйте orElse(), если у вас уже есть готовая константа или примитив.
Используйте orElseGet(), если получение дефолтного значения требует вычислений или создания нового объекта.

Понравился разбор? Ставь ❤️, подписывайся и пиши в комментариях, какие ещё методы Optional тебя путают!

 #java #optional #performance #clean_code #backend #интервью #java_interview_tasks

🔍 Ответ на задачу про try-with-resources: Куда делось исключение? 🛡
В try-with-resources основным считается исключение, возникшее в блоке try. Если при автоматическом закрытии ресурсов тоже возникнет исключение, оно не затрет основное, а будет добавлено в список "подавленных" (доступно через e.getSuppressed()).

Вывод:
Метод getMessage() вернет только основное исключение — "Try Error".

⚡️ Не перепутайте:
В старом стиле (через finally) исключение из finally могло "проглотить" исключение из try. Try-with-resources решает эту проблему.

#java #exceptions #trywithresources #suppressed #clean_code #интервью #java_interview_tasks

🔍 Ответ на задачу про Iterator.remove(): Чистим коллекцию правильно 🧹
- Вариант A (for-each) использует итератор неявно. Если мы вызываем list.remove() напрямую, итератор об этом не знает и при следующей проверке modCount выбросит ConcurrentModificationException.
- Вариант B использует iterator.remove(). Этот метод специально спроектирован для безопасного удаления текущего элемента во время итерации.

Вывод:
Верный вариант — B. (Хотя есть исключение: в ArrayList удаление предпоследнего элемента через list.remove() в for-each может не вызвать ошибку из-за бага/особенности проверки hasNext(), но полагаться на это нельзя).

⚡️ Не перепутайте:
В Java 8+ самый простой и безопасный способ: list.removeIf(s -> s.equals("A")).

#java #collections #iterator #bug #clean_code #интервью #java_interview_tasks

🔍 Ответ на задачу про Static:

Статические методы привязаны к классу, а не к объекту. В Java нет полиморфизма для статики. Это называется method hiding. Какой метод вызовется, определяется типом переменной во время компиляции, а не типом объекта во время выполнения.

Вывод:
Так как переменная obj имеет тип A, вызовется A.staticMethod(). Результат: "A".

⚡️ Не перепутайте:
Никогда не вызывайте статические методы через экземпляры объектов (obj.method()). Всегда пишите ClassName.method(), чтобы не вводить в заблуждение.

#java #static #inheritance #basics #clean_code #интервью #java_interview_tasks

🔍 Ответ на задачу про PECS: Producer Extends, Consumer Super 🦆
Это правило PECS:
- Producer Extends: Если коллекция "производит" данные (мы из нее читаем), используйте extends. Мы гарантируем, что там лежат объекты типа T или его наследники, поэтому их безопасно приводить к T.
- Consumer Super: Если коллекция "потребляет" данные (мы в нее пишем), используйте super. Мы можем безопасно положить туда T. Но при чтении мы получим только Object, так как не знаем реального типа.

Вывод:
Верна только строка A.

⚡️ Не перепутайте:
List<? extends T> — только для чтения.
List<? super T> — в основном для записи.

#java #generics #pecs #clean_code #интервью #java_interview_tasks