Хватит пихать паттерны куда попало: как неправильное понимание ООП превращает ваш код в легаси

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

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

Ловушка первая: «Всё вокруг — объект»

Главная беда начинающих программистов, которые начитались учебников — это попытка смоделировать реальный мир один в один через классы и наследование. В учебниках нам пишут: «Класс — это чертеж Машины, а объекты — это конкретные Жигули и Мерседес».

В реальном промышленном коде это не работает. Пытаясь натянуть эту аналогию на бизнес-логику, разработчик создает гигантские иерархии наследования. Появляется условный BaseVehicle, от него AbstractCar, от него PassengerCar… А через полгода выясняется, что в проект нужно добавить электросамокат, который вообще не вписывается в эту цепочку, потому что у него нет коробки передач, но есть батарея.

Как надо на самом деле: Забудьте про наследование реального мира. Наследование в ООП нужно использовать только тогда, когда вам критически необходимо полиморфное поведение, либо жестко соблюдается принцип подстановки Барбары Лисков (LSP). Во всех остальных случаях используйте композицию — собирайте объект из мелких независимых интерфейсов, как конструктор Лего.

Ловушка вторая: Архитектурный оверинжиниринг (Overengineering)

Это классическая болезнь программистов, которые только-только освоили паттерны проектирования. Им сразу хочется применить их ВСЕ и желательно в одном месте. Вместо того чтобы написать простую функцию, которая берет данные из базы и отдает их пользователю, разработчик начинает городить огород:

• Создает DataServiceFactory
• Пишет AbstractDataRepository
• Оборачивает всё в паттерн «Стратегия» (на случай, если завтра база данных сменится с PostgreSQL на Oracle — спойлер: не сменится никогда)
• Добавляет «Наблюдателя» (Observer) для логирования каждого чиха

В итоге ради решения простейшей задачи пишется 15 пустых классов-пустышек, которые просто перенаправляют вызовы друг другу. Код превращается в лабиринт. Чтобы понять, как работает одна кнопка, приходится прокликивать цепочку из десятка файлов. Это и есть легаси-код, который потом невозможно поддерживать.

Паттерны, которые чаще всего используют не к месту

Давайте разберем три паттерна, которыми программисты грешат чаще всего:

1. Singleton (Одиночка). Самый любимый и самый токсичный паттерн. Новички пихают его везде, где нужен глобальный доступ к объекту (например, к настройкам или базе). В итоге Singleton превращается в скрытую глобальную переменную. Код становится намертво связанным, а написать для такого класса модульные тесты (Unit-тесты) — это отдельный вид мазохизма, потому что объект хранит состояние между тестами.
2. Factory Method (Фабричный метод). Отличный паттерн, если у вас реально есть динамически меняющиеся типы объектов. Но если у вас в системе всего два вида пользователей (Клиент и Админ) и их список не изменится в ближайшие три года, создавать под них абстрактные фабрики — это пустая трата рабочего времени и усложнение кода на ровном месте.
3. Command (Команда). Превращать каждое банальное действие пользователя в отдельный класс «Команды» ради абстракции — прямой путь к раздуванию кодовой базы.

Как проектировать код и не сойти со ума?

Паттерны проектирования — это не священное писание. Это просто типовые паттерны для решения конкретных проблем. Если у вас нет этой проблемы прямо сейчас — вам не нужен этот паттерн. Держите в голове три главных правила чистого кода:

• KISS (Keep It Simple, Stupid): делайте код максимально простым. Если задачу можно решить обычной понятной функцией без создания пяти классов — решите её функцией. Тот, кто будет читать ваш код после вас, скажет спасибо.
• YAGNI (You Ain't Gonna Need It): вам это не понадобится. Не пишите код про запас. Не закладывайте в архитектуру гибкость «на будущее», если этого будущего нет в текущем техзадании. Код должен решать задачу, которая стоит перед вами сегодня.
• Читаемость бьет абстракцию: архитектура хороша не тогда, когда в ней применены все паттерны из книги, а тогда, когда сторонний программист может открыть ваш проект и за 15 минут понять, как там всё устроено.

А как вы относитесь к паттернам? Замечали за собой или коллегами желание переусложнить архитектуру на ровном месте? Делитесь в комментариях примерами самого дикого оверинжиниринга, который вам попадался в работе!