Хаки Java-кодинга, которые стоит знать разработчикам
✓ Используйте
➣ Почему: короче, безопаснее, неизменяемо — снижает риск случайной мутации.
✓ Используйте
➣ Почему: устраняет проверки на
✓ Используйте
➣ Почему: чище и удобнее для сериализации/десериализации enum'ов в API, БД или файлах.
✓ Используйте
➣ Почему: читаемо, понятно, без ошибок в условных сравнениях.
✓ Используйте
➣ Почему: выразительнее и чище — больше никаких ручных
👉 Java Portal
✓ Используйте
Map.ofEntries()
для создания неизменяемых мап с несколькими парами➣ Почему: короче, безопаснее, неизменяемо — снижает риск случайной мутации.
✓ Используйте
Optional.map().orElse()
вместо ручной обработки null
➣ Почему: устраняет проверки на
null
, читается лучше, легко комбинируется с другой логикой.✓ Используйте
Enum.valueOf()
+ name()
для безопасного преобразования enum
➣ Почему: чище и удобнее для сериализации/десериализации enum'ов в API, БД или файлах.
✓ Используйте
Comparator.comparing().thenComparing()
вместо кастомной логики➣ Почему: читаемо, понятно, без ошибок в условных сравнениях.
✓ Используйте
Optional.ifPresentOrElse()
вместо if-else
с isPresent()
➣ Почему: выразительнее и чище — больше никаких ручных
get()
и нагромождений if-else
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Некоторые редкие, но ценные паттерны в Java
1. Null Object Pattern (Объект-Заглушка вместо null)
❯ Позволяет избежать проверок на null, возвращая объект с "пустым" поведением, реализующий ожидаемый интерфейс.
❯ Помогает держать код чистым, без множества
❯ Используй, когда возврат
2. Parameter Object Pattern (Объект параметров)
❯ Объединяет логически связанные параметры в один объект.
❯ Такой объект удобно прокидывать через разные уровни приложения, обеспечивая согласованность.
❯ Используй, когда у метода слишком много связанных аргументов.
3. Fluent Interface / Method Chaining (Флюент-интерфейс / Цепочка вызовов)
❯ Позволяет вызывать методы цепочкой, улучшая читаемость и выражая намерение кода (особенно в билдерах и конфигурациях).
❯ Используй в билдерах или для декларативной настройки.
4. Execute Around Method Pattern (Шаблон обёртки вокруг действия)
❯ Инкапсулирует логику подготовки и завершения вокруг основного действия.
❯ Гарантирует корректное освобождение ресурсов.
❯ Используй для управления ресурсами (файлы, БД и т.п.).
5. Initialization-on-Demand Holder (ленивый Singleton без
❯ Безопасный, потокобезопасный и производительный способ ленивой инициализации Singleton'а без явной синхронизации.
❯ Используй, если нужен быстрый и потокобезопасный синглтон.
👉 Java Portal
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'а без явной синхронизации.
❯ Используй, если нужен быстрый и потокобезопасный синглтон.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Разные подходы к структуре REST API:
1) Чистый CRUD-стиль
👍 Просто и предсказуемо
👎 Начинает хромать при действиях вне CRUD
2) Эндпоинты-действия
👍 Ясное указание на сайд-эффекты
👎 Нарушает REST-идеи (глаголы в URL)
3) Вложенные ресурсы
👍 Удобно моделирует связи между сущностями
👎 Может вырасти в избыточную иерархию, тяжело поддерживать
4) Плоская структура + фильтры
👍 Гибкие запросы
👎 Требует строгой валидации query-параметров
5) Версионирование API
👍 Безопасное развитие API
👎 Увеличивает накладные расходы на поддержку
👉 Java Portal
1) Чистый CRUD-стиль
GET /users
POST /users
PUT /users/{id}
DELETE /users/{id}
2) Эндпоинты-действия
POST /users/{id}/deactivate
POST /orders/{id}/cancel
3) Вложенные ресурсы
GET /users/{id}/orders
POST /users/{id}/addresses
4) Плоская структура + фильтры
GET /orders?userId=123
GET /products?category=books&page=2
5) Версионирование API
GET /v1/users
Accept: application/vnd.myapp.v2+json
Please open Telegram to view this post
VIEW IN TELEGRAM
Плохие практики в коде, которые кажутся безобидными (но это не так)
1) Чрезмерное использование private-методов, скрывающее сложность
Когда private-методов слишком много, это ломает читаемость и разносит логику по коду. Визуально всё выглядит «чисто», но важные логические шаги оказываются скрытыми.
Когда это плохо:
Вы выносите код в private-методы просто ради самого факта выноса, а не потому что они переиспользуемы или несут отдельный смысл.
Как лучше:
Выделяйте разные зоны ответственности в отдельные классы или сервисы, которые сотрудничают между собой.
2) Автоматическое добавление private + геттеров/сеттеров по умолчанию
Бездумное добавление геттеров и сеттеров превращает ООП в просто «структуры с методами». Это нарушает инкапсуляцию, а не сохраняет её.
Вместо этого:
● Открывайте только те геттеры/сеттеры, которые реально нужны для бизнес-логики.
● Вместо сеттеров лучше использовать методы, которые выполняют осмысленные действия с валидацией.
3) Чрезмерное использование static-методов и переменных
static-методы кажутся удобными, но убивают тестируемость и гибкость. Они привязывают код к жёсткому глобальному состоянию.
Как лучше:
Используйте внедрение зависимостей или передавайте нужную конфигурацию явно туда, где она требуется.
4) Слишком большой класс (“God Object”)
Огромный класс, который делает всё подряд, превращается в чёрный ящик — его сложно тестировать, менять и понимать.
Как лучше:
● Применяйте принцип единственной ответственности (Single Responsibility Principle): у класса должна быть только одна причина для изменения.
● Разделяйте обязанности между меньшими по размеру классами или модулями.
5) Скрытие семантики null / Optional
Возврат null или скрытое использование Optional приводит к неожиданным ошибкам во время выполнения. Отсутствие или наличие значения должно быть выражено явно.
Как лучше:
● Используйте
● Если это действительно ошибка — выбрасывайте чётко определённое исключение.
👉 Java Portal
1) Чрезмерное использование private-методов, скрывающее сложность
Когда private-методов слишком много, это ломает читаемость и разносит логику по коду. Визуально всё выглядит «чисто», но важные логические шаги оказываются скрытыми.
Когда это плохо:
Вы выносите код в private-методы просто ради самого факта выноса, а не потому что они переиспользуемы или несут отдельный смысл.
Как лучше:
Выделяйте разные зоны ответственности в отдельные классы или сервисы, которые сотрудничают между собой.
2) Автоматическое добавление private + геттеров/сеттеров по умолчанию
Бездумное добавление геттеров и сеттеров превращает ООП в просто «структуры с методами». Это нарушает инкапсуляцию, а не сохраняет её.
Вместо этого:
● Открывайте только те геттеры/сеттеры, которые реально нужны для бизнес-логики.
● Вместо сеттеров лучше использовать методы, которые выполняют осмысленные действия с валидацией.
3) Чрезмерное использование static-методов и переменных
static-методы кажутся удобными, но убивают тестируемость и гибкость. Они привязывают код к жёсткому глобальному состоянию.
Как лучше:
Используйте внедрение зависимостей или передавайте нужную конфигурацию явно туда, где она требуется.
4) Слишком большой класс (“God Object”)
Огромный класс, который делает всё подряд, превращается в чёрный ящик — его сложно тестировать, менять и понимать.
Как лучше:
● Применяйте принцип единственной ответственности (Single Responsibility Principle): у класса должна быть только одна причина для изменения.
● Разделяйте обязанности между меньшими по размеру классами или модулями.
5) Скрытие семантики null / Optional
Возврат null или скрытое использование Optional приводит к неожиданным ошибкам во время выполнения. Отсутствие или наличие значения должно быть выражено явно.
Как лучше:
● Используйте
Optional<T>
или другой задокументированный способ, чтобы показать, что результат может отсутствовать.● Если это действительно ошибка — выбрасывайте чётко определённое исключение.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Пакетная обработка JDBC через StatelessSession в Hibernate
Статья объясняет, как использовать StatelessSession в Hibernate 6 для быстрой пакетной вставки, обновления и удаления данных с помощью JDBC Batching — без лишнего кеша и с высокой производительностью.
⏩ Читать подробнее
👉 Java Portal | #cтатья
Статья объясняет, как использовать StatelessSession в Hibernate 6 для быстрой пакетной вставки, обновления и удаления данных с помощью JDBC Batching — без лишнего кеша и с высокой производительностью.
Please open Telegram to view this post
VIEW IN TELEGRAM
Советы по Java Stream API: Ленивое вычисление с использованием
Когда возникает необходимость повторно использовать потоковую обработку, можно воспользоваться
👉 Java Portal
Supplier<Stream<T>>
Когда возникает необходимость повторно использовать потоковую обработку, можно воспользоваться
Supplier
. В обычных случаях поток (Stream) нельзя использовать повторно после его обработки.Please open Telegram to view this post
VIEW IN TELEGRAM
14 советов для высокопроизводительной персистентности в Java
⏩ Читать подробнее
👉 Java Portal | #cтатья
Please open Telegram to view this post
VIEW IN TELEGRAM