Java | Фишки и трюки

☕️ Интерфейсы в Java

В этом видео автор подробно разбирает, что такое интерфейсы в Java и чем они похожи на абстрактные классы. Вы узнаете об их ключевых отличиях, научитесь применять интерфейсы на практике и поймёте, в каких задачах они становятся незаменимым инструментом для создания гибкой и понятной архитектуры кода.

👉 Ссылка на первоисточник 🗣Запомни: интерфейсы — это контракты, которые определяют что должен делать класс, а не как. Это основа для написания слабосвязанного и тестируемого кода. 🤩 Java Фишки и трюки || #Видео

👩‍💻 Хватит учить только синтаксис, начинай делать реальные проекты! Python Ready — авторский канал, где Python перестаёт быть только теорией и становится рабочим инструментом. Мини-проекты, боты, советы, разборы задач, гайды и шпаргалки для каждого программиста. 🔥 Советую подписаться: @python_ready

📅 LocalDate и DateTimeFormatter: вечная путаница с YYYY и yyyy Каждый Новый год эта ошибка просыпается и незаметно портит данные в логах, отчётах и экспортах. Разница между YYYY и yyyy - всего одна буква, но она может сдвинуть дату на целый год вперёд или назад в первую неделю января. Вот как не попасть в эту ловушку и почему это происходит 👇 📁 Шаг 1: Наглядный пример ошибки (31 декабря 2024 года)

    
        DateTimeFormatter wrongFormatter = DateTimeFormatter.ofPattern("dd.MM.YYYY");
DateTimeFormatter correctFormatter = DateTimeFormatter.ofPattern("dd.MM.yyyy");

LocalDate date = LocalDate.of(2024, 12, 31);

System.out.println("Неправильно (YYYY): " + date.format(wrongFormatter));  
// 31.12.2025 ← вот он, сдвиг на год!
System.out.println("Правильно (yyyy):  " + date.format(correctFormatter)); 
// 31.12.2024{}
    

➡️ Да, 31 декабря 2024 года форматируется как... 2025 год. Это не баг, а фича, о которой мало кто знает. 📁 Шаг 2: В чём разница? (Год vs Год недели) - `yyyy` — это обычный календарный год (year-of-era). То, что мы все понимаем под годом. - `YYYY` — это год недели (week-based-year) по стандарту ISO 8601. ➡️ YYYY используется вместе с номером недели (ww) и днём недели (E). Он нужен для отображения года, к которому относится неделя, а не календарная дата. 📁 Шаг 3: Почему происходит сдвиг? (Магия первой недели года) По ISO 8601: 1. Неделя начинается с понедельника. 2. Первая неделя года — это неделя, содержащая первый четверг года. 3. Год недели (YYYY) — это год, к которому относится эта неделя.

    
        // Пример: 1 января 2025 года — это среда
LocalDate jan1 = LocalDate.of(2025, 1, 1);

System.out.println("Год недели: " + jan1.format(DateTimeFormatter.ofPattern("YYYY")));
// 2025 — потому что неделя (30 дек - 5 янв) содержит первый четверг 2025 года (2 января)

// А 30 декабря 2024 года — это понедельник, начало недели 1 (2025 года!)
LocalDate dec30 = LocalDate.of(2024, 12, 30);
System.out.println("Год недели: " + dec30.format(DateTimeFormatter.ofPattern("YYYY")));
// 2025 — потому что эта неделя (30 дек - 5 янв) содержит первый четверг 2025 года{}
    

➡️ Критические периоды: последние 3-4 дня декабря и первые 3-4 дня января. Именно здесь YYYY и yyyy чаще всего расходятся. 📁 Шаг 4: Где используется `YYYY` (правильно) Только вместе с номером недели!

    
        // Для отображения номера недели и года недели (отчёты, планирование)
DateTimeFormatter weekFormatter = DateTimeFormatter.ofPattern("'Неделя' ww, YYYY");
LocalDate date = LocalDate.of(2024, 12, 30);

System.out.println(date.format(weekFormatter));
// "Неделя 01, 2025" ← это правильно для систем, работающих по неделям{}
    

➡️ Используй YYYY только если ты точно понимаешь, что такое год недели, и используешь его с ww (номер недели). 📁 Шаг 5: Где НЕЛЬЗЯ использовать `YYYY` (опасные случаи) 1. Логирование — дата в логах внезапно станет 2025 годом 30 декабря. 2. Экспорт в CSV/Excel для отчётности. 3. Формирование имён файлов с датами. 4. Любые даты, которые потом будут парситься обратно.

    
        // ❌ Опасный парсинг (может сломаться)
String wrong = "31.12.2024";
LocalDate parsed = LocalDate.parse(wrong, DateTimeFormatter.ofPattern("dd.MM.YYYY"));
// Может выкинуть исключение или спарсить не ту дату{}
    

📁 Шаг 6: Как избежать ошибки навсегда 1. Используй готовые форматеры вместо ручных паттернов:

    
           DateTimeFormatter.ISO_LOCAL_DATE; // yyyy-MM-dd
   DateTimeFormatter.BASIC_ISO_DATE;  // yyyyMMdd
   {}
    

2. Пиши тесты на граничные даты:

    
           @Test
   void dateFormatting_aroundNewYear() {
       LocalDate dec30 = LocalDate.of(2024, 12, 30);
       LocalDate jan1 = LocalDate.of(2025, 1, 1);
       
       assertThat(dec30.format(DateTimeFormatter.ofPattern("dd/MM/yyyy")))
           .isEqualTo("30/12/2024");
       assertThat(jan1.format(DateTimeFormatter.ofPattern("dd/MM/yyyy")))
           .isEqualTo("01/01/2025");
   }
   {}
    

3. Включи в code review проверку всех DateTimeFormatter на наличие YYYY. 🗣️ Запомни: YYYY - это не опечатка, а отдельная концепция. Используй yyyy для всего, что связано с календарными датами. А YYYY оставь для отчётов по неделям.

Docker и Kubernetes: основы разработки под облачную инфраструктуру Курс для тех, кто хочет держать свой стэк и знания актуальными и глубоко разбираться, как устроены Docker, Kubernetes, и современная облачная инфраструктура в целом. 🌐 Чему вы научитесь: 🤩 Создавать облачную инфраструктуру «с нуля» управление и конфигурация серверов с Terraform, Ansible, cloud‑init 🤩 Уверенно работать с Docker: Dockerfile, слои, кэш, многоступенчатые сборки, реестры, безопасность, air‑gapped 🤩 Проектировать многоконтейнерные приложения: паттерны Sidecar, Ambassador, Adapter, проверки (liveness/readiness), DaemonSet и поды 🤩 Настраивать сеть и балансировку в Kubernetes ClusterIP, Services, Ingress, MetalLB, TLS/SNI, сервис‑меши (Istio) 🤩 Организовывать хранение данных: PersistentVolumes / PVC, StorageClasses, резервное копирование. Упаковка в Helm и поддержка через Operator 🥸 Кто мы: R&D-центр Devhands. Автор курса — Николай Ихалайнен, эксперт по СУБД и бекенду (ex-Percona), со-основатель MyDB, энтузиаст открытого ПО. 🗓 Старт курса: 25 февраля, 6 недель обучения. Изучить программу и записаться можно здесь. Ждем вас! Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2Vtzqvh26Qk

🧪 Тестируем приватные методы: хак или норма? (Спойлер: это запах) Тебе точно знакома ситуация: логика спрятана в приватном методе, а протестировать её «в лоб» нельзя. Первая мысль - рефлексия! Но это как использовать лом для починки часов. Сломаешь больше, чем починишь. Вот почему тестирование приватных методов - это сигнал о проблеме в дизайне класса, и как это исправить правильно 👇 🟢 Шаг 1: Типичный хак через рефлексию (как НЕ делать)

    
        import java.lang.reflect.Method;

public class Calculator {
    private int superSecretFormula(int a, int b) {
        return (a + b) * (a - b);
    }
}

// В тесте:
Method method = Calculator.class.getDeclaredMethod("superSecretFormula", int.class, int.class);
method.setAccessible(true); // Взламываем приватность
int result = (int) method.invoke(new Calculator(), 5, 3);{}
    

➡️ Проблемы: 🔴 Код теста становится хрупким: переименовал метод — тесты сломались. 🔴 Нарушается инкапсуляция. Тест теперь знает о внутренней кухне класса. 🔴 Это просто некрасиво. Рефлексия — это крик отчаяния. 🟢 Шаг 2: Почему это «запах» кода? Если метод настолько сложный, что его нужно тестировать отдельно — он, скорее всего, делает что-то самостоятельное. Возможно, он:

1. Выполняет несколько задач (нарушает SRP). 2. Содержит логику, которая может пригодиться где-то ещё. 3. Слишком умный для своего класса.

➡️ Частный метод — это деталь реализации. Тестировать нужно публичное поведение, а не приватные детали. 🟢 Шаг 3: Решение №1 — Вынеси логику в отдельный класс ❌Был:

    
        public class ReportService {
    public String generateReport() {
        // ... подготовка данных
        String cleaned = cleanData(rawData); // приватный метод
        // ... формирование отчёта
    }

    private String cleanData(String data) {
        // сложная логика очистки
    }
}{}
    

✔️Стал:

    
        // Новая публичная единица, которую легко тестировать
public class DataCleaner {
    public String clean(String data) {
        // та же логика, но теперь она публичная
    }
}

// В ReportService:
public class ReportService {
    private final DataCleaner cleaner;

    public String generateReport() {
        String cleaned = cleaner.clean(rawData);
        // ...
    }
}{}
    

➡️ Теперь DataCleaner можно и нужно тестировать напрямую. Это чистая архитектура. 🟢 Шаг 4: Решение №2 — Сделай метод package-private (если очень надо)

    
        // Было: private void helper() { ... }
// Стало (в том же пакете):
class Service {
    void helper() { ... } // без модификатора = виден в пакете
}

// В тестах (которые лежат в том же test/java/... пакете):
@Test
void testHelper() {
    Service service = new Service();
    service.helper(); // Доступно!
}{}
    

➡️ Компромиссный вариант. Логика всё ещё скрыта от внешнего мира, но доступна для тестов. Используй осторожно. 🟢 Шаг 5: Решение №3 — Тестируй через публичный метод Просто протестируй публичный метод, который использует этот приватный. Если покрытие кажется недостаточным — возможно, это повод задуматься: а нужен ли этот тест? Может, приватный метод настолько прост, что не требует отдельного теста?

    
        @Test
void generateReport_usesCleanDataLogic() {
    ReportService service = new ReportService();
    String report = service.generateReport();
    assertThat(report).contains("очищенные данные");
}{}
    

➡️ Ты тестируешь результат, а не реализацию. Это сильнее и надёжнее. 🗣️ Запомни: Рефлексия для тестов — как гаечный ключ в микросхеме. Если очень хочется протестировать приватное, значит, твой класс тайно просит, чтобы его разделили. Хороший дизайн рождает лёгкое тестирование.

📱Большинство Android-приложений ломаются не из-за UI, а из-за архитектуры. Неправильное разделение слоёв, хаотичная работа с API и логикой — и проект перестаёт масштабироваться уже на старте. На открытом вебинаре OTUS вы пройдёте полный путь создания Android-приложения: от работы с API сервера до отображения данных на экране. Разберём сетевое взаимодействие, получение данных из интернета и разложим приложение по слоям в рамках чистой архитектуры и MVVM. Этот урок — практическая точка входа в современную Android-разработку. Вы увидите, как связать API, бизнес-логику и UI в целостное приложение, которое легко поддерживать и развивать. 📆Встречаемся 24 февраля в 20:00 МСК в преддверии старта курса «Android Developer». Регистрация открыта: https://otus.pw/oQe2/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🪄 Магия @SneakyThrows в Lombok: как она обманывает компилятор Когда видишь @SneakyThrows, кажется, что нашёл волшебную палочку: checked-исключения больше не нужно объявлять в throws и ловить в try-catch. Но эта магия — не настоящее волшебство, а тонкая иллюзия, которая может сломать твой код в самый неподходящий момент. Давай заглянем под капот и узнаем, как эта аннотация обманывает компилятор, и почему с ней нужно быть осторожным 👇 🟢 Шаг 1: Как работают checked-исключения (обычный путь)

    
        // Без Lombok: нужно либо пробросить, либо поймать
public void readFile() throws IOException { // Объявляем throws
    Files.readAllBytes(Paths.get("file.txt"));
}

// Или так:
public void readFile() {
    try {
        Files.readAllBytes(Paths.get("file.txt"));
    } catch (IOException e) { // Ловим исключение
        throw new RuntimeException(e);
    }
}{}
    

➡️ Компилятор Java требует обработать checked-исключения (IOException, SQLException). Это проверка на этапе компиляции. 🟢 Шаг 2: Волшебство `@SneakyThrows` (как оно выглядит)

    
        import lombok.SneakyThrows;

public class FileReader {
    @SneakyThrows
    public byte[] readFile() {
        return Files.readAllBytes(Paths.get("file.txt"));
    }
}{}
    

➡️ Никакого throws, никакого try-catch! Код компилируется, и ты можешь вызывать метод, как будто исключений не существует. Но они никуда не делись. 🟢 Шаг 3: Как Lombok это делает (разоблачение фокуса) Компилятор Lombok преобразует код примерно вот во что:

    
        public byte[] readFile() {
    try {
        return Files.readAllBytes(Paths.get("file.txt"));
    } catch (IOException e) {
        throw Lombok.sneakyThrow(e); // Вот этот метод — ключ!
    }
}

// А метод sneakyThrow делает вот что:
public static RuntimeException sneakyThrow(Throwable t) {
    throw Lombok.<RuntimeException>sneakyThrow0(t);
}

@SuppressWarnings("unchecked")
private static <T extends Throwable> T sneakyThrow0(Throwable t) throws T {
    throw (T) t; // Кастование к unchecked-исключению!
}{}
    

➡️ Фокус в двойном касте! Lombok «притворяется», что кидает unchecked-исключение (RuntimeException), но на самом деле прокидывает оригинальное checked-исключение. JVM разрешает это, потому что стирание типов (type erasure) в generics скрывает реальный тип исключения. 🟢 Шаг 4: Чем это опасно? Проблема №1 — отсутствие декларации

    
        @SneakyThrows
public void connect() {
    Socket socket = new Socket("host", 9999); // Может кинуть IOException
    // ... работа с сокетом
}

// Где-то в другом месте:
public void init() {
    connect(); // Код не знает, что здесь возможен IOException!
    // И поэтому не готов его обработать
}{}
    

➡️ Контракт метода нарушен. Вызывающий код не знает, что метод может выбросить checked-исключение. Это сбивает с толку и ломает принцип явного объявления исключений. 🟢 Шаг 5: Проблема №2 — несовместимость с некоторыми конструкциями

    
        // Попробуем использовать в лямбде (Consumer)
list.forEach(element -> {
    @SneakyThrows
    Thread.sleep(100); // Так не сработает!
});

// Нужно отдельно выносить:
list.forEach(this::sneakySleep);

@SneakyThrows
private void sneakySleep(Object element) {
    Thread.sleep(100);
}{}
    

➡️ @SneakyThrows не работает прямо на лямбдах. Это ограничивает его применение. 🟢 Шаг 6: Когда это можно использовать (редкие случаи) 1. В тестах, где checked-исключения маловероятны и только мешают. 2. В реализациях интерфейсов, которые не объявляют исключений, но твоя реализация может их кидать (например, Runnable). 3. Для избежания излишнего обертывания в RuntimeException, когда ты точно уверен в поведении метода.

    
        // Пример с Runnable
public class Worker implements Runnable {
    @SneakyThrows
    @Override
    public void run() {
        Files.readAllBytes(Paths.get("config.json")); // IOException будет проброшен как unchecked
    }
}{}
    

➡️ Но даже здесь нужно понимать риски — исключение может «уплыть» и убить поток без возможности адекватной обработки. 🗣️ Запомни: @SneakyThrows - это не решение, а побег из тюрьмы checked-исключений через подкоп.