Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября, Санкт-Петербург
- -
. . . . Егор Бугаенко, Teamed.io - ORM - это обидно
Международная Java-конференция JPoint 2016
Москва, 22-23 апреля 2016
Object-Relational Mapping(JPA/Hibernate) is a design pattern, which is very popular and totally anti basic principles of object-oriented programming.
Вижу доклад Егора - иду писать декоратор.
В голос! :D Но вы забыли дописать вначале: "я человек простой -- " :D
Егор Бугаенко - мой любимый Stand Up комик
Люди будут 10 раз изобретать Smalltalk, и не замечать, что у них уже есть Smalltalk.
Уже давно не вводят в использование новые языки, если вы не заметили. Так что это сомнительный заход. Есть куча языков получше smalltalk, только никому не нужен язык без всего остального: без поддержки, без актуальных библиотек, без людей которые его знают.
Декораторно ориентированное программирование
Зачем делить приложение на уровни? Давайте лепить все в один объект
Вижу Егора - ставлю лайк. Конечно, сейчас немного подругому. Все на аннотациях, все пишут сервисы, репозитории, и контроллеры, но суть не особо поменялась. Бизнес-логика размазана, методы сервиса состоят либо из безумных манипуляций со стримами (и каждый лепит свои аналогичные стримы с новых сервисах), либо из new + set, set, set, set + return. И юнит-тестов хрен добьешься, ведь это г хрен протестируешь, тыщщу моков надо настроить. Гребцы гребут быстро, но что-то не туда.
Прокси в спринге отлично выполняют роль этих ваших декораторов) В некоторых сценариях это будет лучше И кстати, с помощью спринг и рефлексии можно делать декораторы в императивном виде, и даже оборачивать конкретные методы с помощью простой аннотации
Про MVC было продолжение на следующих выступлениях?
Егор - мой кумир!
Я "Щетаю" что hibernate и репозиторий паттерн - в целом, отвратительные вещи. И тут полностью поддерживаю Егора. Почему, в swift когда мы делаем layout.setFrame(), то он двигает сам себя на экране? И не делаем мы это, через какой то LayoutFrameHandler.moveLayout(layout, frame) ???? Потому что мы бы умерли от этого С style... это "мерзость" простите так разделять ответственности. Если мне как User нужно помнить свое имя, то я его храню в своем мозгу и в любой момент могу обратится напрямую к контроллеру памяти/мозгу, а не звать для этого дядю Васю/ака hibernate framework что бы он построил запрос для моего мозга.
Я вот все смотрю Егора и он мне в принципе нравится 👍, но никак не могу понять шутит он или серьезно. Почему-то всегда кажется, что он просто стебется и проверяет компетентность публики, нет?
дядька хорош
Хороший был stand-up. Особенно угарнул с шутки про получение xml для последующего форматирования в json. Пока слушал совсем забыл что у нас существуют паттерны которые решают все эти проблемы.
39:40 Евгений Борисов?
дак он же говорит нам про луковую архитектуру - в центре бизнес объект, остальное снаружи, на самом деле бизнес объект не обязательно по его словам должен сам реализовывать всё, например запись в БД, конвертирование себя в json и т.д....он может просто объявить интерфейсы для этого, да, теперь это уже не класс, а сборка, но все же...луковая же...если я неправ, то поправьте? Или же, то что он имеет ввиду копия эктив рекорд, только не обязательно объект в точности копирует реляционную модель?
Как я понял, он про то что объект должен сам в себе реализовать работу и с бд и уметь отдавать себя в xml, json итд. Не похоже на луковую архитектуру, больше напоминает антипаттерн GodObject
@@thunderboy2208activeRecord
Сейчас он блоггер
Я реально согласен с тем чтоб классы не были по 1000-2000 и более строк ))
Почему все пиздят хибер за его скорость, что не оптимально работает и т.п. ??? и никто не делает докладов как надо правильно им пользоваться? Почему никто на докладах не рассказывает, что благодаря хиберу легке работать сразу несколькими таблицами >= 10 вместо того чтобы писать адские sql запросы с 10 join'ами???
Потому что с скл легко работать, если ты его знаешь?
Егор разобрался в хибернейте, докладывает, что понял )))
20:14 в php так не пишут уже давным давно
А как
Некие фантазии, абсолютно не практично выглядящие и пытающиеся решить надуманную проблему выстрелом себе в ногу. При том с апломбом мессии.
Мне кажется такие практики которые тут обсуждаются ведут к нервным срывам программистов, и все хорошие патерны тут критикуются а плохие патерны привозносятся.
Анемичные классы это называет, когда строят DTO, а все потому что в JAVA забрали возможность создавать модули, все только классами... Ограничения...
нет взять норм язык с монадами =)
вот все классно, но возникает интересный вопрос - тупые объекты с данными (POJO) плохо, но вот мне надо вернуть из метода имя и фамилию пользователя и в каком виде я это должен вернуть по мнению автора
у Вас будет метод: user.serializeNameWithSurnameIntoJson(), без аргументов, который внутри не только выполнит сериализацию в String, но и запишет её в HttpServletResponse короче, не знаю, как Вы, а я категорически против и, если честно, пока не готов согласиться с Егором, что такой код более "чистый" и управляемый
@@user-vl4zr6py9s и представьте что будет внутри этого метода, мы выберем из базы записи и сразу начнем пихать данные из ResultSet в какие небуть JsonObject, агрегируя их в JsonArray, мы шли в ООП за абстракцией, а в итоге будем работать с примитивами, не находите, причем наш User превращается в God Object, не находите
@@_ArturMamedov_ тут наверное подразумевается, что класс User - это statefull объекты, то есть Вы сперва методом user.loadById(), например, загрузили из базы, затем другим методом сериализовали в JSON, а так - да, god object, при этом, даже если сериализация и чтение из бд в разных объектах, все равно придется побегать к интерактивному подходу в коде, последовательно вызвав сперва чтение, затем сериализацию и запись в response, ну а в случае с Вашим примером так вообще получается, что мы процедурный код просто прячем "под ковёр" объекта. Вобщем согласен с Вами, и получается, что мы только усложняем код и делаем его менее управляемым.
Вы точно смотрели видео? ) Вам ничего не может быть нужно "вернуть из объекта".
DTO != VO
Процедуры и функции точно так же были придуманы, чтобы уменьшить количество информации в голове программиста. На самом деле любая модульная система реализует ту же задачу. У автора ООП головного мзга
single responsibility как раз таки нарушается, ваш объект отвечает за бизнес логику и за базу данных, такое себе
42:00 когда тебя загнали в тупик, нужно говорить "это прекрасно"
Забавно слышать как ломает аудиторию и они аж с места кричат от боли
Откровенно говоря, такое объяснение ООП (такой пример - ужас) только путает людей и не дает четкого понимания, что такое ООП и как эта задача должна решаться. 1. Слой базы данных и предоставление доступа на запись и получение должен находится в отдельном классе. В нем должна быть реализована основная базовая логика работы с БД. Все классы логики, которые работают с базой, в качестве проперти должны иметь доступ к этому объекту. Тогда при смене БД нам не придется растекаться по всему проекту и искать вот такие вот классы пишущие себя в базу и исправлять их. Ужас. 2. Анемичные объекты плохо. Безусловно. И это действительно так. Но это не значит, что представленное решение, перестало быть анемичной моделью. Нет. Оно все еще анемичная модель, просто ее сеттер и геттер сильно повязан на базе. Перестала бы анемичная модель быть анемичной, когда та самая логика расчета значения тайтла, о котором говорил докладчик, была перенесена на уровень объекта, а не находилась извне. И тогда она перестанет быть анемичной. Вся логика, которая связана с пропертями объекта будет инкапсулирована в объект. А не наоборот, логика отдельно, а запись в базу в проперти. Фе. 3. ДТО не плохо. Взаимодействие между объектами логики, простая передача структур между методами, чтобы не делать 500 параметров, рано или поздно потребует выделение анемичных интерфейсов (те в которых описаны только проперти, и нет методов). Наследники интерфейсов - это те самые ДТО. Если у вас есть взаимодействие, между проектами, системами, слоями приложений, клиентом и бэком - вам обязательно нужно иметь ДТО. Потому что в этих прослойках не может существовать логика. Ее там быть не должно. Именно в этом суть и цель ДТО. 4. Объект и класс это не одно и тоже. ООП говорит о работе с объектами логики - классами. Объекты же это данные. И смешивать эти понятия не совсем корректно. 5. ActiveRecord гораздо более серьезный антипаттерн, чем использование ОРМ. Простое объяснение почему: а. попробуйте сменить с таким подходом тип БД и посмотрите, как удобно вам это получится сделать. б. Попробуйте разделить проект на разные базы - и вы увидете насколько это тяжело. в. Попробуйте переделать структуру базы данных - и вы умрете. По сути правильная структура решения должна была бы выглядеть следующим образом. 1. Класс доступа к БД и не более того. 2. Классы отвечающие за запись в базу данных и работу с ней имеют доступ к объекту ОРМ и привязаны к определенной таблице в БД или связке таблиц. Они не знают о БД напрямую - они знают о ДТО таблицы которую обслуживают (и только они знают), и о том, какой интерфейс для объекта логики нужно вернуть наружу. 3. Классы ДТО для работы с БД, которые четко отображают структуру БД (не обязательно 1 к 1 если что, один ДТО может иметь в себе лишь часть полей из базы) и позволяют разрабу разобраться с тем, как это все хранится. 4. Объекты логики используют класс доступа к таблицам когда им необходимо. Они не знают вообще о БД. Вообще. Зато прекрасно знают об объектах логики. Трансферах, расчетах бюджета, обработке и тп. И тогда, при смене БД или ее структуры - вам не нужно будет менять миллиард классов. Только классы связанные с БД. Если у вас ДИ вы просто переподключите нужный вам класс доступа к БД или к структуры в БД. И меняться это будет легко и понятно. А представленный пример ужасен. Реально ужасен. И не удивлен, что люди вообще не поняли, в чем проблема с ОРМами
Куча ошибок в коде. Доклад хэйтера.
"Надо доверять объектам, надо уважать объекты" - Надо встать перед ними на колени и молить о прощении за годы эксплуатации, предрассудков и гнета по отношению к ним. Давайте, всем залом бухайтесь на четвереньки и начинайте каяться и биться лбом об пол! Кто вообще позволил шизику нести со сцены весь этот бред?
Прям Objects Lives Matter))
Докладчик троль
На вопросы начинает гадать. Неправильный подход. Наоборот типы и набор функций. В калькуляторе значения вводятся отдельно. Калькулятор объект.
господи, какую чушь городит) харизматичный дядька)
вот у докладчика бомбанет, когда коммьюните отвергнет его идеи и через 10 лет его язык так и не станет мегапопулярным ))) это ж надо, столько обиды заиметь на имеющиеся инструменты и пойти свое колесо изобретать ))) А языки нынче модно писать...
не знаю докладчика но чувак порет какую-то дичь. как будто сектант. нет ничего зазорного использовать классы как объекты хранения и передачи данных (DTO). тем более объектно-ориентированное программирование позволяет это делать и при этом соблюдены принципы SOLID. не надо засорять людям мозг.
Исходя из слов Егора мы просто добавляем 1 абстракцию на обращение к БД, вместо ORM прослойки а далее добавляем по n-количеству абстракций для SRP. Мне кажется или в таком случае кэширующий декоратор объекта будет делать 2 вещи, а именно: 1) Обрабатывать объект 2) Использовать кэш для случаев, когда много обращений? Можно было добавить АОП и накинуть @Hasheble(class = "наш класс") и класс бы явно уменьшился и мы бы могли так же имплементировать 1 аспект для конкретного класса вместо построения одной абстракции над классом. То что доклад про ООП не говорит о том, что ООП надо пихать постоянно и везде, поскольку как аспекты не называй они все равно аспекты
Пьяный программист теперь должен открывать свой ноут и говорить: "Мой объект, я тебя уважаю! А ты меня уважаешь?".
ШЕДЕВР )
Как сделать доклад запоминающимся? Расскажи что-нибудь, с чем аудитория будет несогласно настолько, что не может утерпеть до сессии вопросов и начинает орать прямо с места, всем залом. А в ответ - "Это же хорошо!". Отличный доклад, заставляет всех подумать и побиться за свои привычки в ООП. При том что речь-то - про запиcь в БД (про ОРМ же), и про ActiveRecord
Это же ActiveRecord, битый час про ActiveRecord - серьезно?
Да походу ActiveRecord
Вообще не ActiveRecord
Не слышно вопросов из зала, в остальном качество хорошее, спасибо
Главная проблема доклада, на мой взгляд - отсутствие хоть сколько-нибудь сложных примеров. Просто не верю, что с таким подходом можно написать и после этого не просто поддерживать, а активно развивать систему более чем в 100-200 тыс. строк кода. А на уровне HelloWorld`ов подойдёт вообще любая концепция кодирования...
ActiveRecord и ООП для хело волдов? Мдя.
Раньше когда я смотрел подобные доклады я восхищался, но поработав со всеми этими технологиями годы, возвращаюсь к таким докладам и у меня складывается впечатление, что докладчик кроме книг в реальной жизни с этим не работал. Любая технология имеет изъяны. Я не топлю за hibernate, меня он тоже подбешивает. Я топлю за улучшение инструментов путем коммитов в их код, а не платными лекциями о том, какие они плохие.
На мой взгляд аргументация Егора не убедительна - "это же не ООП" - ну и что - если в данном случае процедурное программирование удобнее - почему его не использовать? Стиль для человека а не человек для стиля. "Я хочу умные объекты!" - а я хочу объекты которые делают то что мне надо. Простые бины как раз это и делают. Неубедителен и код с декарируемым Entity - в хибере вполне можно написать перехватчик события и это будет ничуть не менее элегантно чем декоратор (я тоже люблю декораторы но не зацикливаюсь на них!). Ну и, наконец - я готов принять и авторский подход с "умными" объектами - но не хочу для этого писать свой фреймворк. Будет фреймворк сравнимый по удобности с хибером - тогда и поговорим.
43:00 Вся суть подхода
Интересный доклад. Хорошее дополнение от Николая.
Фаулер о проблеме Anemic Domain Model ещё в 2003 писал. А воз и ныне там.
не обязательно все пихать в один GodObject. Домен должен решать проблему предметной области. сохраняемость данных лежит в другой плоскости - инфраструктура. то что вокруг домена но не обязательная часть - онион-архитектура.
Егор, ты все верно мыслишь. Твоя идея понятна. Мы пишем на ООП средствами не ООП. Класс в нашем понимании - это некая "глобальная супер функция", просто вынесенная в отдельный класс. Мне кажется, с текущим техническим подходом к ООП, в том числе и в Java, тебе сложно будет добиваться своей идеи. Ты писал, что собираешься свой язык писать, который будет четко следовать фарватеру ООП. Удачи тебе желаю! Искренне! Жду первой альфа версии! Переучивать java как язык - бесполезно. нужен новый язык, где нет того, что java позволяет, и того чего нет в java. Нужен новый "интерфейс", не в том понятии, в котором он преподносится в java, а я имею в виду - возможно новые номенклатуры языка нужны, которые будут правильно описывать сущность. Классов видимо не будет, но будет не замена таковых, а будет именно новое определение, возможно даже со сдвигом в мышлении, согласен - класс во всех книгах преподается как супер что-то, что имеет свое хранилище и действо. Правильно сказал твой - ты апостол, а опостолу не легко :) удачи!
Что-то мне по сути докладов показалось, что человек просто любит декораторы и пытается везде их пропихнуть, даже там, где они не нужны
Шикарный доклад
Нужно больше классов (c)
Проблема в том, что при большом количестве декораторов и наслаивании объектов друг на друга, мы забываем о возможностях человеческой памяти и магическом числе "семь". Дойдя до 10 слоя, я легко забуду о том, что было на каких-то других. В памяти придется удерживать большое кол-во объектов. Сама тема конечно интересная и спорная.
Вы когда-нибудь дебажили Hierbnate или Eclipselink? Там где-то столько слоёв и есть.
Нет. Смотри у тебя есть юзер. У него есть логирующий декоратор, и sql декоратор. Потом ты new вкладываешь в new и в new и видишь все слои.
@@kep261 а потом, когда логика станет посложнее, нужно будет скролить вправо очень долго, чтобы все слои увидеть
@@user-ss2rj4wz5s ну или сидеть и ковырять спагетти код, заходя в каждый класс)
тема правильная, тема не раскрыта, стиль доклада вызывает желание убивать.
Раз в n лет появляется человек, который говорит: "Забудьте все что вы знали и делали до этого, вас всех обманули!")
Иногда такой человек оказывается прав)
Хорошо бы чтобы на амазоне продаваемая книжка показала хотя бы один вразумительный пример использования. К сожалению пример содержит нечто похожее в самом выступлении - какой то мутный hello world.
Ааа, блин, это тот самый yegor256, который топит за объекты. Вспомнил его. Обсуждали уже его подходы.
Обидно, что так негативно восприняли
Так а толку. Если не нравится эта ОРМ, то сделайте форк и покажите как надо. github.com/hibernate/hibernate-orm
Да нет, приятно послушать. Несогласие не означает негатив. Егор - большой молодец!
Есть такая вещь как DDD идея которой ядро энкапсулирующее бизнес логику, которая тестится юнит тестами. Все IO по краям - DB/REST/SOAP etc.
Тоже понял что речь о DDD, но все названия паттернов перекручены Модель вместо агрегата Users вместо репозитория Даже про контексты было немного инфы
Доклад прикольный, Егор харизматичный, идеи спорненькие....Золотая середина рулит..
Спасибо, очень интересный доклад. В моём понимании, это доклад о противоречиях ООП.
@@Petr-kh1lt Согласен. Мне тоже кажется, что функциональный подход более продуманный и логичный.
вы ещё вижуал фокспро не видели!
Проблема правильная. Решение любопытное. Доклад куцый. Стыдно что никто не упоминает Фаулера и не оперирует его терминологией. Только Николай вспомнил про Active Record. Но ни про Anemic, ни про Transaction Script ни слова. Никто не объясняет в какие объекты бизнес-транзакции помещать. В общем, вопросов на много больше чем ответов.
первый слайд и есть про anemic model
Я-то понимаю. Проблема в том что даже Фаулера не все понимают с его Anemic Model. И докладчик вместо того чтобы объяснить, ссылаясь на уже проделанную работу других в этой теме, сводит всё к аргументации "тут у нас True OOP, а вот тут нет". А давно устоявшуюся терминологию по вопросу почему-то подсказывают из зала. Тема отличная. Направление мыслей правильное. Но решения нет. Переделать всё на колбэки и Active Record это не решение. Отказаться от всех современных фреймверков это тоже не решение. И, что самое забавное, это притянутый за уши ORM, который к проблеме имеет посредственное отношение. А всего-то надо было взять какой-нибудь Spring Boot Hello World и показать на каждом слое как можно было сделать иначе.
@@wjblazkowicz а почему orm притянутый за уши? Это как я понял пример проблемы - что реляционность размазана по всему приложению
@@johnconstantine6331 притянутый за уши потому что никто на самом деле не мешает методы написать в классах сущностях. ORM это не запрещает. Обвинять его в этом сложно.
23:10 - Active Record. Какая прелесть.
Active Record без наследования?
я не бекенд разработчик, но уже наперед вижу очень много потенциальных проблем с таким подходом. Поэтому человек и не показывает сложные примеры. Он вероятно никогда не работал на нормальном большом проекте. Причем тут ооп, процедуршина. Как тебе удобно писать, а потом всем поддерживать так и пиши. Где процедурно, где ооп, а где использую функциональшину. Я к примеру привык к функциональному подходу и много чего делаю с его помощью. Это позволяет быстрее писать. Его также можно и нормально поддерживать и дебажить, если привыкнуть. Правда соглашусь что писать тесты не всегда удобно под него. Но концепция какого-то большого объекта это полный изврат. Во первых почти полностью теряется переиспользование кода. С его подходами по выгрузке данных из базы или записи можно нарваться на большие проблемы с ресурсами, особенно если это какая-то большая живая система.
Mvc во фронте уже раскусили: react предлагает совмещать разметку и логику в своих компонентах. Что касается паттерна Repository, домены нам заменяют нехватку гибкости java в структурах данных, сам по себе репозиторий похож на тот самый любимый объект который знает как его сохранить и тд.
React предлагает полностью отделять разметку и логику. Посмотрите на redux и прочее. Вся логика находится в отдельном методе, с которым оперируют через actions. Его легко тестировать. Сам реакт используется только в качестве разметки
не, опять не понимаю, черт я тупой ( я говорю: "эй юзер, переименую себя" юзер: "да без проблем, где мой конекшен, эй конекшен, на тебе запрос" конекшен:"эй, слюшай, ты меня не уважаешь, я тебе что, не объект, ты че в меня сиквелом тычешь? давай сюда иди, я сам знаю, что с тобой делать" юзер:"погоди, я тебе, что тупое хранилище данных, глупая структура? я так и знал, тебе ничего от меня, кроме полей не нужно!!!" все уходят в нул поинтер эксепшен. занавес.
Моё понимание: Акт 1. "Ваша вселенная" : Вы говорите: "эй, юзер, вот тебе новое имя -- переименуйся". Юзер: "ок, шеф, без проблем". (Вы идёте курить трубку) Акт 2. "Вселенная юзера". Смена декораций. Никакого юзера как сущности здесь не существует, юзер здесь -- это Вселенная, внутри которой и разворачиваются все события. Коннектор: я слышал голос Бога, который сказал мне: "юниту сего мира, нейму Ивану, надлежит имя поменять своё. Отныне, нейм Иван пусть зовется Борисом, ибо такова воля моя, юзера, Бога твоего единого". Коннектор (бормочет): хм... неизведынны пути Господни. Но я знаю как исполнить волю божью. (берет лопату и делает реквест): "update user set name = "Борис" where name = "Иван", -- получет error 0. Коннектор: Аллилуя! Акт 3. "Возврат обртно". Юзер: "эй, шеф..." Вы (вытаскиваете трубку изо рта): "...А? Чего тебе". Юзер: "все готово, теперь я Борис". Вы (выбиваете трубку, вздыхаете): "Отлично, спасибо". (Грустно уходите в закат пилить стопяцотую форму на вебе) Занавес.
А ведь "делать mock этой сессии" - это и есть ООП во всей своей красе. Я всё-таки не до конца понимаю, что имеет в виду докладчик.
Соглашусь, идти нужно от бизнес задачи, а не реляционной модели . То что, хибернейт медленный г..код не согласится только поклонник хибернейта. Но это ладно, есть более красивые реализации. Но и конкретного решения по теме я не увидел. Хоть бы ссылку на гитхаб дали.
Не благодарите github.com/
Не буду)
Вот какой-то true oo фреймворк автора github.com/yegor256/takes
Немного в шоке был, увидев этот "декоратор", сочувствую.
Хотел бы я увидеть реальный рабочий пример от Егора скажем какой нибудь простенький MVC в виде библиотеки книг который на том же спринге пишется ~за час. Я не хотел бы тратить время на монотонное создание сотен и тысяч файлов, вместо того что бы потратить час на разработку простенькой архитектуры
Хм, какой вы MVC хотите увидеть от человека, который считает MVC антипаттерном?
Простенькая библиотека книг, которая пишется за час на MVC, собирается за полчаса на MS Access без единой строчки кода. Вопрос задач, собираетесь ли вы свой прототип развивать и поддерживать.
тема правильная, но не раскрыта. Терминология не проработана. В комментах подсказывают особо больше полезности чем в докладе. Удивляет то что человек книгу написал, а самые простые вопросы вызывают негодование и удивление. Некоторые, как по мне, вообще в корне не правильно отвечены. Например где-то здесь kzhead.info/sun/ls-jcbuQgYmQeJE/bejne.html Егор говорит что все его обьекты имплементят один интерфейс. Странное решение которое и приводит к тому непониманию предмета публикой и дублированию изменений в коде. Обьект несёт КОНТРАКТЫ. Декорировать мы можем КОНТРАКТ и всё что мы делаем мы делаем по контракту. Когда приходит запрос на новый функционал - это новый контракт. В вызывающем коде мы получаем не пачку юзеров/постов/етц. - мы получаем пачку чего-то что реализует КОНТРАКТ! И тогда ни дублирования ни переписывания ни комбинаторного взрыва. Просто обьекты, которые реализуют множественные контракты.
Идеологические противники втащили SQL в свой язык на уровне синтаксиса, чтобы только люди меньше смотрели в сторону функциональщины, а этот возмущается, что в Hibernate SQL размазан по коду...
Какой-то религиозный фанатик, а не разработчик. С какой стати ООП == прекрасный код, функциональный == плохой код? Про apache spark смешно слушать, это по сути функциональный фреймворк.
он не говорит что функциональный код - плохой, он говорит что процедурный плохой
Функциональные мало от ооп отличается. Он говорит что процедурный сложнее поддерживать в больших приложениях. Всему своё место
ru.wikipedia.org/wiki/Функционал
При данном подходе вся логика приложения со временем спустится в объект! И мы как раз получим не ООП, а старую процедурку! У каждого объекта (сущнорсти) должно быть множественно число! Это вообще пиздец! Вы что там курите? MVC - антипаттерн )) В завершении доклада нужно было произнести фразу "Земля плоская!"
Лол. Да, вся логика спустится в объекты. И, внезапно, это и есть ООП )
Это как раз то что Фаулер называет Rich domain model. Это как раз и есть ООП, когда обьекты сами знают что с собой делать, ты посылаешь ему сообщение и он что-то делает.
Охренеть. Я понял теперь что такое лженаука и закостенелость мышления. 90% аудитории привыкло забивать гвозди молотком и когда им говорят, что гвозди можно не забивать а вкручивать шурупы электрическим шуруповертом - у чуваков происходит срыв шаблона, когнитивный ступор и жесткое отрицание существования иных парадигм.
Я не смог дойти до общения с аудиторией, но сам доклад -- это квинтэссенция той самой лженауки. Человек не понимает ни что такое модель, что она должна делать, не слышал про такие вещи, как CQRS и многое другое. Он действует именно как сторонник религии, искренне веря в чушь, которую произносит. Он просто не осознаёт свои ошибки в силу низкой квалификации, но судя по тому, что он пришёл с докладом -- он искренне считает, что что-то в этом понимает.
Подход вида "а давайте все выдавать в виде XML, а если нам нужно что-то иное, создадим прокси-обретку и будем парсить каждый раз XML, и никаких геттеров" - это тоже закостенелость мышления, догматизм в чистом виде.
ну так show me the code
Мне кажется, у Егора слабый научный бекграунд, так как он пытается лезть в архитектуру языков, при этом досконально не изуччив другие парадигмы и паттерны. Он смешал в одну кучу иммутабельность, ооп и фп. На гитхабе его проекты не впечатлили, больше похожи на курсачи.
@@sergeydostovalov6180 Идеи похожи на DDD но DDD продуман настолько хорошо, что тут с Users как то грусно стало
Чувак просто пропагандирует, что каждый объект должен уметь все и вмещать безграничный функционал в себя ))
Он сказал, объект должен содержать не более 70-100 строк кода, а не 3000-4000. Слушайте внимательно.
и? благодаря наследованию наследуем,наследуем,наследуем и в итоге конечный объект умеет все.. вникайте внимательнее
не каждый, и не всё ) как минимум исходный - будет уметь мало зы. очень его код напоминает turbovision середины 90-х - лесенки new
все исходные сделать абстрактными) и не будет объектов умеющих очень мало)
@@user-be2cy2fb9u он не про наследование, он про абстракции: декораторы, декораторы, декораторы
OOP zombie
какой не приятный докладчик, жесть !!! не смогла его долго слушать, такой впечатление что он предлагает с Hibernate перейти на куриный бульон.
Не обижайте куриный бульон.