Нейросети поясняют за ООП
Под видео с приглашением на будущую Неделю ООП внезапно образовалась весьма продуктивная дискуссия. Интересные вопросы и ответы вынес в канал и решил продублировать здесь. Да и у самого меня накопились свои мысли про ИИ. Посмотрим, как сети пояснят за ООП :)
Дмитрий сейчас это не актуально, ИИ весь код пишет сам за нас и способен из новичка сделать профи за бесплатно, только стоит его попросить.
ИИ любое ООП за 10 минут объяснит без утомительных 40 часового курса.
Ну как бы да, должно же это великое нейрочудо, обученное на всех материалах планеты, нас хорошему научить и пояснить за ООП. Решил сей тезис про 10 минут и профи проверить и спросил, является ли DTO объектом:
Ответ Google в режиме AI:
Да, DTO (Data Transfer Object) является объектом в объектно-ориентированном программировании (ООП).
Ответ Qwen:
Да, DTO (Data Transfer Object — объект передачи данных) является объектом. Это полноправный объект в терминах ООП.
Ответ ChatGPT:
Короткий ответ: да, DTO — это объект, но с очень конкретной ролью.
Долго смеялся и плакал. Если ИИ даже по этому вопросу такую чушь про полноправный объект несёт и не краснеет, то, как говорится, от дивертисмента до пердюмонокля один шаг :)
Ну... полетели!
Посмотрел ваш пост в ТГ по поводу ИИ. И сразу увидел типичного хейтерка который не умеет пользоваться ИИ)) Формально он вам ответил правильно, нужно правильно задавать вопросы и давать больше контекста.
А это сразу виден ответ типичного фанатка, который думает, что умеет пользоваться ИИ))
Формально он ответил чушь. DTO объектом не является. Ни при каком контексте и умении задавать вопросы это меняться не должно.
DTO это по вашему не объект?
Именно. Объект определяется смыслом, а не синтаксисом. DTO это не объект с инкапсуляцией и инвариантом, а структура для передачи данных. А то, что в каком-то языке программирования нет для передачи данных отдельных конструкций вроде struct или record и это всё тоже приходится писать как class – это особенности конкретного языка программирования. Отсюда же распространённые случаи того, что программист на классах пишет процедурный код, думая что пишет объектно-ориентированный. Про это как раз был была большая стратья про структуры и объекты.
ИИ надо спрашивать конкретнее
Значит получаем, что на вопрос "является ли DTO объектом" ИИ изначально отвечает чушь. И новичок не способен это распознать и спросить конкретнее, так как не знает что и как надо уточнять.
Правило "Нужно больше золота контекста" не должно здесь так работать. Тем более при обучении чему-то новичка. На вопрос подобный этому желательно давать сухие определения и ссылки на источники, а не сразу нейросеткой компоновать ложный ответ на основе смежных мнений как про приготовление свиных крылышек.
Потому изначальный тезис "ИИ любое ООП за 10 минут пояснит" не является истиной.
В мире где все уже пишут клаудкодом, кто-то еще хочет продать ООП. кек :)
Одно другому не мешает.
Если клаудкод попросить организовать проект более аккуратно по тем же принципам SOLID и GRAP, то получатся слабосвязанные самодостаточные модули. Это позволит для каждой задачи работать нейросетью изолированно в контексте небольшого модуля, а не всей кучи кода. Эта модульность экономит токены и избавляет от размазывания контекста. А слабые связи и изоляция от GRASP и SOLID уменьшают вероятность внешних и внутренних поломок от неаккуратных изменений кода.
Так что архитектурные умения полезны даже с нейросетями.
Какой из этого сделать вывод и почему у всех разное отношении к ИИ? Почему кто-то им сильно доволен, а кто-то не очень. Дело принципе его работы и порой в сравнении с собой.
По принципу работы нейросеть сейчас ввиду ограничений способна только перекомпоновывать материал, на котором её обучили. И она делает только то, что от неё просят. А сама подумать и предложить более оптимальное или изобрести новое решение она не может.
Если вы новичок и пишете код или рисуете картины хуже чем в среднем по планете, то нейросеть оказывается умнее вас и это вам нравится. Вам кажется, что она способна сделать всё сама и её картинки или код идеальны. Можно вайб-кодить любые проекты прямо так.
Если же вы профи и делаете всё лучше чем в среднем, то нейросеть оказывается глупее вас и тогда вам это не нравится. Вы видите в её картинках или коде кучу косяков. То шесть пальцев, то тень не в ту сторону, то SQL-инъекция, то весь код в одной куче вместо разделения на DDD-контексты. Опытный художник или программист это заметит и попросит исправить. Неопытный не попросит и оставит так.
Если этих нюансов самому не знать и у нейросети этого не просить, то она сама этого не учтёт.
Так что нейросеть не заменяет, а дополняет программиста. Что программист просит, то нейросеть и делает. Теперь просто программист производит больше кода.
Дело в самом программисте, а не в нейросети. Если он сам продумает как сделать лучше и попросит сделать хорошо – получит хороший структурируемый и поддерживаемый людьми и нейросетями код. Попросит как обычно – скорее всего получит обычное невнятное месиво, в котором будут вязнуть люди и нейросети.
С опытом приходит понимание, что программирование не ограничивается только банальной генерацией тонн строк кода.
В мире где все уже пишут клаудкодом, кто-то еще хочет продать ООП. кек :)
Этому поколению это может и не нужно. Оставим ООП следующему поколению, которое будет потом разгребать это нейролегаси. Их и приглашаю к себе в эфир :)
Андейизи.
Дмитрий ЕлисеевНу вот. Оно выдаст правильный ответ только если ты его сам заранее знаешь и до него наводящими уточнениями подведёшь :)
michaelПолучить краткую справку о чем-то и научиться применять некий навык на практике - это разные ситуации. Поэтому и нужны книги и практические семинары, скринкасты и проч.
ArchilВот такое мне выдал ChatGPT Pro версия:
Да, DTO обычно называют объектом, но с оговоркой. DTO (Data Transfer Object) — это объект, структура или модель, предназначенная только для переноса данных между слоями, сервисами или по сети. Что важно: • технически — да, это объект, если он реализован как class/object; • по смыслу — это не доменный объект и не бизнес-сущность; • у DTO обычно нет бизнес-логики, только поля данных и иногда простая валидация/сериализация. Пример: class CreateUserDto { email: string; firstName: string; lastName: string; } Это объект в OOP-смысле, но его роль — просто контейнер данных. Точнее будет так: • Entity — объект предметной области с идентичностью; • Value Object — объект со смыслом и инвариантами; • DTO — объект для передачи данных. Так что ответ: да, DTO — это объект, но “транспортный”, а не бизнес-объект.
Дмитрий ЕлисеевИнтересно :)
Надо вдогонку спросить что он имел в виду под словом "модель"
СергейАвтор сражается с соломенным чучелом.
Открыл Claude на 20баксовой подписке, спросил Sonnet, даже не Opus.
**Да**, 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 это не объект с инкапсуляцией и инвариантом, а структура для передачи данных.
А это утверждение контекстно-зависимо и поэтому в общем случае ложно.
Понятие объекта определяется семантикой той или иной системы понятий. В случае ООП есть целый градиент из различных семантик, и поэтому делать утверждения о том как что-то в ООП чем-то является или не является достаточно бессмысленно без оговорки заданного контекста.
Дмитрий Елисеев> В случае ООП есть целый градиент из различных семантик
В случае ООП как раз нет никакого градиента и всё точно:
У объекта есть состояние и управляющее этим состоянием поведение.
Если же есть поведение, но нет состояния, то это процедура или функция.
Если есть только данные и нет поведения, то это структура данных.
Разные парадигмы этим и различаются:
Если данные в структуре, а поведение отдельно в изменяющей структуру процедуре, то это процедурное программирование (ПП).
Если данные в структуре, а поведение отдельно в функции, вычисляющей новую структуру на основе старой, то это функциональное программирование (ФП).
Если данные и поведение помещены вместе в одну штуку, то это объектное программирование (ООП). И такую штуку называют объектом.
Всё как только раскрыли в той статье.
Попытки уводить это в какие-то другие контексты смысла не имеет.
АндрейВы описали собственную ментальную модель парадигм программирования, и я нахожу ее родственной своей модели.
В Вашей голове никакого градиента ООП нет, но оно есть в обществе разработчиков, и ответы ИИ подтверждают это.
В своем описании парадигм Вы даете определение понятиям и формируете из них систему. Помимо Вас кто-то другой тоже может описать собственную ментальную модель через систему понятий с теми же названиями, но другими определениями, и в силу изоморфизма Карри-Говорда программирование как деятельность можно относить к формальным наукам и, как следствие, считать Вашу систему понятий, описывающую парадигмы программирования, и аналогичную систему понятий другого человека как независимые и с формальной стороны равнозначные. В связи с этим называть ответы ИИ правильными или неправильными в отрыве от терминологического контекста равносильно выражению собственных вкусов.
По моему субъективному мнению свойство правильно/неправильно, принадлежащее какому-либо утверждению, существует только относительно определенных критериев, и любое утверждение само по себе этим свойством не обладает. Относительно Ваших определений ответы ИИ неправильны. Относительно других определений они могут быть правильными.
Формальные критерии позволят Вам и другим людям логически вывести Ваши суждения и формально доказать их обоснованность, позволят снизить количество возможных контрпродуктивных трений, а обмен знаниями сделать доступнее. Для меня это имеет смысл, и исходя из Вашего скурпулезного, в хорошем смысле дотошного, метода обучения с популяризацией лучших практик и того факта, что ИИ в своих ответах по умолчанию не описывает используемую систему координат, предполагаю имеет смысл и для Вас.
Дмитрий Елисеев> В связи с этим называть ответы ИИ правильными или неправильными в отрыве от терминологического контекста равносильно выражению собственных вкусов.
> Относительно Ваших определений ответы ИИ неправильны. Относительно других определений они могут быть правильными.
Пардон, но какое бы определение в книгах или статьях не найти, все они однозначно определяют объект в ООП как сущность, объединяющую состояние (данные) и поведение (действия).
А всё потому, что программист-микробиолог Алан Кей изобретал ООП в Smalltalk по аналогии с системой живых клеток в организме, которые он наблюдал в микроскоп на своей другой работе.
Как подход, в котором вместо написания отдельных структур и процедур или функций процедурного или функционального подходов программа воплощается как система из умных живущих своей жизнью самостоятельных объектов со своим состоянием, выполняющих свою работу и обменивающихся сообщениями друг с другом. Как живые клетки в организме или как отдельные компьютеры в сети. А теперь так делают самостоятельные общающиеся сообщениями микросервисы.
То есть раньше в ПП и ФП данные и поведение программировались раздельно в структурах и процедурах/функциях. А Кей всего лишь предложил складывать данные и поведение вместе в одну штуку, которую и назвал объектом. И пусть теперь объект самостоятельно своими данными управляет.
В этом и вся суть ООП. Никаких вкусовщин и градиентов в этом не было и нет. Терминологический контекст всего один и определение по сути всего одно, что объект – это умная живущая своей жизнью штука со своим состоянием и поведением. Если состояния или поведениея не хватает, то это уже по такой логике не объект:
Штука только с данными без действий – это структура данных.
Штука только с действием без данных – это процедура или функция.
Потому пустую структуру с данными без поведения называть объектом просто потому, что она технически в конкретном языке написана как class вместо struct или record ни в каком контексте не корректно. Это всего лишь костыль из-за ограниченности синтаксиса конкретного языка программирования.
> В Вашей голове никакого градиента ООП нет, но оно есть в обществе разработчиков, и ответы ИИ подтверждают это.
То, что 95% людей измеряют вес в килограммах не говорит, что Ньютон неправ.
Так и то, что думает сообщество разработчиков про ООП не говорит, что Кей неправ.
АндрейМы с Вами как будто немного разные вещи обсуждаем.
> То, что 95% людей измеряют вес в килограммах не говорит, что Ньютон неправ.
> Так и то, что думает сообщество разработчиков про ООП не говорит, что Кей неправ.
Полностью с этими утверждениями согласен, так же как и с тем, что данные посылки ничего не говорят и в пользу правоты Ньютона или Кея, так как это не связанные вещи. Но если мы формально определим критерием оценивания правоты Ньютона соответствие с истинностью утверждения "95% людей измеряют вес в килограммах", то тогда в зависимости от истинности этого утверждения по нашим критериям (какими бы странными они ни были) Ньютон будет прав или неправ.
> ...какое бы определение в книгах или статьях не найти, все они однозначно определяют объект в ООП как сущность, объединяющую состояние (данные) и поведение (действия).
Вы утверждаете, что Ваше определение единственное, а я утверждаю обратное. Разрешим наш спор сравнением вашего определения с существующими.
В предыдущем сообщении вы даете несколько определений:
> (1) ...объект в ООП как сущность, объединяющую состояние (данные) и поведение (действия).
> (2) ...из умных живущих своей жизнью самостоятельных объектов со своим состоянием, выполняющих свою работу и обменивающихся сообщениями друг с другом.
> (3) ...объект – это умная живущая своей жизнью штука со своим состоянием и поведением.
> (4) Если состояния или поведениея не хватает, то это уже по такой логике не объект
Определение (3) можно исключить, так как оно дублирует информацию из (1) и (2).
Определение (4) задает два обязательных критерия: наличие и состояния, и поведения.
Определение (1) задает те же критерии, что и (4), и поэтому их можно сократить до определения (1).
Определение (2) добавляет новый критерий - обмен сообщениями. Если сравнивать (1) и (2) по количеству критериев, то тогда это разные определения. По критерию эквивалентности они тоже различны, так как объект по (2) всегда будет соответствовать (1), но не наоборот. Если в Вашем понимании понятие поведения включает в себя обмен сообщениями, то тогда (1) и (2) равнозначны, но утверждение "все они однозначно определяют объект" неверно, так как (2) может трактоваться по разному.
Допустим, все Ваши определения не имеют между собой различий и можно взять (1) как эталонное. Сравним его с определением и уточнениями Алана Кея.
Определение:
> ...everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages.
> ...всё, что мы можем описать, может быть представлено рекурсивной композицией единственного вида поведенческого строительного блока, который скрывает свою комбинацию состояния и процесса внутри себя и с которым можно взаимодействовать только посредством обмена сообщениями.
Уточнения:
> I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages...
> Я думал об объектах как о биологических клетках и/или отдельных компьютерах в сети, способных общаться только с помощью сообщений...
> I'm sorry that I long ago coined the term 'objects' for this topic because it gets many people to focus on the lesser idea. The big idea is 'messaging'...
> Я сожалею, что давным-давно ввел термин "объекты" для этой темы, потому что он заставляет многих людей сосредотачиваться на второстепенной идее. Главная идея — это "обмен сообщениями"...
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
> ООП для меня означает только обмен сообщениями, локальное удержание, защиту и сокрытие состояния-процесса, а также экстремально позднее связывание всего.
В определении Алана Кея можно выделить следующие критерии: состояние-процесс, их защиту и сокрытие, а также взаимодействие только посредством обмена сообщениями. По количеству критериев они различны. По соответствию критериев они тоже различны, так как процесс и поведение не равнозначные понятия. Помимо этого отдельно выделяется отношение Алана Кея к наличию взаимодействия с объектом только через обмен сообщениями. В Вашем определении этот пункт не ключевой.
Сравнение доказало наличие различий между определениями.
Сравним так же отличия с другими определениями, признанных авторов.
Гради Буч и Крэг Ларман выделяют отдельно критерий идентичности:
> An object is a concrete manifestation of an abstraction; an entity with a well-defined boundary and identity that encapsulates state and behavior; an instance of a class.
> Объект — это конкретное проявление абстракции; сущность с чётко определённой границей и идентичностью, которая инкапсулирует состояние и поведение; экземпляр класса.
> An object is characterized by identity, state, and behavior. Identity is the property of an object that distinguishes it from all others.
> Объект характеризуется идентичностью, состоянием и поведением. Идентичность — это свойство объекта, которое отличает его от всех других.
Тед Ньюард выделяет отдельно идентичность и инкапсуляцию:
> Object systems are typically characterized by four basic components: identity, state, behavior and encapsulation.
> Объектные системы обычно характеризуются четырьмя базовыми компонентами: идентичностью, состоянием, поведением и инкапсуляцией.
Определения Мартина Фаулера и SICP совпадают с Вашими:
> Domain Model — An object model of the domain that incorporates both behavior and data.
> Модель предметной области — Объектная модель предметной области, которая включает в себя как поведение, так и данные.
> An object is a computational entity that has state and behavior.
> Объект — это вычислительная сущность, обладающая состоянием и поведением.
Сравнение других существующий определений так же доказывает наличие отличных от Вашего.
Но по итогам проведенного анализа хочу признать, что описываемый мною ранее градиент очень слабо выражен, а Ваше определение объекта, если и не соответствует другим, то точно не противоречит им, за исключением определения Алана Кея в критерии состояние-процесса.
Помимо этого хочу отметить мое изначальное утверждение:
>> DTO это не объект с инкапсуляцией и инвариантом, а структура для передачи данных.
> А это утверждение контекстно-зависимо и поэтому в общем случае ложно.
Оно формально корректно (можно задать любое определение), но относительно всех рассмотренных тут определений это неправда.
Дмитрий Елисеев> Но если мы формально определим критерием оценивания правоты Ньютона соответствие с истинностью утверждения "95% людей измеряют вес в килограммах", то тогда в зависимости от истинности этого утверждения по нашим критериям Ньютон будет прав или неправ.
Ну это фаталити :)
Пройтись философией по физике и допустить вариант, что Ньютон, меряющий силу в Ньютонах, неправ лишь потому, что другие люди меряют вес в единицах массы.
Красиво получилось :)
А потом нейроречь о том, что как будто бы все эти определения разные. Что процесс не равнозначен поведению. Что слова про защиту и сокрытие отличаются от слов про инвариант и инкапсуляцию. Это уже поиск мнимых различий.
Все действия в процессе жизненного цикла объекта производятся его поведением. Объект как раз защищает инвариант состояния инкапсуляцией и скрывает состояние и логику от прямого внешнего вмешательства для усиления этой же инкапсуляции. Эти все определения про одно и то же. А обмен сообщениями происходит снаружи объекта, а не внутри, потому на устройство объекта никак не влияет.
Андрей> А потом нейроречь о том, что как будто бы все эти определения разные.
Не очень красиво с Вашей стороны (особенно с таким высоким авторитетом в сообществе) вешать принижающие ярлыки без приведения доводов.
Весь текст, за исключением определений и их переводов, придуман и написан лично мною и полностью без участия ИИ. Перед публикацией своего сообщения для каждого определения эксперта, за исключением совпадающих с Вашим, выполнялась проверка на нейрослоп.
Определение и все уточнения Алана Кея были взяты из этих источников:
1) https://worrydream.com/EarlyHistoryOfSmalltalk/
2) https://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
3) https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
На определение Гради Буча ссылаются несколько вторичных источников:
1) https://rd.springer.com/chapter/10.1007/978-1-4899-7463-1_3
2) https://ideas.repec.org/h/spr/spochp/978-1-4899-7463-1_3.html
В случае определения Крэга Лармана проверка на нейрослоп оказалась поверхностной. Описанное определение действительно существует, но оно принадлежит университету Олд Доминион:
-- https://www.cs.odu.edu/~zeil/cs330/web/website/Lectures/overview/pages/object.html
Ни первичных, ни вторичных ссылок на определение понятия объекта Крэга Лармана при повторной проверки я не нашел.
Тед Ньюард дает определение объекта в статье "Вьетнам компьютерной науки":
1) en https://web.archive.org/web/20220711013001/https://web.archive.org/web/20060704030226/http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
2) ru https://citforum.ru/database/articles/vietnam/
Определения Мартина Фаулера и SICP в прошлом сообщении я не стал проверять, так как они по смыслу совпадают с Вашим, но для чистоты нашего обсуждения проверим и их.
Определение Мартина Фаулера совпадает и его можно посмотреть на сайте автора:
-- https://martinfowler.com/eaaCatalog/domainModel.html
В случае SICP определение выдумано. Оригинальное определение можно посмотреть в разделе 3.1 в первом абзаце книги:
-- https://web.mit.edu/6.001/6.037/sicp.pdf
> We ordinarily view the world as populated by independent objects, each of which has a state that changes over time. An object is said to “have state” if its behavior is influenced by its history.
> Обычно мы рассматриваем мир как населённый независимыми объектами, каждый из которых обладает состоянием, изменяющимся с течением времени. Объект называют "имеющим состояние", если на его поведение влияет его история.
После перепроверки источников выводы сравнения определений из предыдущего моего сообщения не изменились.
> Что слова про защиту и сокрытие отличаются от слов про инвариант и инкапсуляцию. Это уже поиск мнимых различий.
Это неправда, при сравнении я этих различий не делал и Вы можете в этом убедиться, но прежде хочу отметить, что у меня нет цели девальвировать Ваш статус, спорить с Вами или ставить мою точку зрения выше Вашей и тем более использовать всякие ухищрения в виде мнимых различий или иных манипуляций для победы в споре. Моей целью было сообщить Вам об ошибке в статье. Вы привели доводы в свою защиту, а я в защиту наличия ошибки. После этого Вы еще раз привели аргументы, а я с ними не согласился и поэтому провел анализ и сравнение, которые сказали "ну как бы да, определения отличаются, кто-то выделяет отдельно идентификацию, кто-то инкапсуляцию, но они не противоречат друг другу, и поэтому этими формальными различиями на практике можно пренебречь, так как они говорят по сути об одном". И своим последним предложением в предыдущем сообщении я вам об этом сообщил. То есть результаты анализа показали, что у Вас нет ошибки: в мировой практике в целом одно мнение в определении объекта в ООП, и в соответствии с этим определением DTO не объект, поэтому спор разрешен, причем в Вашу пользу.
Единственное что оставляет неоднозначность для меня это определение объекта Алана Кея в части:
> ...behavioral building block that hides its combination of state and process...
Он в одном определении использовал и понятие "поведение", и понятие "процесс". По этой причине я не могу однозначно сказать, считал ли Алан Кей их взаимозаменяемыми понятиями в данном контексте или нет.
Как бы Вы объяснили причину выбора именно таких слов?
> Пройтись философией по физике и допустить вариант, что Ньютон, меряющий силу в Ньютонах, неправ лишь потому, что другие люди меряют вес в единицах массы.
Физика относится к естественным наукам, а логика и математика к формальным наукам. Наше недопонимание в том, что Вы говорите о Ньютоне как об объекте материального мира, а я как об объекте идеального (логического) мира. Вы можете написать на php: $p ? "Ньютон неправ" : "Ньютон прав", и в зависимости от предиката будет выбрано одно из значений. Если еще есть недопонимание или интерес в этом вопросе, то я готов раскрыть эту тему шире.
Дмитрий Елисеев> ...behavioral building block that hides its combination of state and process...
> Он в одном определении использовал и понятие "поведение", и понятие "процесс". Как бы Вы объяснили причину выбора именно таких слов?
Объяснил бы нежеланием использовать одно слово два раза в одном предложении. Мог бы использовать какие-нибудь value and action. От выбора слов суть не меняется.
> Наше недопонимание в том, что Вы говорите о Ньютоне как об объекте материального мира, а я как об объекте идеального (логического) мира.
Именно.
Я говорю о реальном мире и практической логике, где есть последовательность и ограничения. В этом есть прикладной смысл.
Вы говорите о фантастическом мире, где возможно придумать всё что хочется. Эти рассуждения обычно порождают только бесконечное словоблудие про курицу и яйцо и вечный двигатель.
Андрей> От выбора слов суть не меняется.
По разному бывает. Очень рекомендую почитать про семантический треугольник Готлоба Фреге. Он хорошо демонстрирует разницу между обозначением, объектом и смыслом.
> Я говорю о реальном мире и практической логике, где есть последовательность и ограничения. В этом есть прикладной смысл.
Последовательность и ограничения существуют в формальной логике в виде различных исчислений высказываний и законов, и практическая логика есть ни что иное как применение формальной логики к логическим моделям объектов предметной области. Прикладной смысл в получении результатов практической логики.
> Вы говорите о фантастическом мире, где возможно придумать всё что хочется.
Не совсем так. Я говорю о том, что важно различать фантастический мир от реального, то есть отличать математику от физики, логическую модель объекта от самого объекта, программу от описываемой ею предметной области. Для первого мы сами определяем ограничения, у второго они определены реальностью.
> Вы говорите о фантастическом мире, где возможно придумать всё что хочется. Эти рассуждения обычно порождают только бесконечное словоблудие про курицу и яйцо и вечный двигатель.
Практическое применение логики никаких словоблудий не допустит, но сделает обсуждение конструктивным.
Эти рассуждения порождают такие вещи как неевклидову геометрию.
Эти рассуждения могут сподвигнуть разработчика задуматься о своих возможностях и последствиях их применения, и, после, лучше разобраться в том какие проблемы решает иммутабельность, почему надо следить за соблюдением инвариантов и почему лучше не использовать глобальные переменные. И если он углубиться в эту тему, то поймет, что полные по Тьюрингу ЯП имеют логические противоречия, из которых можно вывести все что угодно, и поэтому ответственность за их недопущение в программах лежит на нем и его коллегах. После чего практическая польза применения таких подходов как DDD и TDD станет для него очевидна, что потенциально поспособствует их внедрению в работе и их популяризации среди коллег.
На мой взгляд, это более чем достойные причины для рассуждений.
Андрей> описываемый мною ранее градиент очень слабо выражен
Тут ошибка.
В изначальном сообщении я писал про градиент ООП, а не про градиент понятия объекта в ООП. Итоги моего анализа про второе.
Насчет градиента ООП требуется отдельный анализ существующих определений.
АлександрGPT 5.4
Да. DTO — это объект, но особого назначения. DTO расшифровывается как Data Transfer Object, по-русски: объект передачи данных. Он нужен, чтобы передать набор данных из одного слоя в другой, например: Presentation -> Application Контроллер получил HTTP-запрос, собрал DTO и передал его в use case. Пример: final class CreateTenantData { public function __construct( public readonly string $name, public readonly string $ownerEmail, public readonly string $storeName, ) { } } Использование: $data = new CreateTenantData( name: $request->request->get('name'), ownerEmail: $request->request->get('owner_email'), storeName: $request->request->get('store_name'), ); $createTenantUseCase->execute($data); Важно: DTO обычно не содержит бизнес-логику. Он просто несет данные. Разница: Tenant Это доменная сущность. У нее есть смысл и поведение: арендатор, статус, правила. CreateTenantData Это DTO. Просто данные для сценария “создать арендатора”. Шпаргалка: DTO = объект-пакет с данными Entity = объект бизнес-смысла UseCase = объект-сценарий Service = объект, который выполняет работу
Дмитрий ЕлисеевОпять :)
Правильная шпаргалка это:
АнтонДмитрий уточняйте, что правильная для Вас шпаргалка. Т.к. вы воспринимаете объект как сущность. А объект это более широкое понятие. Если хотите, то структура - это тоже объект, просто синтаксис доклассовый.
Дмитрий Елисеев> А объект это более широкое понятие
Объект в программировании – это чёткое конкретное узкое понятие. Синтаксис какого-то конкретного языка программирования значения не имеет.
Антон> Объект в программировании – это чёткое конкретное узкое понятие. Синтаксис какого-то конкретного языка программирования значения не имеет.
Очень даже имеет. Любой экземпляр класса является объектом по определению. А что такое структура в ООП, не припомню такого понятия, а вот как синтаксис конкретных языков программирования да существует и даже использовалась мной вместо классов в 90х на С.
maleksЧто за время то всратое , с этим ии.
Дошло до того, у нас, на рабке, что заставляют шарить экран, ставят задачу, и показывай как ты её с claude решишь. Докажи что ты современный, и со скоростью звука лепишь функционал. На то что там за код получится, всем пох уже, даже не требуют тут ничего.
Поддерживаемый, расширяемый, solid - это как слова из прошлого
Dzianis R.ИИ полезен в (работе|обучении) как инструмент, когда за плечами уже есть опыт и знания - эти оба процесса становятся эффективней.
Отказаться от обучения, ссылаясь на то что "ИИ всему научит и всё решит" - это недальновидно.
Бесполезно переубеждать людей в обратном. Когда придет время "платить цену" своих решений, вот тогда человек сможет понять на сколько его взгляды и убеждения соответствовали полученному результату.
Это как раньше.
Одни работают с Тильдой, а другие с Symfony.
Можно сказать что оба разрабатывают сайты, но есть нюансы....