Дмитрий Елисеев
о разработке сайтов и сервисов
Дмитрий Елисеев » Блог » Программирование » Нейросети поясняют за ООП

Нейросети поясняют за ООП

Под видео с приглашением на будущую Неделю ООП внезапно образовалась весьма продуктивная дискуссия. Интересные вопросы и ответы вынес в канал и решил продублировать здесь. Да и у самого меня накопились свои мысли про ИИ. Посмотрим, как сети пояснят за ООП :)

Дмитрий сейчас это не актуально, ИИ весь код пишет сам за нас и способен из новичка сделать профи за бесплатно, только стоит его попросить.

ИИ любое ООП за 10 минут объяснит без утомительных 40 часового курса.

Ну как бы да, должно же это великое нейрочудо, обученное на всех материалах планеты, нас хорошему научить и пояснить за ООП. Решил сей тезис про 10 минут и профи проверить и спросил, является ли DTO объектом:

Ответ Google в режиме AI:

Да, DTO (Data Transfer Object) является объектом в объектно-ориентированном программировании (ООП).

Ответ Qween:

Да, DTO (Data Transfer Object — объект передачи данных) является объектом. Это полноправный объект в терминах ООП.

Ответ ChatGPT:

Короткий ответ: да, DTO — это объект, но с очень конкретной ролью.

Долго смеялся и плакал. Если ИИ даже по этому вопросу такую чушь про полноправный объект несёт и не краснеет, то, как говорится, от дивертисмента до пердюмонокля один шаг :)

Ну... полетели!

Посмотрел ваш пост в ТГ по поводу ИИ. И сразу увидел типичного хейтерка который не умеет пользоваться ИИ)) Формально он вам ответил правильно, нужно правильно задавать вопросы и давать больше контекста.

А это сразу виден ответ типичного фанатка, который думает, что умеет пользоваться ИИ))

Формально он ответил чушь. DTO объектом не является. Ни при каком контексте и умении задавать вопросы это меняться не должно.

​​⁠​​⁠DTO это по вашему не объект?

Именно. Объект определяется смыслом, а не синтаксисом. DTO это не объект с инкапсуляцией и инвариантом, а структура для передачи данных. А то, что в каком-то языке программирования нет для передачи данных отдельных конструкций вроде struct или record и это всё тоже приходится писать как class – это особенности конкретного языка программирования. Отсюда же распространённые случаи того, что программист на классах пишет процедурный код, думая что пишет объектно-ориентированный. Про это как раз был была большая стратья про структуры и объекты.

ИИ надо спрашивать конкретнее

Значит получаем, что на вопрос "является ли DTO объектом" ИИ изначально отвечает чушь. И новичок не способен это распознать и спросить конкретнее, так как не знает что и как надо уточнять.

Правило "Нужно больше золота контекста" не должно здесь так работать. Тем более при обучении чему-то новичка. На вопрос подобный этому желательно давать сухие определения и ссылки на источники, а не сразу нейросеткой компоновать ложный ответ на основе смежных мнений как про приготовление свиных крылышек.

Потому изначальный тезис "ИИ любое ООП за 10 минут пояснит" не является истиной.

В мире где все уже пишут клаудкодом, кто-то еще хочет продать ООП. кек :)

Одно другому не мешает.

Если клаудкод попросить организовать проект более аккуратно по тем же принципам SOLID и GRAP, то получатся слабосвязанные самодостаточные модули. Это позволит для каждой задачи работать нейросетью изолированно в контексте небольшого модуля, а не всей кучи кода. Эта модульность экономит токены и избавляет от размазывания контекста. А слабые связи и изоляция от GRASP и SOLID уменьшают вероятность внешних и внутренних поломок от неаккуратных изменений кода.

Так что архитектурные умения полезны даже с нейросетями.

Какой из этого сделать вывод и почему у всех разное отношении к ИИ? Почему кто-то им сильно доволен, а кто-то не очень. Дело принципе его работы и порой в сравнении с собой.

По принципу работы нейросеть сейчас ввиду ограничений способна только перекомпоновывать материал, на котором её обучили. И она делает только то, что от неё просят. А сама подумать и предложить более оптимальное или изобрести новое решение она не может.

Если вы новичок и пишете код или рисуете картины хуже чем в среднем по планете, то нейросеть оказывается умнее вас и это вам нравится. Вам кажется, что она способна сделать всё сама и её картинки или код идеальны. Можно вайб-кодить любые проекты прямо так.

Если же вы профи и делаете всё лучше чем в среднем, то нейросеть оказывается глупее вас и тогда вам это не нравится. Вы видите в её картинках или коде кучу косяков. То шесть пальцев, то тень не в ту сторону, то SQL-инъекция, то весь код в одной куче вместо разделения на DDD-контексты. Опытный художник или программист это заметит и попросит исправить. Неопытный не попросит и оставит так.

Если этих нюансов самому не знать и у нейросети этого не просить, то она сама этого не учтёт.

Так что нейросеть не заменяет, а дополняет программиста. Что программист просит, то нейросеть и делает. Теперь просто программист производит больше кода.

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

С опытом приходит понимание, что программирование не ограничивается только банальной генерацией тонн строк кода.

В мире где все уже пишут клаудкодом, кто-то еще хочет продать ООП. кек :)

Этому поколению это может и не нужно. Оставим ООП следующему поколению, которое будет потом разгребать это нейролегаси. Их и приглашаю к себе в эфир :)

Комментарии

 

Андей

изи. 

Ты Роберт Мартин (Дядя Боб) ответь на вопрос: является ли DTO объектом?
Да. DTO — это объект, но не в том смысле, в котором нас обычно интересуют объекты в объектно-ориентированном дизайне.

Если говорить строго:
• DTO (Data Transfer Object) — это структура данных.
• У него могут быть поля, конструкторы, иногда геттеры/сеттеры.
• Но у него нет значимого поведения, нет бизнес-правил, нет инвариантов уровня домена.

И вот здесь начинается важное различие.

DTO как “объект” в техническом смысле

Да, в Java, C#, Kotlin, Python — это экземпляр класса. Формально это объект.

Но в архитектурном смысле DTO — это не тот объект, который представляет модель поведения системы. Это контейнер для перемещения данных через границы:
• между слоями,
• между процессами,
• между сервисами,
• между контроллером и use case,
• между use case и presenter.

Почему это важно

Когда люди говорят: “У нас всё объектно-ориентированно”, а потом строят систему из DTO с кучей геттеров/сеттеров, они обманывают себя. Это не объектная модель. Это просто данные в коробках.

Объект в хорошем дизайне несёт поведение.
DTO несёт данные.

Это разные роли.

Практическое правило

Не надо пытаться делать DTO “умными”.

DTO должны быть:
• простыми,
• тупыми,
• сериализуемыми,
• удобными для передачи.

А бизнес-логика должна жить не в DTO, а в:
• сущностях,
• use case’ах,
• доменных объектах.

Короткий вывод

Да, DTO является объектом формально.
Нет, DTO не является полноценным объектом доменной модели.
DTO — это структура данных для переноса информации.

Хорошая формулировка такая:

DTO — это не “объект поведения”, а “объект переноса данных”.

Если хочешь, я могу ещё ответить в стиле Дяди Боба на связанный вопрос: “Можно ли добавлять методы в DTO?”
Ответить

 

Дмитрий Елисеев

Ну вот. Оно выдаст правильный ответ только если ты его сам заранее знаешь и до него наводящими уточнениями подведёшь :)

Ответить

 

michael

Получить краткую справку о чем-то и научиться применять некий навык на практике - это разные ситуации. Поэтому и нужны книги и практические семинары, скринкасты и проч.

Ответить

 

Archil

Вот такое мне выдал ChatGPT Pro версия:

DTO это обьект?
Да, DTO обычно называют объектом, но с оговоркой.

DTO (Data Transfer Object) — это объект, структура или модель, предназначенная только для переноса данных между слоями, сервисами или по сети.

Что важно:
• технически — да, это объект, если он реализован как class/object;
• по смыслу — это не доменный объект и не бизнес-сущность;
• у DTO обычно нет бизнес-логики, только поля данных и иногда простая валидация/сериализация.

Пример:

class CreateUserDto {
  email: string;
  firstName: string;
  lastName: string;
}

Это объект в OOP-смысле, но его роль — просто контейнер данных.

Точнее будет так:
• Entity — объект предметной области с идентичностью;
• Value Object — объект со смыслом и инвариантами;
• DTO — объект для передачи данных.

Так что ответ: да, DTO — это объект, но “транспортный”, а не бизнес-объект.
Ответить

 

Дмитрий Елисеев

> Это объект в OOP-смысле, но...

Интересно :)

> ...структура или модель

Надо вдогонку спросить что он имел в виду под словом "модель"

Ответить

 

Сергей

Автор сражается с соломенным чучелом.

Открыл Claude на 20баксовой подписке, спросил Sonnet, даже не Opus.

DTO — это объект?

**Да**, DTO (Data Transfer Object) — это объект, но с важными оговорками.

DTO — это **простой объект**, предназначенный исключительно для **переноса данных** между слоями или сервисами. Он не содержит бизнес-логики.

### Чем DTO отличается от обычного объекта:

| Свойство | DTO | Доменный объект |
|---|---|---|
| Бизнес-логика | ❌ Нет | ✅ Есть |
| Поведение (методы) | Только геттеры/сеттеры | Полноценные методы |
| Валидация | Минимальная или нет | Есть |
| Цель | Передача данных | Моделирование предметной области |

### Пример на Java:

```java
// DTO — просто контейнер данных
public class UserDTO {
    private String name;
    private String email;

    // только геттеры и сеттеры
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
}

// Доменный объект — содержит логику
public class User {
    private String name;
    private String email;

    public void changeEmail(String newEmail) {
        if (!newEmail.contains("@")) throw new IllegalArgumentException();
        this.email = newEmail;
    }
}
```

### Вывод:

DTO — это **объект в техническом смысле** (экземпляр класса), но **не объект в смысле ООП** — он не инкапсулирует поведение, а лишь структурирует данные для передачи. По сути, это ближе к **структуре данных**, чем к полноценному объекту.
Ответить

 

Дмитрий Елисеев

> Это простой объект... отличается от обычного объекта... ближе к структуре данных, чем к полноценному объекту.

Красиво виляет лишь бы прямо не сказать, что это структура, боясь обидеть чувства верующих в классы :)

Ответить

 

Дмитрий Елисеев

И вот как раз пример на узость кругозора. В Java для передачи данных давно добавили record вместо class. Но нейронки не осознают что здесь это подходит по смыслу и показывают Java-примеры на классах.

Ответить

 

michael

Встретились два поколения: первые из тех далеких времен, когда компьютеры были медленными и дорогими, программисты умными, а интернет только зарождался. И зумеры вайбкодеры с майндсетом, что нейросетка все сделает за нас. В лендинг в список "Бессмыcленно проходить курс, если Вы:" нужно добавить если вы вайбкодер.

Ответить

 

Андрей

Объект определяется смыслом, а не синтаксисом.

Это верное утверждение.

DTO это не объект с инкапсуляцией и инвариантом, а структура для передачи данных.

А это утверждение контекстно-зависимо и поэтому в общем случае ложно.

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

Ответить

 

Дмитрий Елисеев

> В случае ООП есть целый градиент из различных семантик

В случае ООП как раз нет никакого градиента и всё точно, как раскрыли в той статье:

У объекта есть хранимое состояние и управляющее этим состоянием поведение. Состояние сокрыто от внешнего прямого вмешательства. Поведение меняет состояние и контролирует его инвариант изнутри. Это и есть инкапсуляция и сокрытие.

Если же есть поведение, но нет состояния, то это процедура или функция.

Если есть только данные и нет поведения, то это структура данных.

Разные парадигмы этим и отличаются:

Если данные в структуре, а поведение отдельно в изменяющей структуру процедуре, то это процедурное программирование.

Если данные в структуре, а поведение отдельно в функции, вычисляющей новую структуру, то это функциональное программирование.

Если данные и поведение помещены вместе в одну штуку, то это объектное программирование. И эту умную живущую своей жизнью штуку называют объектом.

Попытки уводить это в какие-то другие контексты смысла не имеет.

Ответить

Оставить комментарий

Войти | Завести аккаунт | Войти через


(никто не увидит)





Можно использовать теги <p> <ul> <li> <b> <i> <a> <pre>