Егор Бугаенко - ORM - это обидно 

Вижу доклад Егора - иду писать декоратор.

Люди будут 10 раз изобретать Smalltalk, и не замечать, что у них уже есть Smalltalk.

Егор Бугаенко - мой любимый Stand Up комик

Декораторно ориентированное программирование

Вижу Егора - ставлю лайк. Конечно, сейчас немного подругому. Все на аннотациях, все пишут сервисы, репозитории, и контроллеры, но суть не особо поменялась. Бизнес-логика размазана, методы сервиса состоят либо из безумных манипуляций со стримами (и каждый лепит свои аналогичные стримы с новых сервисах), либо из new + set, set, set, set + return. И юнит-тестов хрен добьешься, ведь это г хрен протестируешь, тыщщу моков надо настроить. Гребцы гребут быстро, но что-то не туда.

Я "Щетаю" что hibernate и репозиторий паттерн - в целом, отвратительные вещи. И тут полностью поддерживаю Егора. Почему, в swift когда мы делаем layout.setFrame(), то он двигает сам себя на экране? И не делаем мы это, через какой то LayoutFrameHandler.moveLayout(layout, frame) ???? Потому что мы бы умерли от этого С style... это "мерзость" простите так разделять ответственности. Если мне как User нужно помнить свое имя, то я его храню в своем мозгу и в любой момент могу обратится напрямую к контроллеру памяти/мозгу, а не звать для этого дядю Васю/ака hibernate framework что бы он построил запрос для моего мозга.

Зачем делить приложение на уровни? Давайте лепить все в один объект

Прокси в спринге отлично выполняют роль этих ваших декораторов) В некоторых сценариях это будет лучше И кстати, с помощью спринг и рефлексии можно делать декораторы в императивном виде, и даже оборачивать конкретные методы с помощью простой аннотации

Почему все пиздят хибер за его скорость, что не оптимально работает и т.п. ??? и никто не делает докладов как надо правильно им пользоваться? Почему никто на докладах не рассказывает, что благодаря хиберу легке работать сразу несколькими таблицами >= 10 вместо того чтобы писать адские sql запросы с 10 join'ами???

Про MVC было продолжение на следующих выступлениях?

Егор - мой кумир!

дядька хорош

Мне кажется такие практики которые тут обсуждаются ведут к нервным срывам программистов, и все хорошие патерны тут критикуются а плохие патерны привозносятся.

Я вот все смотрю Егора и он мне в принципе нравится 👍, но никак не могу понять шутит он или серьезно. Почему-то всегда кажется, что он просто стебется и проверяет компетентность публики, нет?

дак он же говорит нам про луковую архитектуру - в центре бизнес объект, остальное снаружи, на самом деле бизнес объект не обязательно по его словам должен сам реализовывать всё, например запись в БД, конвертирование себя в json и т.д....он может просто объявить интерфейсы для этого, да, теперь это уже не класс, а сборка, но все же...луковая же...если я неправ, то поправьте? Или же, то что он имеет ввиду копия эктив рекорд, только не обязательно объект в точности копирует реляционную модель?

Я реально согласен с тем чтоб классы не были по 1000-2000 и более строк ))

Хороший был stand-up. Особенно угарнул с шутки про получение xml для последующего форматирования в json. Пока слушал совсем забыл что у нас существуют паттерны которые решают все эти проблемы.

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

20:14 в php так не пишут уже давным давно

Егор разобрался в хибернейте, докладывает, что понял )))

Сейчас он блоггер

Процедуры и функции точно так же были придуманы, чтобы уменьшить количество информации в голове программиста. На самом деле любая модульная система реализует ту же задачу. У автора ООП головного мзга

Анемичные классы это называет, когда строят DTO, а все потому что в JAVA забрали возможность создавать модули, все только классами... Ограничения...

39:40 Евгений Борисов?

вот все классно, но возникает интересный вопрос - тупые объекты с данными (POJO) плохо, но вот мне надо вернуть из метода имя и фамилию пользователя и в каком виде я это должен вернуть по мнению автора

single responsibility как раз таки нарушается, ваш объект отвечает за бизнес логику и за базу данных, такое себе

нет взять норм язык с монадами =)

Забавно слышать как ломает аудиторию и они аж с места кричат от боли

DTO != VO

"Надо доверять объектам, надо уважать объекты" - Надо встать перед ними на колени и молить о прощении за годы эксплуатации, предрассудков и гнета по отношению к ним. Давайте, всем залом бухайтесь на четвереньки и начинайте каяться и биться лбом об пол! Кто вообще позволил шизику нести со сцены весь этот бред?

Откровенно говоря, такое объяснение ООП (такой пример - ужас) только путает людей и не дает четкого понимания, что такое ООП и как эта задача должна решаться. 1. Слой базы данных и предоставление доступа на запись и получение должен находится в отдельном классе. В нем должна быть реализована основная базовая логика работы с БД. Все классы логики, которые работают с базой, в качестве проперти должны иметь доступ к этому объекту. Тогда при смене БД нам не придется растекаться по всему проекту и искать вот такие вот классы пишущие себя в базу и исправлять их. Ужас. 2. Анемичные объекты плохо. Безусловно. И это действительно так. Но это не значит, что представленное решение, перестало быть анемичной моделью. Нет. Оно все еще анемичная модель, просто ее сеттер и геттер сильно повязан на базе. Перестала бы анемичная модель быть анемичной, когда та самая логика расчета значения тайтла, о котором говорил докладчик, была перенесена на уровень объекта, а не находилась извне. И тогда она перестанет быть анемичной. Вся логика, которая связана с пропертями объекта будет инкапсулирована в объект. А не наоборот, логика отдельно, а запись в базу в проперти. Фе. 3. ДТО не плохо. Взаимодействие между объектами логики, простая передача структур между методами, чтобы не делать 500 параметров, рано или поздно потребует выделение анемичных интерфейсов (те в которых описаны только проперти, и нет методов). Наследники интерфейсов - это те самые ДТО. Если у вас есть взаимодействие, между проектами, системами, слоями приложений, клиентом и бэком - вам обязательно нужно иметь ДТО. Потому что в этих прослойках не может существовать логика. Ее там быть не должно. Именно в этом суть и цель ДТО. 4. Объект и класс это не одно и тоже. ООП говорит о работе с объектами логики - классами. Объекты же это данные. И смешивать эти понятия не совсем корректно. 5. ActiveRecord гораздо более серьезный антипаттерн, чем использование ОРМ. Простое объяснение почему: а. попробуйте сменить с таким подходом тип БД и посмотрите, как удобно вам это получится сделать. б. Попробуйте разделить проект на разные базы - и вы увидете насколько это тяжело. в. Попробуйте переделать структуру базы данных - и вы умрете. По сути правильная структура решения должна была бы выглядеть следующим образом. 1. Класс доступа к БД и не более того. 2. Классы отвечающие за запись в базу данных и работу с ней имеют доступ к объекту ОРМ и привязаны к определенной таблице в БД или связке таблиц. Они не знают о БД напрямую - они знают о ДТО таблицы которую обслуживают (и только они знают), и о том, какой интерфейс для объекта логики нужно вернуть наружу. 3. Классы ДТО для работы с БД, которые четко отображают структуру БД (не обязательно 1 к 1 если что, один ДТО может иметь в себе лишь часть полей из базы) и позволяют разрабу разобраться с тем, как это все хранится. 4. Объекты логики используют класс доступа к таблицам когда им необходимо. Они не знают вообще о БД. Вообще. Зато прекрасно знают об объектах логики. Трансферах, расчетах бюджета, обработке и тп. И тогда, при смене БД или ее структуры - вам не нужно будет менять миллиард классов. Только классы связанные с БД. Если у вас ДИ вы просто переподключите нужный вам класс доступа к БД или к структуры в БД. И меняться это будет легко и понятно. А представленный пример ужасен. Реально ужасен. И не удивлен, что люди вообще не поняли, в чем проблема с ОРМами

Куча ошибок в коде. Доклад хэйтера.

господи, какую чушь городит) харизматичный дядька)

42:00 когда тебя загнали в тупик, нужно говорить "это прекрасно"

На вопросы начинает гадать. Неправильный подход. Наоборот типы и набор функций. В калькуляторе значения вводятся отдельно. Калькулятор объект.

вот у докладчика бомбанет, когда коммьюните отвергнет его идеи и через 10 лет его язык так и не станет мегапопулярным ))) это ж надо, столько обиды заиметь на имеющиеся инструменты и пойти свое колесо изобретать ))) А языки нынче модно писать...

не знаю докладчика но чувак порет какую-то дичь. как будто сектант. нет ничего зазорного использовать классы как объекты хранения и передачи данных (DTO). тем более объектно-ориентированное программирование позволяет это делать и при этом соблюдены принципы SOLID. не надо засорять людям мозг.

Исходя из слов Егора мы просто добавляем 1 абстракцию на обращение к БД, вместо ORM прослойки а далее добавляем по n-количеству абстракций для SRP. Мне кажется или в таком случае кэширующий декоратор объекта будет делать 2 вещи, а именно: 1) Обрабатывать объект 2) Использовать кэш для случаев, когда много обращений? Можно было добавить АОП и накинуть @Hasheble(class = "наш класс") и класс бы явно уменьшился и мы бы могли так же имплементировать 1 аспект для конкретного класса вместо построения одной абстракции над классом. То что доклад про ООП не говорит о том, что ООП надо пихать постоянно и везде, поскольку как аспекты не называй они все равно аспекты

Пьяный программист теперь должен открывать свой ноут и говорить: "Мой объект, я тебя уважаю! А ты меня уважаешь?".

Как сделать доклад запоминающимся? Расскажи что-нибудь, с чем аудитория будет несогласно настолько, что не может утерпеть до сессии вопросов и начинает орать прямо с места, всем залом. А в ответ - "Это же хорошо!". Отличный доклад, заставляет всех подумать и побиться за свои привычки в ООП. При том что речь-то - про запиcь в БД (про ОРМ же), и про ActiveRecord

Это же ActiveRecord, битый час про ActiveRecord - серьезно?

На мой взгляд аргументация Егора не убедительна - "это же не ООП" - ну и что - если в данном случае процедурное программирование удобнее - почему его не использовать? Стиль для человека а не человек для стиля. "Я хочу умные объекты!" - а я хочу объекты которые делают то что мне надо. Простые бины как раз это и делают. Неубедителен и код с декарируемым Entity - в хибере вполне можно написать перехватчик события и это будет ничуть не менее элегантно чем декоратор (я тоже люблю декораторы но не зацикливаюсь на них!). Ну и, наконец - я готов принять и авторский подход с "умными" объектами - но не хочу для этого писать свой фреймворк. Будет фреймворк сравнимый по удобности с хибером - тогда и поговорим.

Главная проблема доклада, на мой взгляд - отсутствие хоть сколько-нибудь сложных примеров. Просто не верю, что с таким подходом можно написать и после этого не просто поддерживать, а активно развивать систему более чем в 100-200 тыс. строк кода. А на уровне HelloWorld`ов подойдёт вообще любая концепция кодирования...

Раньше когда я смотрел подобные доклады я восхищался, но поработав со всеми этими технологиями годы, возвращаюсь к таким докладам и у меня складывается впечатление, что докладчик кроме книг в реальной жизни с этим не работал. Любая технология имеет изъяны. Я не топлю за hibernate, меня он тоже подбешивает. Я топлю за улучшение инструментов путем коммитов в их код, а не платными лекциями о том, какие они плохие.

Фаулер о проблеме Anemic Domain Model ещё в 2003 писал. А воз и ныне там.

Егор, ты все верно мыслишь. Твоя идея понятна. Мы пишем на ООП средствами не ООП. Класс в нашем понимании - это некая "глобальная супер функция", просто вынесенная в отдельный класс. Мне кажется, с текущим техническим подходом к ООП, в том числе и в Java, тебе сложно будет добиваться своей идеи. Ты писал, что собираешься свой язык писать, который будет четко следовать фарватеру ООП. Удачи тебе желаю! Искренне! Жду первой альфа версии! Переучивать java как язык - бесполезно. нужен новый язык, где нет того, что java позволяет, и того чего нет в java. Нужен новый "интерфейс", не в том понятии, в котором он преподносится в java, а я имею в виду - возможно новые номенклатуры языка нужны, которые будут правильно описывать сущность. Классов видимо не будет, но будет не замена таковых, а будет именно новое определение, возможно даже со сдвигом в мышлении, согласен - класс во всех книгах преподается как супер что-то, что имеет свое хранилище и действо. Правильно сказал твой - ты апостол, а опостолу не легко :) удачи!

Проблема в том, что при большом количестве декораторов и наслаивании объектов друг на друга, мы забываем о возможностях человеческой памяти и магическом числе "семь". Дойдя до 10 слоя, я легко забуду о том, что было на каких-то других. В памяти придется удерживать большое кол-во объектов. Сама тема конечно интересная и спорная.

Не слышно вопросов из зала, в остальном качество хорошее, спасибо

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

Что-то мне по сути докладов показалось, что человек просто любит декораторы и пытается везде их пропихнуть, даже там, где они не нужны

Интересный доклад. Хорошее дополнение от Николая.

Раз в n лет появляется человек, который говорит: "Забудьте все что вы знали и делали до этого, вас всех обманули!")

Проблема правильная. Решение любопытное. Доклад куцый. Стыдно что никто не упоминает Фаулера и не оперирует его терминологией. Только Николай вспомнил про Active Record. Но ни про Anemic, ни про Transaction Script ни слова. Никто не объясняет в какие объекты бизнес-транзакции помещать. В общем, вопросов на много больше чем ответов.

не, опять не понимаю, черт я тупой ( я говорю: "эй юзер, переименую себя" юзер: "да без проблем, где мой конекшен, эй конекшен, на тебе запрос" конекшен:"эй, слюшай, ты меня не уважаешь, я тебе что, не объект, ты че в меня сиквелом тычешь? давай сюда иди, я сам знаю, что с тобой делать" юзер:"погоди, я тебе, что тупое хранилище данных, глупая структура? я так и знал, тебе ничего от меня, кроме полей не нужно!!!" все уходят в нул поинтер эксепшен. занавес.

43:00 Вся суть подхода

я не бекенд разработчик, но уже наперед вижу очень много потенциальных проблем с таким подходом. Поэтому человек и не показывает сложные примеры. Он вероятно никогда не работал на нормальном большом проекте. Причем тут ооп, процедуршина. Как тебе удобно писать, а потом всем поддерживать так и пиши. Где процедурно, где ооп, а где использую функциональшину. Я к примеру привык к функциональному подходу и много чего делаю с его помощью. Это позволяет быстрее писать. Его также можно и нормально поддерживать и дебажить, если привыкнуть. Правда соглашусь что писать тесты не всегда удобно под него. Но концепция какого-то большого объекта это полный изврат. Во первых почти полностью теряется переиспользование кода. С его подходами по выгрузке данных из базы или записи можно нарваться на большие проблемы с ресурсами, особенно если это какая-то большая живая система.

Шикарный доклад

Нужно больше классов (c)

Хорошо бы чтобы на амазоне продаваемая книжка показала хотя бы один вразумительный пример использования. К сожалению пример содержит нечто похожее в самом выступлении - какой то мутный hello world.

Ааа, блин, это тот самый yegor256, который топит за объекты. Вспомнил его. Обсуждали уже его подходы.

Есть такая вещь как DDD идея которой ядро энкапсулирующее бизнес логику, которая тестится юнит тестами. Все IO по краям - DB/REST/SOAP etc.

Доклад прикольный, Егор харизматичный, идеи спорненькие....Золотая середина рулит..

Обидно, что так негативно восприняли

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

вы ещё вижуал фокспро не видели!

Mvc во фронте уже раскусили: react предлагает совмещать разметку и логику в своих компонентах. Что касается паттерна Repository, домены нам заменяют нехватку гибкости java в структурах данных, сам по себе репозиторий похож на тот самый любимый объект который знает как его сохранить и тд.

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

тема правильная, но не раскрыта. Терминология не проработана. В комментах подсказывают особо больше полезности чем в докладе. Удивляет то что человек книгу написал, а самые простые вопросы вызывают негодование и удивление. Некоторые, как по мне, вообще в корне не правильно отвечены. Например где-то здесь ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ckjAWXJWZEY.html Егор говорит что все его обьекты имплементят один интерфейс. Странное решение которое и приводит к тому непониманию предмета публикой и дублированию изменений в коде. Обьект несёт КОНТРАКТЫ. Декорировать мы можем КОНТРАКТ и всё что мы делаем мы делаем по контракту. Когда приходит запрос на новый функционал - это новый контракт. В вызывающем коде мы получаем не пачку юзеров/постов/етц. - мы получаем пачку чего-то что реализует КОНТРАКТ! И тогда ни дублирования ни переписывания ни комбинаторного взрыва. Просто обьекты, которые реализуют множественные контракты.

А ведь "делать mock этой сессии" - это и есть ООП во всей своей красе. Я всё-таки не до конца понимаю, что имеет в виду докладчик.

23:10 - Active Record. Какая прелесть.

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

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

Хотел бы я увидеть реальный рабочий пример от Егора скажем какой нибудь простенький MVC в виде библиотеки книг который на том же спринге пишется ~за час. Я не хотел бы тратить время на монотонное создание сотен и тысяч файлов, вместо того что бы потратить час на разработку простенькой архитектуры

При данном подходе вся логика приложения со временем спустится в объект! И мы как раз получим не ООП, а старую процедурку! У каждого объекта (сущнорсти) должно быть множественно число! Это вообще пиздец! Вы что там курите? MVC - антипаттерн )) В завершении доклада нужно было произнести фразу "Земля плоская!"

Немного в шоке был, увидев этот "декоратор", сочувствую.

ru.wikipedia.org/wiki/Функционал

Охренеть. Я понял теперь что такое лженаука и закостенелость мышления. 90% аудитории привыкло забивать гвозди молотком и когда им говорят, что гвозди можно не забивать а вкручивать шурупы электрическим шуруповертом - у чуваков происходит срыв шаблона, когнитивный ступор и жесткое отрицание существования иных парадигм.

Чувак просто пропагандирует, что каждый объект должен уметь все и вмещать безграничный функционал в себя ))

OOP zombie

какой не приятный докладчик, жесть !!! не смогла его долго слушать, такой впечатление что он предлагает с Hibernate перейти на куриный бульон.