1) Чрезмерное использование private-методов, скрывающее сложность
Когда private-методов слишком много, это ломает читаемость и разносит логику по коду. Визуально всё выглядит «чисто», но важные логические шаги оказываются скрытыми.
Когда это плохо:
Вы выносите код в private-методы просто ради самого факта выноса, а не потому что они переиспользуемы или несут отдельный смысл.
Как лучше:
Выделяйте разные зоны ответственности в отдельные классы или сервисы, которые сотрудничают между собой.
2) Автоматическое добавление private + геттеров/сеттеров по умолчанию
Бездумное добавление геттеров и сеттеров превращает ООП в просто «структуры с методами». Это нарушает инкапсуляцию, а не сохраняет её.
Вместо этого:
● Открывайте только те геттеры/сеттеры, которые реально нужны для бизнес-логики.
● Вместо сеттеров лучше использовать методы, которые выполняют осмысленные действия с валидацией.
3) Чрезмерное использование static-методов и переменных
static-методы кажутся удобными, но убивают тестируемость и гибкость. Они привязывают код к жёсткому глобальному состоянию.
Как лучше:
Используйте внедрение зависимостей или передавайте нужную конфигурацию явно туда, где она требуется.
4) Слишком большой класс (“God Object”)
Огромный класс, который делает всё подряд, превращается в чёрный ящик — его сложно тестировать, менять и понимать.
Как лучше:
● Применяйте принцип единственной ответственности (Single Responsibility Principle): у класса должна быть только одна причина для изменения.
● Разделяйте обязанности между меньшими по размеру классами или модулями.
5) Скрытие семантики null / Optional
Возврат null или скрытое использование Optional приводит к неожиданным ошибкам во время выполнения. Отсутствие или наличие значения должно быть выражено явно.
Как лучше:
● Используйте
Optional<T> или другой задокументированный способ, чтобы показать, что результат может отсутствовать.● Если это действительно ошибка — выбрасывайте чётко определённое исключение.
👉 Java Portal