📌 Как правильно писать equals и hashCode в Java?

Сейчас разберем один из самых частых вопросов у Java-разработчиков: как правильно переопределять equals() и hashCode()?

Эти методы нужны для корректного сравнения объектов и работы коллекций (`HashMap`, HashSet, HashTable и т. д.). Неправильная реализация может привести к неожиданным багам, которые трудно отловить.

✅ Основные правила для equals()
1️⃣ Рефлексивность – x.equals(x) должно всегда возвращать true.
2️⃣ Симметричность – x.equals(y) должно возвращать тот же результат, что и y.equals(x).
3️⃣ Транзитивность – если x.equals(y) и y.equals(z), то x.equals(z).
4️⃣ Стабильность – если объекты не менялись, результат вызова equals() не должен меняться.
5️⃣ Не null – x.equals(null) всегда должен возвращать false.

Пример корректного equals():

@Override
public boolean equals(Object obj) {
    if (this == obj) return true;
    if (obj == null || getClass() != obj.getClass()) return false;
    MyClass myClass = (MyClass) obj;
    return Objects.equals(field1, myClass.field1) &&
           Objects.equals(field2, myClass.field2);
}

✅ Основные правила для hashCode()
🔹 Если equals() возвращает true, то hashCode() должен быть одинаковым.
🔹 Если equals() возвращает false, то hashCode() может быть одинаковым, но лучше минимизировать коллизии.
🔹 hashCode() должен быть быстрым и эффективно распределять объекты.

Пример hashCode():

@Override
public int hashCode() {
    return Objects.hash(field1, field2);
}

❌ Частые ошибки
🚫 Использование == вместо equals() для объектов.
🚫 Неопределенный hashCode(), из-за чего HashMap работает некорректно.
🚫 Изменяемые поля в hashCode() – при изменении объекта он может потеряться в HashMap.

Используйте Objects.equals() и Objects.hash(), чтобы избежать рутины!

📢 Как вы реализуете equals() и hashCode()? Были ли у вас баги из-за их неправильной работы? Делитесь в комментариях!

📲 Мы в MAX

👉@BookJava

🔥 Приглашаем на бесплатный открытый вебинар курса «Высоконагруженные системы: архитектура и масштабирование»:

«Polyglot Persistence: как современные системы живут с десятками баз данных»

🗓 Когда: 2 июня, 20:00 (мск)

Одной базы данных уже давно недостаточно. Современные высоконагруженные системы — это сложная экосистема из разных хранилищ, каждое из которых решает свою задачу.

На вебинаре разберём, как грамотно сочетать PostgreSQL, ClickHouse, Redis, Kafka и Elasticsearch, чтобы система оставалась быстрой, согласованной и отказоустойчивой.

Что будет на вебинаре:
— Принципы Polyglot Persistence и роль каждой базы в современной архитектуре
— Как связать PostgreSQL, ClickHouse, Redis и Kafka без потери согласованности данных
— Event-driven подход, CDC и Outbox-паттерн в высоконагруженных системах
— Архитектурные приёмы построения надёжных data-платформ, способных выдерживать миллионы операций

Кому будет полезно:
— Backend-разработчикам, желающим понимать устройство современных систем
— Архитекторам и DevOps-инженерам, решающим задачи масштабирования и согласованности
— Всем, кто работает с большими данными и хочет эффективно комбинировать разные типы хранилищ

👉 Зарегистрироваться: https://vk.cc/cYcSEc

Бесплатное занятие приурочено к курсу «Highload Architect», на котором вы научитесь проектировать сложные высоконагруженные системы, грамотно выбирать и сочетать технологии хранения и обработки данных.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Java springboot
Совет: Нужно быстро собрать разрозненные данные в POST-запросе?

Просто создайте встроенную record в вашем
@RestController и используйте её как @RequestBody.

Не нужно определять DTO в отдельном классе – record будет видна только внутри этого контроллера. 🚀

📲 Мы в MAX

👉@BookJava

🚀 Подборка полезных IT каналов в Max


Системное администрирование, DevOps 📌

https://max.ru/i_odmin Все для системного администратора
https://max.ru/bash_srv Bash Советы
https://max.ru/sysadminof Книги для админов, полезные материалы
https://max.ru/i_odmin_book Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.
https://max.ru/tipsysdmin Типичный Сисадмин

Excel лайфхак 📌
https://t.me/Excel_lifehack Excel лайфхак

1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С

Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика

Программирование Go📌
https://max.ru/golang_lib Библиотека Go (Golang) разработчика

Программирование React📌
https://max.ru/react_lib React

Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика

Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика

GitHub Сообщество 📌
https://max.ru/githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://max.ru/database_info Все про базы данных

Фронтенд разработка 📌
https://max.ru/frontend_1 Подборки для frontend разработчиков

Библиотеки 📌
https://max.ru/programmist_of Книги по программированию
https://max.ru/proglb Библиотека программиста
https://max.ru/bfbook Книги для программистов

Программирование 📌
https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций
https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT
https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻

Шутки программистов 📌
https://max.ru/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://max.ru/thehaking Канал о кибербезопасности
https://max.ru/xakkep_1 Хакер Free

Книги, статьи для дизайнеров 📌
https://max.ru/odesigners Статьи, книги для дизайнеров

Математика 📌
https://max.ru/Pomatematike Канал по математике
https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике

Вакансии 📌
https://max.ru/progjob Вакансии в IT

Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных


Бонус 📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы
https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП

🛠️ SOLID: Почему важно соблюдать принципы?

Сегодня поговорим о SOLID – пяти принципах, которые делают код понятным, гибким и легким для поддержки. Если ты хочешь писать код, который не треснет по швам через пару месяцев, эти принципы — твои лучшие друзья.

1. Single Responsibility Principle (SRP)
Одна ответственность – один класс.
Если у класса больше одной причины измениться, значит, он нарушает SRP. Такой код сложно поддерживать, потому что при изменении одной логики мы можем случайно сломать другую.

✅ Правильно:

class ReportGenerator {
    void generateReport() { /* Логика генерации отчета */ }
}

class ReportSaver {
    void saveReport() { /* Логика сохранения отчета */ }
}

❌ Неправильно (всё в одном месте):

class ReportService {
    void generateAndSaveReport() { /* Генерация + сохранение отчета */ }
}

2. Open/Closed Principle (OCP)
Код открыт для расширения, но закрыт для модификации.
Когда нам нужно добавить новую функциональность, мы должны расширять существующий код, а не менять его.

✅ Пример с интерфейсом:

interface Payment {
    void process();
}

class CreditCardPayment implements Payment {
    public void process() { /* Логика оплаты картой */ }
}

class PayPalPayment implements Payment {
    public void process() { /* Логика оплаты PayPal */ }
}

Теперь мы можем добавить новый способ оплаты, просто создав новый класс.

3. Liskov Substitution Principle (LSP)
Дочерние классы должны полностью заменять родительские.
Если где-то используется родительский класс, мы должны без проблем подставить его потомка.

❌ Нарушение LSP:

class Bird {
    void fly() { /* Летает */ }
}

class Penguin extends Bird {
    void fly() { throw new UnsupportedOperationException("Пингвины не летают!"); }
}

Проблема в том, что Penguin нарушает контракт родителя.

✅ Используем интерфейсы:

interface Bird { }
interface FlyingBird extends Bird { void fly(); }

class Sparrow implements FlyingBird {
    public void fly() { /* Летает */ }
}

class Penguin implements Bird {
    // Пингвин вообще не имеет метода fly()
}

4. Interface Segregation Principle (ISP)
Лучше несколько маленьких интерфейсов, чем один большой.

❌ Плохой пример:

interface Worker {
    void work();
    void eat();
}

class Robot implements Worker {
    public void work() { /* Работает */ }
    public void eat() { throw new UnsupportedOperationException("Роботы не едят!"); }
}

✅ Разделяем интерфейсы:

interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

class Robot implements Workable {
    public void work() { /* Работает */ }
}

5. Dependency Inversion Principle (DIP)
Модули верхнего уровня не должны зависеть от модулей нижнего уровня.
Оба должны зависеть от абстракций.

❌ Жёсткая зависимость:

class Lamp {
    void turnOn() { /* Включить */ }
}

class Switch {
    private Lamp lamp;

    Switch(Lamp lamp) {
        this.lamp = lamp;
    }

    void press() { lamp.turnOn(); }
}

✅ Используем абстракции:

interface Switchable {
    void turnOn();
}

class Lamp implements Switchable {
    public void turnOn() { /* Включить */ }
}

class Switch {
    private Switchable device;

    Switch(Switchable device) {
        this.device = device;
    }

    void press() { device.turnOn(); }
}

📌 Итог
Принципы SOLID помогают писать гибкий, поддерживаемый и расширяемый код. Если следовать этим принципам, код будет легче читать и рефакторить.

Используешь ли ты SOLID в своих проектах? Напиши в комментариях, какой принцип для тебя самый сложный!

📲 Мы в MAX

👉@BookJava

Совет Spring Framework💡

Вы можете инжектировать (autowire) бины, которые могут отсутствовать, обернув их в java.util.Optional. Таким образом вы сообщаете, что этот бин является необязательным, избегаете исключения, если он не существует, и можете аккуратно обработать его отсутствие с помощью Optional API.

📲 Мы в MAX

👉@BookJava

🔧 Как ускорить сборку Maven проекта в 3 раза

Сегодня покажу пару приёмов, которые помогут тебе значительно ускорить сборку Maven проекта. Особенно полезно, если ты работаешь с большими монолитами или частыми CI/CD прогонками.

🚀 1. Включи параллельную сборку

Добавь флаг -T (thread count), чтобы Maven собирал модули параллельно:

mvn clean install -T 1C

1C — это количество потоков = количеству ядер CPU. Можешь указать, например, -T 4 для 4 потоков. Эффект — сборка может стать в 2–4 раза быстрее.

🧹 2. Пропускай тесты, если они не нужны

Когда работаешь над UI, версткой или конфигурацией:

mvn clean install -DskipTests

⚠️ -DskipTests — пропускает *и* компиляцию тестов, и сами тесты.
Если хочешь только не запускать тесты, используй:

mvn clean install -Dmaven.test.skip=false -DskipTests=true

📦 3. Используй mvn dependency:go-offline

Это скачает все зависимости, плагины и сделает тебя независимым от интернета:

mvn dependency:go-offline

Полезно для CI и работы в поезде ✈️


📲 Мы в MAX

👉@BookJava

🧵 Как правильно логировать ошибки в Java-приложении

Привет, друзья! Сегодня я расскажу о простой, но критически важной теме — логирование ошибок. Часто вижу, как разработчики либо совсем не логируют исключения, либо делают это неправильно. В итоге: баг есть, а откуда он взялся — непонятно.

Вот пара реальных примеров:

❌ Плохо:

try {
    doSomething();
} catch (Exception e) {
    System.out.println("Error happened");
}

✅ Хорошо:

private static final Logger logger = LoggerFactory.getLogger(MyClass.class);

try {
    doSomething();
} catch (Exception e) {
    logger.error("Failed to do something", e);
}

💡 Почему это важно:
- logger.error позволяет видеть стек исключения, а это ключ к диагностике.
- Можно использовать logger.warn или logger.info в зависимости от уровня важности.
- Хороший лог помогает быстро локализовать проблему на проде без дебага.

🎯 Совет:
Используйте Slf4j в связке с Logback или Log4j2. И обязательно следите за форматом логов — например, логируйте traceId, userId, requestId и другие полезные метаданные.

А вы как логируете ошибки у себя в проекте? Делаете свою обёртку? Используете AOP?

📲 Мы в MAX

👉@BookJava

💡 Collection vs List в Java: в чём разница и когда что использовать

Сегодня разберёмся с одним из самых популярных вопросов у джавистов: чем отличается Collection от List и когда что применять.


🔹 Collection — это базовый интерфейс всех коллекций в Java. Он описывает общие операции:
add(), remove(), size(), contains() и т.д.

🔹 List — это подинтерфейс Collection, предназначенный для работы с упорядоченными списками.
Дополнительно даёт методы:
get(index), set(index, value), indexOf(), add(index, value).


🔧 Пример с Collection:

Collection<String> names = new ArrayList<>();
names.add("Alice");
names.add("Bob");

for (String name : names) {
    System.out.println(name);
}

Здесь важно только наличие элементов — порядок и индексы не важны.


🔧 Пример с List:

List<String> cities = new ArrayList<>();
cities.add("Moscow");
cities.add("Berlin");
cities.add(1, "Paris");

System.out.println(cities.get(1)); // Paris

В этом случае нужен порядок и доступ по индексу — значит, выбираем List.


📌 Когда использовать что:

- Используй Collection, если хочешь абстрагироваться от конкретной структуры и не используешь индексы.
- Используй List, если:
- важен порядок добавления,
- нужен доступ по индексу,
- требуется вставка в определённое место.

🧠 Совет:
При проектировании методов или API лучше принимать Collection — так ты не ограничиваешь пользователя в реализации.
А если внутри метода тебе нужны индексы — переходи на List.

📲 Мы в MAX

👉@BookJava