Хаки Java-кодинга, которые стоит знать разработчикам

✓ Используйте Map.ofEntries() для создания неизменяемых мап с несколькими парами
➣ Почему: короче, безопаснее, неизменяемо — снижает риск случайной мутации.

✓ Используйте Optional.map().orElse() вместо ручной обработки null
➣ Почему: устраняет проверки на null, читается лучше, легко комбинируется с другой логикой.

✓ Используйте Enum.valueOf() + name() для безопасного преобразования enum
➣ Почему: чище и удобнее для сериализации/десериализации enum'ов в API, БД или файлах.

✓ Используйте Comparator.comparing().thenComparing() вместо кастомной логики
➣ Почему: читаемо, понятно, без ошибок в условных сравнениях.

✓ Используйте Optional.ifPresentOrElse() вместо if-else с isPresent()
➣ Почему: выразительнее и чище — больше никаких ручных get() и нагромождений if-else

👉 Java Portal

Некоторые редкие, но ценные паттерны в Java

1. Null Object Pattern (Объект-Заглушка вместо null)

❯ Позволяет избежать проверок на null, возвращая объект с "пустым" поведением, реализующий ожидаемый интерфейс.
❯ Помогает держать код чистым, без множества if (obj != null) перед каждым вызовом метода.
❯ Используй, когда возврат null приводит к захламлению условными конструкциями.

2. Parameter Object Pattern (Объект параметров)

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

3. Fluent Interface / Method Chaining (Флюент-интерфейс / Цепочка вызовов)

❯ Позволяет вызывать методы цепочкой, улучшая читаемость и выражая намерение кода (особенно в билдерах и конфигурациях).
❯ Используй в билдерах или для декларативной настройки.

4. Execute Around Method Pattern (Шаблон обёртки вокруг действия)

❯ Инкапсулирует логику подготовки и завершения вокруг основного действия.
❯ Гарантирует корректное освобождение ресурсов.
❯ Используй для управления ресурсами (файлы, БД и т.п.).

5. Initialization-on-Demand Holder (ленивый Singleton без synchronized)

❯ Безопасный, потокобезопасный и производительный способ ленивой инициализации Singleton'а без явной синхронизации.
❯ Используй, если нужен быстрый и потокобезопасный синглтон.

👉 Java Portal

Плохие практики в коде, которые кажутся безобидными (но это не так)

1) Чрезмерное использование private-методов, скрывающее сложность

Когда private-методов слишком много, это ломает читаемость и разносит логику по коду. Визуально всё выглядит «чисто», но важные логические шаги оказываются скрытыми.

Когда это плохо:
Вы выносите код в private-методы просто ради самого факта выноса, а не потому что они переиспользуемы или несут отдельный смысл.

Как лучше:
Выделяйте разные зоны ответственности в отдельные классы или сервисы, которые сотрудничают между собой.

2) Автоматическое добавление private + геттеров/сеттеров по умолчанию

Бездумное добавление геттеров и сеттеров превращает ООП в просто «структуры с методами». Это нарушает инкапсуляцию, а не сохраняет её.

Вместо этого:

● Открывайте только те геттеры/сеттеры, которые реально нужны для бизнес-логики.
● Вместо сеттеров лучше использовать методы, которые выполняют осмысленные действия с валидацией.

3) Чрезмерное использование static-методов и переменных

static-методы кажутся удобными, но убивают тестируемость и гибкость. Они привязывают код к жёсткому глобальному состоянию.

Как лучше:
Используйте внедрение зависимостей или передавайте нужную конфигурацию явно туда, где она требуется.

4) Слишком большой класс (“God Object”)

Огромный класс, который делает всё подряд, превращается в чёрный ящик — его сложно тестировать, менять и понимать.

Как лучше:

● Применяйте принцип единственной ответственности (Single Responsibility Principle): у класса должна быть только одна причина для изменения.

● Разделяйте обязанности между меньшими по размеру классами или модулями.

5) Скрытие семантики null / Optional

Возврат null или скрытое использование Optional приводит к неожиданным ошибкам во время выполнения. Отсутствие или наличие значения должно быть выражено явно.

Как лучше:

● Используйте Optional<T> или другой задокументированный способ, чтобы показать, что результат может отсутствовать.

● Если это действительно ошибка — выбрасывайте чётко определённое исключение.

👉 Java Portal

Креативные (нетрадиционные) способы использования интерфейсов в Java

1) Конфигурация на основе интерфейсов (расширение паттерна Strategy)

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

🔸Инкапсулируется поведение, а не просто значения.
🔸Позволяет менять поведение динамически в рантайме, подставляя разные реализации.

2) Интерфейсы для method chaining с условным выполнением

Интерфейсы могут быть использованы для построения цепочек вызовов методов с возможностью условного выполнения. Это позволяет динамически пропускать определённые вызовы.

Используется при создании fluent API, где некоторые методы должны выполняться только при выполнении условий.
Это:

🔸Делает код более читаемым и выразительным.
🔸Избегает ненужных вызовов, если условие не выполнено.

Традиционный аналог:

if (conditionMet) {
    obj.doSomething();
    obj.doAnotherThing();
}

3) Маркировочные (tagging/marker) интерфейсы с проверкой по типу

Пустые интерфейсы можно использовать для "тегирования" классов и принятия решений во время выполнения или компиляции.

Это позволяет выполнять определённые действия, если класс реализует конкретный marker-интерфейс.

🔸Чистое разделение ролей без добавления логики
🔸Хорошо сочетается с reflection и generics

4) Наследование интерфейсов для реализации поведения по умолчанию

Интерфейсы с default-методами можно использовать для композиции переиспользуемой логики.

Применяется, когда нужно разделить общее поведение между разными классами, не прибегая к наследованию от общего базового класса.

👉 Java Portal