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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

дядька хорош

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

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

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

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

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

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

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

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

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

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

DTO != VO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

тема правильная, но не раскрыта. Терминология не проработана. В комментах подсказывают особо больше полезности чем в докладе. Удивляет то что человек книгу написал, а самые простые вопросы вызывают негодование и удивление. Некоторые, как по мне, вообще в корне не правильно отвечены. Например где-то здесь ukposts.info/have/v-deo/m5ubdY2PgY2Lpo0.html Егор говорит что все его обьекты имплементят один интерфейс. Странное решение которое и приводит к тому непониманию предмета публикой и дублированию изменений в коде. Обьект несёт КОНТРАКТЫ. Декорировать мы можем КОНТРАКТ и всё что мы делаем мы делаем по контракту. Когда приходит запрос на новый функционал - это новый контракт. В вызывающем коде мы получаем не пачку юзеров/постов/етц. - мы получаем пачку чего-то что реализует КОНТРАКТ! И тогда ни дублирования ни переписывания ни комбинаторного взрыва. Просто обьекты, которые реализуют множественные контракты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OOP zombie

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