Плохие практики в коде, которые кажутся безобидными (но это не так)
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
Креативные (нетрадиционные) способы использования интерфейсов в Java
1) Конфигурация на основе интерфейсов (расширение паттерна Strategy)
Вместо использования конфигурационных файлов или
🔸 Инкапсулируется поведение, а не просто значения.
🔸 Позволяет менять поведение динамически в рантайме, подставляя разные реализации.
2) Интерфейсы для method chaining с условным выполнением
Интерфейсы могут быть использованы для построения цепочек вызовов методов с возможностью условного выполнения. Это позволяет динамически пропускать определённые вызовы.
Используется при создании fluent API, где некоторые методы должны выполняться только при выполнении условий.
Это:
🔸 Делает код более читаемым и выразительным.
🔸 Избегает ненужных вызовов, если условие не выполнено.
Традиционный аналог:
3) Маркировочные (tagging/marker) интерфейсы с проверкой по типу
Пустые интерфейсы можно использовать для "тегирования" классов и принятия решений во время выполнения или компиляции.
Это позволяет выполнять определённые действия, если класс реализует конкретный marker-интерфейс.
🔸 Чистое разделение ролей без добавления логики
🔸 Хорошо сочетается с
4) Наследование интерфейсов для реализации поведения по умолчанию
Интерфейсы с default-методами можно использовать для композиции переиспользуемой логики.
Применяется, когда нужно разделить общее поведение между разными классами, не прибегая к наследованию от общего базового класса.
👉 Java Portal
1) Конфигурация на основе интерфейсов (расширение паттерна Strategy)
Вместо использования конфигурационных файлов или
enum
для выбора поведения на лету (что считается классическим подходом), можно использовать интерфейсы для инкапсуляции различных конфигураций.2) Интерфейсы для method chaining с условным выполнением
Интерфейсы могут быть использованы для построения цепочек вызовов методов с возможностью условного выполнения. Это позволяет динамически пропускать определённые вызовы.
Используется при создании fluent API, где некоторые методы должны выполняться только при выполнении условий.
Это:
Традиционный аналог:
if (conditionMet) {
obj.doSomething();
obj.doAnotherThing();
}
3) Маркировочные (tagging/marker) интерфейсы с проверкой по типу
Пустые интерфейсы можно использовать для "тегирования" классов и принятия решений во время выполнения или компиляции.
Это позволяет выполнять определённые действия, если класс реализует конкретный marker-интерфейс.
reflection
и generics
4) Наследование интерфейсов для реализации поведения по умолчанию
Интерфейсы с default-методами можно использовать для композиции переиспользуемой логики.
Применяется, когда нужно разделить общее поведение между разными классами, не прибегая к наследованию от общего базового класса.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM