ООП головного мозга: почему ChatGPT плюёт на паттерны и пишет спагетти-код

Когда ChatGPT получает просьбу написать код.

Ты говоришь ему:

- Сделай простую проверку пользователя.

И через минуту выясняется, что для проверки одного if нам уже нужны интерфейс, стратегия, фабрика и сервис.

Кажется, будто у нейросети где-то внутри сидит маленький архитектор и шепчет:

«Не смей писать функцию. Это же можно сделать через пять классов».

Я решил проверить, насколько далеко это может зайти.

Сначала я попросил написать просто

Задача была элементарная: определить скидку для пользователя.

Если VIP - 20 процентов.

Если обычный пользователь - без скидки.

Первый вариант получился подозрительно коротким:

//php

function getDiscount($user): int
{
    if ($user['vip']) {
        return 20;
    }

    return 0;
}

Всё.

Функция получила пользователя и вернула скидку.

Я посмотрел на код и подумал: ну здесь даже ругаться не на что.

Но потом решил включить в ChatGPT его любимую кнопку «а теперь сделай по-взрослому».

Попросил использовать ООП, SOLID и паттерн Strategy, чтобы решение можно было расширять.

Вот тут началось самое интересное.

Появился интерфейс:

//php

interface DiscountStrategy
{
    public function supports(array $user): bool;

    public function getDiscount(): int;
}

Потом класс для VIP:

//php

class VipDiscountStrategy implements DiscountStrategy
{
    public function supports(array $user): bool
    {
        return $user['vip'];
    }

    public function getDiscount(): int
    {
        return 20;
    }
}

Потом обычная стратегия:

//php

class DefaultDiscountStrategy implements DiscountStrategy
{
    public function supports(array $user): bool
    {
        return true;
    }

    public function getDiscount(): int
    {
        return 0;
    }
}

А потом появился ещё и сервис:

//php

class DiscountResolver
{
    public function __construct(
        private array $strategies
    ) {}

    public function resolve(array $user): int
    {
        foreach ($this->strategies as $strategy) {
            if ($strategy->supports($user)) {
                return $strategy->getDiscount();
            }
        }

        return 0;
    }
}

Я смотрел на это несколько секунд.

Потом ещё раз посмотрел на исходную задачу.

Нам всё ещё нужно было ответить на один вопрос:

VIP пользователь или нет?

В первом варианте для этого требовался один if.

Во втором мы уже организовали маленький чемпионат классов за право вернуть число 20.

Но самое смешное было дальше

Я спросил ChatGPT:

- А теперь объясни, почему второй вариант лучше первого.

Ответ был вполне убедительным.

Расширяемость.

Разделение ответственности.

Возможность добавлять новые типы скидок.

Тестируемость.

И всё это действительно звучало разумно.

Пока я не задал следующий вопрос:

- А какие новые типы скидок нам нужно добавить прямо сейчас?

Ответ был простой: никаких.

Вот и приехали.

Мы построили архитектуру для будущего, которое даже не обещало наступить.

Именно здесь я впервые поймал у ChatGPT то, что называю ООП головного мозга.

Нейросеть начинает видеть классы там, где человеку достаточно переменной.

Причём самое неприятное - отдельные части такого кода выглядят совершенно нормально.

Вот интерфейс.

Вот стратегия.

Вот сервис.

Вот Dependency Injection.

Вот SOLID.

Каждый элемент можно защитить на собеседовании.

Но если собрать всё вместе, возникает странный вопрос:

а проблему-то мы какую решали?

Почему такой код вообще появляется

ChatGPT очень хорошо знает, как обычно выглядит «правильный» программный код в статьях, документации, книгах и ответах на Stack Overflow.

Поэтому когда ему дают слова «ООП», «SOLID», «расширяемость» и «паттерны», он начинает собирать знакомую конструкцию.

Получается архитектура, которая выглядит убедительно ещё до того, как появилась необходимость в этой архитектуре.

И вот тут программисту легко попасться.

Особенно если он только начинает работать с нейросетями.

Смотришь на десять классов вместо одной функции и думаешь:

«Наверное, это я чего-то не понимаю. Наверное, профессиональный код именно так и должен выглядеть».

Нет.

Иногда профессиональный код - это как раз тот код, который не стал сложнее без причины.

Где начинается настоящая проблема

Сам по себе лишний класс ещё никого не убил.

Проблемы начинаются позже.

Сегодня у нас:

//text

Controller
   ↓
Service
   ↓
Resolver
   ↓
Strategy
   ↓
Repository

А завтра приходит баг.

И вместо того чтобы открыть одну функцию и найти ошибку, мы начинаем ходить по цепочке.

Почему сюда попал этот объект?

Кто создал этот сервис?

Почему выбралась именно эта стратегия?

Где зарегистрирован этот класс?

Почему здесь вообще нужен интерфейс?

Через десять минут ты уже не исправляешь баг.

Ты изучаешь собственную архитектуру.

И вот это действительно смешно.

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

Поэтому я теперь проверяю нейросеть одним вопросом

Если ChatGPT начинает превращать небольшую функцию в архитектурный дворец, я спрашиваю:

«А теперь покажи самый простой вариант, который решает ту же задачу».

И сравниваю.

Если простой вариант делает всё то же самое - оставляю простой.

Если сложный действительно даёт что-то полезное - оставляю сложный.

Для меня это и есть главный урок из истории с «ООП головного мозга».

Паттерн не делает код хорошим. Интерфейс не делает код профессиональным. А количество классов вообще ничего не говорит о качестве программы.

Иногда хороший программист пишет двадцать строк.

Иногда - двадцать классов.

Вопрос не в том, сколько получилось кода.

Вопрос в том, зачем он там вообще находится.