Уже давно не вводят в использование новые языки, если вы не заметили. Так что это сомнительный заход. Есть куча языков получше smalltalk, только никому не нужен язык без всего остального: без поддержки, без актуальных библиотек, без людей которые его знают.
Как сделать доклад запоминающимся? Расскажи что-нибудь, с чем аудитория будет несогласно настолько, что не может утерпеть до сессии вопросов и начинает орать прямо с места, всем залом. А в ответ - "Это же хорошо!". Отличный доклад, заставляет всех подумать и побиться за свои привычки в ООП. При том что речь-то - про запиcь в БД (про ОРМ же), и про ActiveRecord
Главная проблема доклада, на мой взгляд - отсутствие хоть сколько-нибудь сложных примеров. Просто не верю, что с таким подходом можно написать и после этого не просто поддерживать, а активно развивать систему более чем в 100-200 тыс. строк кода. А на уровне HelloWorld`ов подойдёт вообще любая концепция кодирования...
не обязательно все пихать в один GodObject. Домен должен решать проблему предметной области. сохраняемость данных лежит в другой плоскости - инфраструктура. то что вокруг домена но не обязательная часть - онион-архитектура.
Вижу Егора - ставлю лайк. Конечно, сейчас немного подругому. Все на аннотациях, все пишут сервисы, репозитории, и контроллеры, но суть не особо поменялась. Бизнес-логика размазана, методы сервиса состоят либо из безумных манипуляций со стримами (и каждый лепит свои аналогичные стримы с новых сервисах), либо из new + set, set, set, set + return. И юнит-тестов хрен добьешься, ведь это г хрен протестируешь, тыщщу моков надо настроить. Гребцы гребут быстро, но что-то не туда.
Раньше когда я смотрел подобные доклады я восхищался, но поработав со всеми этими технологиями годы, возвращаюсь к таким докладам и у меня складывается впечатление, что докладчик кроме книг в реальной жизни с этим не работал. Любая технология имеет изъяны. Я не топлю за hibernate, меня он тоже подбешивает. Я топлю за улучшение инструментов путем коммитов в их код, а не платными лекциями о том, какие они плохие.
Проблема в том, что при большом количестве декораторов и наслаивании объектов друг на друга, мы забываем о возможностях человеческой памяти и магическом числе "семь". Дойдя до 10 слоя, я легко забуду о том, что было на каких-то других. В памяти придется удерживать большое кол-во объектов. Сама тема конечно интересная и спорная.
На мой взгляд аргументация Егора не убедительна - "это же не ООП" - ну и что - если в данном случае процедурное программирование удобнее - почему его не использовать? Стиль для человека а не человек для стиля. "Я хочу умные объекты!" - а я хочу объекты которые делают то что мне надо. Простые бины как раз это и делают. Неубедителен и код с декарируемым Entity - в хибере вполне можно написать перехватчик события и это будет ничуть не менее элегантно чем декоратор (я тоже люблю декораторы но не зацикливаюсь на них!). Ну и, наконец - я готов принять и авторский подход с "умными" объектами - но не хочу для этого писать свой фреймворк. Будет фреймворк сравнимый по удобности с хибером - тогда и поговорим.
не, опять не понимаю, черт я тупой ( я говорю: "эй юзер, переименую себя" юзер: "да без проблем, где мой конекшен, эй конекшен, на тебе запрос" конекшен:"эй, слюшай, ты меня не уважаешь, я тебе что, не объект, ты че в меня сиквелом тычешь? давай сюда иди, я сам знаю, что с тобой делать" юзер:"погоди, я тебе, что тупое хранилище данных, глупая структура? я так и знал, тебе ничего от меня, кроме полей не нужно!!!" все уходят в нул поинтер эксепшен. занавес.
Моё понимание: Акт 1. "Ваша вселенная" : Вы говорите: "эй, юзер, вот тебе новое имя -- переименуйся". Юзер: "ок, шеф, без проблем". (Вы идёте курить трубку) Акт 2. "Вселенная юзера". Смена декораций. Никакого юзера как сущности здесь не существует, юзер здесь -- это Вселенная, внутри которой и разворачиваются все события. Коннектор: я слышал голос Бога, который сказал мне: "юниту сего мира, нейму Ивану, надлежит имя поменять своё. Отныне, нейм Иван пусть зовется Борисом, ибо такова воля моя, юзера, Бога твоего единого". Коннектор (бормочет): хм... неизведынны пути Господни. Но я знаю как исполнить волю божью. (берет лопату и делает реквест): "update user set name = "Борис" where name = "Иван", -- получет error 0. Коннектор: Аллилуя! Акт 3. "Возврат обртно". Юзер: "эй, шеф..." Вы (вытаскиваете трубку изо рта): "...А? Чего тебе". Юзер: "все готово, теперь я Борис". Вы (выбиваете трубку, вздыхаете): "Отлично, спасибо". (Грустно уходите в закат пилить стопяцотую форму на вебе) Занавес.
@@Vilabz О великий Java кодер. Представь вселенную, где существуют аналоги гибернейта и в других языках, например доктрина=) Которая точно так же конфигурируется аннотациями (в контексте PHP это атрибуты), и имеет те же преимущества и недостатки что и гибернейт=) Там еще и пакетные менеджеры есть, и сборщики, и тесты пишут, и тайп хинты, и редис, и мемкешед и еще куча того с чем работают и Java кодеры. Прикинь=)
Егор, ты все верно мыслишь. Твоя идея понятна. Мы пишем на ООП средствами не ООП. Класс в нашем понимании - это некая "глобальная супер функция", просто вынесенная в отдельный класс. Мне кажется, с текущим техническим подходом к ООП, в том числе и в Java, тебе сложно будет добиваться своей идеи. Ты писал, что собираешься свой язык писать, который будет четко следовать фарватеру ООП. Удачи тебе желаю! Искренне! Жду первой альфа версии! Переучивать java как язык - бесполезно. нужен новый язык, где нет того, что java позволяет, и того чего нет в java. Нужен новый "интерфейс", не в том понятии, в котором он преподносится в java, а я имею в виду - возможно новые номенклатуры языка нужны, которые будут правильно описывать сущность. Классов видимо не будет, но будет не замена таковых, а будет именно новое определение, возможно даже со сдвигом в мышлении, согласен - класс во всех книгах преподается как супер что-то, что имеет свое хранилище и действо. Правильно сказал твой - ты апостол, а опостолу не легко :) удачи!
Я "Щетаю" что hibernate и репозиторий паттерн - в целом, отвратительные вещи. И тут полностью поддерживаю Егора. Почему, в swift когда мы делаем layout.setFrame(), то он двигает сам себя на экране? И не делаем мы это, через какой то LayoutFrameHandler.moveLayout(layout, frame) ???? Потому что мы бы умерли от этого С style... это "мерзость" простите так разделять ответственности. Если мне как User нужно помнить свое имя, то я его храню в своем мозгу и в любой момент могу обратится напрямую к контроллеру памяти/мозгу, а не звать для этого дядю Васю/ака hibernate framework что бы он построил запрос для моего мозга.
@@mexvision-3556 Я же не против, просто реально, мы пишем какую то ерунду процедурную, средствами ООП. Controller -> ControllerHelper -> Service -> Repository -> Model -> DTO. В будущем, думаю найдется человек спаситель, который вернет ООП в нужное русло. Каким образом это будет хз 😂✌
Ну а теперь скажи такую вещь. Ты вообще разбирал то о чем говоришь? Репозиторий не отвечает за функционал пользователя. Дальше сам погугли, мне лень учить людей которые в этом не заинтересованы.
Проблема правильная. Решение любопытное. Доклад куцый. Стыдно что никто не упоминает Фаулера и не оперирует его терминологией. Только Николай вспомнил про Active Record. Но ни про Anemic, ни про Transaction Script ни слова. Никто не объясняет в какие объекты бизнес-транзакции помещать. В общем, вопросов на много больше чем ответов.
Я-то понимаю. Проблема в том что даже Фаулера не все понимают с его Anemic Model. И докладчик вместо того чтобы объяснить, ссылаясь на уже проделанную работу других в этой теме, сводит всё к аргументации "тут у нас True OOP, а вот тут нет". А давно устоявшуюся терминологию по вопросу почему-то подсказывают из зала. Тема отличная. Направление мыслей правильное. Но решения нет. Переделать всё на колбэки и Active Record это не решение. Отказаться от всех современных фреймверков это тоже не решение. И, что самое забавное, это притянутый за уши ORM, который к проблеме имеет посредственное отношение. А всего-то надо было взять какой-нибудь Spring Boot Hello World и показать на каждом слое как можно было сделать иначе.
@@johnconstantine6331 притянутый за уши потому что никто на самом деле не мешает методы написать в классах сущностях. ORM это не запрещает. Обвинять его в этом сложно.
Вообще главная проблема - пытаться реалиционные даны натянуть на объекты ооп. А это абсолютно разные вещи, даже с точки зрения математики. Лучше решение - использовать статический класс для одного sql запроса(или несколько sql запросов С ОДНИМ РЕЗУЛЬТАТОМ), который на вход будет принимать данные БЕЗ использования структур(да, для запроса с 30 параметрами на вход использовать 30 параметров для функции) и на выходе выводить картеж. Структуры и объекты для параметров и результата sql не нужно использовать, чтобы не было соблазна переиспользовать их в других участках кода, то есть этого вообще не нужно делать, соответствено использовать структуры для параметров и результата sql бессмысленно. Если переиспользовать такие структуры - то твой код будет слишком связанный и слишком зависить от логики запроса
Хорошо бы чтобы на амазоне продаваемая книжка показала хотя бы один вразумительный пример использования. К сожалению пример содержит нечто похожее в самом выступлении - какой то мутный hello world.
дак он же говорит нам про луковую архитектуру - в центре бизнес объект, остальное снаружи, на самом деле бизнес объект не обязательно по его словам должен сам реализовывать всё, например запись в БД, конвертирование себя в json и т.д....он может просто объявить интерфейсы для этого, да, теперь это уже не класс, а сборка, но все же...луковая же...если я неправ, то поправьте? Или же, то что он имеет ввиду копия эктив рекорд, только не обязательно объект в точности копирует реляционную модель?
Как я понял, он про то что объект должен сам в себе реализовать работу и с бд и уметь отдавать себя в xml, json итд. Не похоже на луковую архитектуру, больше напоминает антипаттерн GodObject
я не бекенд разработчик, но уже наперед вижу очень много потенциальных проблем с таким подходом. Поэтому человек и не показывает сложные примеры. Он вероятно никогда не работал на нормальном большом проекте. Причем тут ооп, процедуршина. Как тебе удобно писать, а потом всем поддерживать так и пиши. Где процедурно, где ооп, а где использую функциональшину. Я к примеру привык к функциональному подходу и много чего делаю с его помощью. Это позволяет быстрее писать. Его также можно и нормально поддерживать и дебажить, если привыкнуть. Правда соглашусь что писать тесты не всегда удобно под него. Но концепция какого-то большого объекта это полный изврат. Во первых почти полностью теряется переиспользование кода. С его подходами по выгрузке данных из базы или записи можно нарваться на большие проблемы с ресурсами, особенно если это какая-то большая живая система.
Прокси в спринге отлично выполняют роль этих ваших декораторов) В некоторых сценариях это будет лучше И кстати, с помощью спринг и рефлексии можно делать декораторы в императивном виде, и даже оборачивать конкретные методы с помощью простой аннотации
Почему все пиздят хибер за его скорость, что не оптимально работает и т.п. ??? и никто не делает докладов как надо правильно им пользоваться? Почему никто на докладах не рассказывает, что благодаря хиберу легке работать сразу несколькими таблицами >= 10 вместо того чтобы писать адские sql запросы с 10 join'ами???
чем проще работать с инструментом, тем больше надо знать, как устроены его внутренности) Иначе вместо удобства будет куча проблем. Ну а в данном ролике больше речь не про "медленность" работы хибернейта, а про то, что можно как-то по-другому работать с данными с точки зрения ООП.
@@gaben-agent Вилами по воде. Никто так и не сказал как именно. Как-то можно, но мы не знаем как=) То что предложил автор доклада - изменения ради изменений, не применяемые даже самим автором нигде. Он говорит о том, что на практике не применялось, даже на средних по величине проектах. Я уже не говорю про большие системы. Ровно 0 плюсов от предложенного подхода я увидел для себя.
@@mexvision-3556 Ровно 0? Ну вообще-то код становится более прозрачным и объект принадлежит тебе. Логика не размазана по аннотациям и критериям. Да, может практических применений не было, но доклад больше интересен с теоретической точки зрения. С научной, если хотите. Егор нас подталкивает задуматься о том, как можно писать код по другому, чтобы это больше походило на ООП и приводит небольшой пример. А конкретно какие буковки писать и куда вставлять чтобы всё сразу заработало... Ну это как-то слишком узко и скучно) Доклад и не ставит перед собой цели сразу дать практический аналог Хиберу, который работает из коробки и лучше Хибера.
@@gaben-agent Блять, чел, ты сам то вникал в то что он предлагает? =) Ахахаха, я просто ору с таких людей как ты, которые на серьезных щах, занимаются поиском истины в речах типа, который показывает CRUD класс и называет это объектом. Объект который вместо одного запроса в БД шлет по запросу на каждый геттер или сеттер. Затем чел предлагает ебануть декоратор. ДЕКОРТАТОР С КЕШИРОВАНИЕМ) Ведь это тоже в его понимании нормальный такой объект=))) Ебать. То есть сущности в контексте гибернейта, доктрины и прочих ОРМ - это хуйня. А CRUD обернут декоратором - это заебась. Вы блять фильтруйте инфу, парни. Это уже не смешно. Хоть немного свою голову подрубайте. Не стоит жрать всё то что тебе говорят типы с раскрученными ебальниками. Он туда книжки продавать пришел, а не мир изменять.
Я вот все смотрю Егора и он мне в принципе нравится 👍, но никак не могу понять шутит он или серьезно. Почему-то всегда кажется, что он просто стебется и проверяет компетентность публики, нет?
Понимаю о чем говорит егор и к этому и пришол. Все по полочкам в своих ячейках как интсрументы в мастерской и код не размазан по всему проекту(меньше спагетти)
Мне кажется такие практики которые тут обсуждаются ведут к нервным срывам программистов, и все хорошие патерны тут критикуются а плохие патерны привозносятся.
тема правильная, но не раскрыта. Терминология не проработана. В комментах подсказывают особо больше полезности чем в докладе. Удивляет то что человек книгу написал, а самые простые вопросы вызывают негодование и удивление. Некоторые, как по мне, вообще в корне не правильно отвечены. Например где-то здесь th-cam.com/video/ckjAWXJWZEY/w-d-xo.html Егор говорит что все его обьекты имплементят один интерфейс. Странное решение которое и приводит к тому непониманию предмета публикой и дублированию изменений в коде. Обьект несёт КОНТРАКТЫ. Декорировать мы можем КОНТРАКТ и всё что мы делаем мы делаем по контракту. Когда приходит запрос на новый функционал - это новый контракт. В вызывающем коде мы получаем не пачку юзеров/постов/етц. - мы получаем пачку чего-то что реализует КОНТРАКТ! И тогда ни дублирования ни переписывания ни комбинаторного взрыва. Просто обьекты, которые реализуют множественные контракты.
Хотел бы я увидеть реальный рабочий пример от Егора скажем какой нибудь простенький MVC в виде библиотеки книг который на том же спринге пишется ~за час. Я не хотел бы тратить время на монотонное создание сотен и тысяч файлов, вместо того что бы потратить час на разработку простенькой архитектуры
Простенькая библиотека книг, которая пишется за час на MVC, собирается за полчаса на MS Access без единой строчки кода. Вопрос задач, собираетесь ли вы свой прототип развивать и поддерживать.
Mvc во фронте уже раскусили: react предлагает совмещать разметку и логику в своих компонентах. Что касается паттерна Repository, домены нам заменяют нехватку гибкости java в структурах данных, сам по себе репозиторий похож на тот самый любимый объект который знает как его сохранить и тд.
React предлагает полностью отделять разметку и логику. Посмотрите на redux и прочее. Вся логика находится в отдельном методе, с которым оперируют через actions. Его легко тестировать. Сам реакт используется только в качестве разметки
Какой-то религиозный фанатик, а не разработчик. С какой стати ООП == прекрасный код, функциональный == плохой код? Про apache spark смешно слушать, это по сути функциональный фреймворк.
Соглашусь, идти нужно от бизнес задачи, а не реляционной модели . То что, хибернейт медленный г..код не согласится только поклонник хибернейта. Но это ладно, есть более красивые реализации. Но и конкретного решения по теме я не увидел. Хоть бы ссылку на гитхаб дали.
Хороший был stand-up. Особенно угарнул с шутки про получение xml для последующего форматирования в json. Пока слушал совсем забыл что у нас существуют паттерны которые решают все эти проблемы.
Да кому нужны твои паттерны, ты пишешь код не правильно. И вообще, весь накопленный за десятилетия опыт миллионов программистов, который выносился в принципы ничего абсолютно не стоит. Так сказал таксист со своим бизнесом, который таксует для души=)
Какая нетерпеливая аудитория, жесть. Вот им прям надо сейчас что-то прокомментировать, так как у них видимо подгорает сильно) В итоге это превращается в базар, так как у каждого свои мысли, свои вопросы и попытки контраргументировать. Дайте закончить доклад, потом лезьте уже со своими вопросами. Ппц.
вот все классно, но возникает интересный вопрос - тупые объекты с данными (POJO) плохо, но вот мне надо вернуть из метода имя и фамилию пользователя и в каком виде я это должен вернуть по мнению автора
у Вас будет метод: user.serializeNameWithSurnameIntoJson(), без аргументов, который внутри не только выполнит сериализацию в String, но и запишет её в HttpServletResponse короче, не знаю, как Вы, а я категорически против и, если честно, пока не готов согласиться с Егором, что такой код более "чистый" и управляемый
@@ИгорьСелезнев-в2у и представьте что будет внутри этого метода, мы выберем из базы записи и сразу начнем пихать данные из ResultSet в какие небуть JsonObject, агрегируя их в JsonArray, мы шли в ООП за абстракцией, а в итоге будем работать с примитивами, не находите, причем наш User превращается в God Object, не находите
@@_ArturMamedov_ тут наверное подразумевается, что класс User - это statefull объекты, то есть Вы сперва методом user.loadById(), например, загрузили из базы, затем другим методом сериализовали в JSON, а так - да, god object, при этом, даже если сериализация и чтение из бд в разных объектах, все равно придется побегать к интерактивному подходу в коде, последовательно вызвав сперва чтение, затем сериализацию и запись в response, ну а в случае с Вашим примером так вообще получается, что мы процедурный код просто прячем "под ковёр" объекта. Вобщем согласен с Вами, и получается, что мы только усложняем код и делаем его менее управляемым.
Идеологические противники втащили SQL в свой язык на уровне синтаксиса, чтобы только люди меньше смотрели в сторону функциональщины, а этот возмущается, что в Hibernate SQL размазан по коду...
"Надо доверять объектам, надо уважать объекты" - Надо встать перед ними на колени и молить о прощении за годы эксплуатации, предрассудков и гнета по отношению к ним. Давайте, всем залом бухайтесь на четвереньки и начинайте каяться и биться лбом об пол! Кто вообще позволил шизику нести со сцены весь этот бред?
Процедуры и функции точно так же были придуманы, чтобы уменьшить количество информации в голове программиста. На самом деле любая модульная система реализует ту же задачу. У автора ООП головного мзга
ORM реально какой-то бред, ненужная надстройка над нативным SQL, но к сожалению он удобен и безопасен, поэтому не смотря на убогость без него не обойтись
При данном подходе вся логика приложения со временем спустится в объект! И мы как раз получим не ООП, а старую процедурку! У каждого объекта (сущнорсти) должно быть множественно число! Это вообще пиздец! Вы что там курите? MVC - антипаттерн )) В завершении доклада нужно было произнести фразу "Земля плоская!"
Это как раз то что Фаулер называет Rich domain model. Это как раз и есть ООП, когда обьекты сами знают что с собой делать, ты посылаешь ему сообщение и он что-то делает.
Охренеть. Я понял теперь что такое лженаука и закостенелость мышления. 90% аудитории привыкло забивать гвозди молотком и когда им говорят, что гвозди можно не забивать а вкручивать шурупы электрическим шуруповертом - у чуваков происходит срыв шаблона, когнитивный ступор и жесткое отрицание существования иных парадигм.
Я не смог дойти до общения с аудиторией, но сам доклад -- это квинтэссенция той самой лженауки. Человек не понимает ни что такое модель, что она должна делать, не слышал про такие вещи, как CQRS и многое другое. Он действует именно как сторонник религии, искренне веря в чушь, которую произносит. Он просто не осознаёт свои ошибки в силу низкой квалификации, но судя по тому, что он пришёл с докладом -- он искренне считает, что что-то в этом понимает.
Подход вида "а давайте все выдавать в виде XML, а если нам нужно что-то иное, создадим прокси-обретку и будем парсить каждый раз XML, и никаких геттеров" - это тоже закостенелость мышления, догматизм в чистом виде.
Мне кажется, у Егора слабый научный бекграунд, так как он пытается лезть в архитектуру языков, при этом досконально не изуччив другие парадигмы и паттерны. Он смешал в одну кучу иммутабельность, ооп и фп. На гитхабе его проекты не впечатлили, больше похожи на курсачи.
Исходя из слов Егора мы просто добавляем 1 абстракцию на обращение к БД, вместо ORM прослойки а далее добавляем по n-количеству абстракций для SRP. Мне кажется или в таком случае кэширующий декоратор объекта будет делать 2 вещи, а именно: 1) Обрабатывать объект 2) Использовать кэш для случаев, когда много обращений? Можно было добавить АОП и накинуть @Hasheble(class = "наш класс") и класс бы явно уменьшился и мы бы могли так же имплементировать 1 аспект для конкретного класса вместо построения одной абстракции над классом. То что доклад про ООП не говорит о том, что ООП надо пихать постоянно и везде, поскольку как аспекты не называй они все равно аспекты
Откровенно говоря, такое объяснение ООП (такой пример - ужас) только путает людей и не дает четкого понимания, что такое ООП и как эта задача должна решаться. 1. Слой базы данных и предоставление доступа на запись и получение должен находится в отдельном классе. В нем должна быть реализована основная базовая логика работы с БД. Все классы логики, которые работают с базой, в качестве проперти должны иметь доступ к этому объекту. Тогда при смене БД нам не придется растекаться по всему проекту и искать вот такие вот классы пишущие себя в базу и исправлять их. Ужас. 2. Анемичные объекты плохо. Безусловно. И это действительно так. Но это не значит, что представленное решение, перестало быть анемичной моделью. Нет. Оно все еще анемичная модель, просто ее сеттер и геттер сильно повязан на базе. Перестала бы анемичная модель быть анемичной, когда та самая логика расчета значения тайтла, о котором говорил докладчик, была перенесена на уровень объекта, а не находилась извне. И тогда она перестанет быть анемичной. Вся логика, которая связана с пропертями объекта будет инкапсулирована в объект. А не наоборот, логика отдельно, а запись в базу в проперти. Фе. 3. ДТО не плохо. Взаимодействие между объектами логики, простая передача структур между методами, чтобы не делать 500 параметров, рано или поздно потребует выделение анемичных интерфейсов (те в которых описаны только проперти, и нет методов). Наследники интерфейсов - это те самые ДТО. Если у вас есть взаимодействие, между проектами, системами, слоями приложений, клиентом и бэком - вам обязательно нужно иметь ДТО. Потому что в этих прослойках не может существовать логика. Ее там быть не должно. Именно в этом суть и цель ДТО. 4. Объект и класс это не одно и тоже. ООП говорит о работе с объектами логики - классами. Объекты же это данные. И смешивать эти понятия не совсем корректно. 5. ActiveRecord гораздо более серьезный антипаттерн, чем использование ОРМ. Простое объяснение почему: а. попробуйте сменить с таким подходом тип БД и посмотрите, как удобно вам это получится сделать. б. Попробуйте разделить проект на разные базы - и вы увидете насколько это тяжело. в. Попробуйте переделать структуру базы данных - и вы умрете. По сути правильная структура решения должна была бы выглядеть следующим образом. 1. Класс доступа к БД и не более того. 2. Классы отвечающие за запись в базу данных и работу с ней имеют доступ к объекту ОРМ и привязаны к определенной таблице в БД или связке таблиц. Они не знают о БД напрямую - они знают о ДТО таблицы которую обслуживают (и только они знают), и о том, какой интерфейс для объекта логики нужно вернуть наружу. 3. Классы ДТО для работы с БД, которые четко отображают структуру БД (не обязательно 1 к 1 если что, один ДТО может иметь в себе лишь часть полей из базы) и позволяют разрабу разобраться с тем, как это все хранится. 4. Объекты логики используют класс доступа к таблицам когда им необходимо. Они не знают вообще о БД. Вообще. Зато прекрасно знают об объектах логики. Трансферах, расчетах бюджета, обработке и тп. И тогда, при смене БД или ее структуры - вам не нужно будет менять миллиард классов. Только классы связанные с БД. Если у вас ДИ вы просто переподключите нужный вам класс доступа к БД или к структуры в БД. И меняться это будет легко и понятно. А представленный пример ужасен. Реально ужасен. И не удивлен, что люди вообще не поняли, в чем проблема с ОРМами
не знаю докладчика но чувак порет какую-то дичь. как будто сектант. нет ничего зазорного использовать классы как объекты хранения и передачи данных (DTO). тем более объектно-ориентированное программирование позволяет это делать и при этом соблюдены принципы SOLID. не надо засорять людям мозг.
вот у докладчика бомбанет, когда коммьюните отвергнет его идеи и через 10 лет его язык так и не станет мегапопулярным ))) это ж надо, столько обиды заиметь на имеющиеся инструменты и пойти свое колесо изобретать ))) А языки нынче модно писать...
Вижу доклад Егора - иду писать декоратор.
В голос! :D Но вы забыли дописать вначале: "я человек простой -- " :D
-- Сколько паттернов вы знаете?
-- Декоратор!
Егор Бугаенко - мой любимый Stand Up комик
Люди будут 10 раз изобретать Smalltalk, и не замечать, что у них уже есть Smalltalk.
Уже давно не вводят в использование новые языки, если вы не заметили. Так что это сомнительный заход. Есть куча языков получше smalltalk, только никому не нужен язык без всего остального: без поддержки, без актуальных библиотек, без людей которые его знают.
Это же ActiveRecord, битый час про ActiveRecord - серьезно?
Да походу ActiveRecord
Вообще не ActiveRecord
Декораторно ориентированное программирование
Как сделать доклад запоминающимся? Расскажи что-нибудь, с чем аудитория будет несогласно настолько, что не может утерпеть до сессии вопросов и начинает орать прямо с места, всем залом. А в ответ - "Это же хорошо!". Отличный доклад, заставляет всех подумать и побиться за свои привычки в ООП. При том что речь-то - про запиcь в БД (про ОРМ же), и про ActiveRecord
Зачем делить приложение на уровни? Давайте лепить все в один объект
Пьяный программист теперь должен открывать свой ноут и говорить: "Мой объект, я тебя уважаю! А ты меня уважаешь?".
ШЕДЕВР )
Главная проблема доклада, на мой взгляд - отсутствие хоть сколько-нибудь сложных примеров. Просто не верю, что с таким подходом можно написать и после этого не просто поддерживать, а активно развивать систему более чем в 100-200 тыс. строк кода. А на уровне HelloWorld`ов подойдёт вообще любая концепция кодирования...
ActiveRecord и ООП для хело волдов? Мдя.
Фаулер о проблеме Anemic Domain Model ещё в 2003 писал. А воз и ныне там.
не обязательно все пихать в один GodObject. Домен должен решать проблему предметной области. сохраняемость данных лежит в другой плоскости - инфраструктура. то что вокруг домена но не обязательная часть - онион-архитектура.
Вижу Егора - ставлю лайк. Конечно, сейчас немного подругому. Все на аннотациях, все пишут сервисы, репозитории, и контроллеры, но суть не особо поменялась. Бизнес-логика размазана, методы сервиса состоят либо из безумных манипуляций со стримами (и каждый лепит свои аналогичные стримы с новых сервисах), либо из new + set, set, set, set + return. И юнит-тестов хрен добьешься, ведь это г хрен протестируешь, тыщщу моков надо настроить. Гребцы гребут быстро, но что-то не туда.
Раньше когда я смотрел подобные доклады я восхищался, но поработав со всеми этими технологиями годы, возвращаюсь к таким докладам и у меня складывается впечатление, что докладчик кроме книг в реальной жизни с этим не работал. Любая технология имеет изъяны.
Я не топлю за hibernate, меня он тоже подбешивает. Я топлю за улучшение инструментов путем коммитов в их код, а не платными лекциями о том, какие они плохие.
Проблема в том, что при большом количестве декораторов и наслаивании объектов друг на друга, мы забываем о возможностях человеческой памяти и магическом числе "семь". Дойдя до 10 слоя, я легко забуду о том, что было на каких-то других. В памяти придется удерживать большое кол-во объектов. Сама тема конечно интересная и спорная.
Вы когда-нибудь дебажили Hierbnate или Eclipselink? Там где-то столько слоёв и есть.
Нет.
Смотри у тебя есть юзер. У него есть логирующий декоратор, и sql декоратор. Потом ты new вкладываешь в new и в new и видишь все слои.
@@kep261 а потом, когда логика станет посложнее, нужно будет скролить вправо очень долго, чтобы все слои увидеть
@@МаксимАлексеев-ч4й ну или сидеть и ковырять спагетти код, заходя в каждый класс)
На мой взгляд аргументация Егора не убедительна - "это же не ООП" - ну и что - если в данном случае процедурное программирование удобнее - почему его не использовать? Стиль для человека а не человек для стиля. "Я хочу умные объекты!" - а я хочу объекты которые делают то что мне надо. Простые бины как раз это и делают. Неубедителен и код с декарируемым Entity - в хибере вполне можно написать перехватчик события и это будет ничуть не менее элегантно чем декоратор (я тоже люблю декораторы но не зацикливаюсь на них!). Ну и, наконец - я готов принять и авторский подход с "умными" объектами - но не хочу для этого писать свой фреймворк. Будет фреймворк сравнимый по удобности с хибером - тогда и поговорим.
Не слышно вопросов из зала, в остальном качество хорошее, спасибо
не, опять не понимаю, черт я тупой (
я говорю: "эй юзер, переименую себя"
юзер: "да без проблем, где мой конекшен, эй конекшен, на тебе запрос"
конекшен:"эй, слюшай, ты меня не уважаешь, я тебе что, не объект, ты че в меня сиквелом тычешь? давай сюда иди, я сам знаю, что с тобой делать"
юзер:"погоди, я тебе, что тупое хранилище данных, глупая структура? я так и знал, тебе ничего от меня, кроме полей не нужно!!!"
все уходят в нул поинтер эксепшен.
занавес.
Моё понимание:
Акт 1. "Ваша вселенная" :
Вы говорите: "эй, юзер, вот тебе новое имя -- переименуйся".
Юзер: "ок, шеф, без проблем".
(Вы идёте курить трубку)
Акт 2. "Вселенная юзера".
Смена декораций. Никакого юзера как сущности здесь не существует, юзер здесь -- это Вселенная, внутри которой и разворачиваются все события.
Коннектор: я слышал голос Бога, который сказал мне: "юниту сего мира, нейму Ивану, надлежит имя поменять своё. Отныне, нейм Иван пусть зовется Борисом, ибо такова воля моя, юзера, Бога твоего единого".
Коннектор (бормочет): хм... неизведынны пути Господни. Но я знаю как исполнить волю божью.
(берет лопату и делает реквест): "update user set name = "Борис" where name = "Иван", -- получет error 0.
Коннектор: Аллилуя!
Акт 3. "Возврат обртно".
Юзер: "эй, шеф..."
Вы (вытаскиваете трубку изо рта): "...А? Чего тебе".
Юзер: "все готово, теперь я Борис".
Вы (выбиваете трубку, вздыхаете): "Отлично, спасибо".
(Грустно уходите в закат пилить стопяцотую форму на вебе)
Занавес.
20:14 в php так не пишут уже давным давно
А как
@@Vilabz О великий Java кодер. Представь вселенную, где существуют аналоги гибернейта и в других языках, например доктрина=) Которая точно так же конфигурируется аннотациями (в контексте PHP это атрибуты), и имеет те же преимущества и недостатки что и гибернейт=) Там еще и пакетные менеджеры есть, и сборщики, и тесты пишут, и тайп хинты, и редис, и мемкешед и еще куча того с чем работают и Java кодеры. Прикинь=)
Егор, ты все верно мыслишь. Твоя идея понятна. Мы пишем на ООП средствами не ООП. Класс в нашем понимании - это некая "глобальная супер функция", просто вынесенная в отдельный класс.
Мне кажется, с текущим техническим подходом к ООП, в том числе и в Java, тебе сложно будет добиваться своей идеи. Ты писал, что собираешься свой язык писать, который будет четко следовать фарватеру ООП. Удачи тебе желаю! Искренне! Жду первой альфа версии! Переучивать java как язык - бесполезно. нужен новый язык, где нет того, что java позволяет, и того чего нет в java. Нужен новый "интерфейс", не в том понятии, в котором он преподносится в java, а я имею в виду - возможно новые номенклатуры языка нужны, которые будут правильно описывать сущность. Классов видимо не будет, но будет не замена таковых, а будет именно новое определение, возможно даже со сдвигом в мышлении, согласен - класс во всех книгах преподается как супер что-то, что имеет свое хранилище и действо.
Правильно сказал твой - ты апостол, а опостолу не легко :) удачи!
Раз в n лет появляется человек, который говорит: "Забудьте все что вы знали и делали до этого, вас всех обманули!")
Иногда такой человек оказывается прав)
43:00 Вся суть подхода
Егор - мой кумир!
Я "Щетаю" что hibernate и репозиторий паттерн - в целом, отвратительные вещи. И тут полностью поддерживаю Егора. Почему, в swift когда мы делаем layout.setFrame(), то он двигает сам себя на экране? И не делаем мы это, через какой то LayoutFrameHandler.moveLayout(layout, frame) ???? Потому что мы бы умерли от этого С style... это "мерзость" простите так разделять ответственности. Если мне как User нужно помнить свое имя, то я его храню в своем мозгу и в любой момент могу обратится напрямую к контроллеру памяти/мозгу, а не звать для этого дядю Васю/ака hibernate framework что бы он построил запрос для моего мозга.
Как только у тебя сущности начнут писать сами себя в бд, напиши как дела.
@@mexvision-3556 Я же не против, просто реально, мы пишем какую то ерунду процедурную, средствами ООП. Controller -> ControllerHelper -> Service -> Repository -> Model -> DTO. В будущем, думаю найдется человек спаситель, который вернет ООП в нужное русло. Каким образом это будет хз 😂✌
Репозиторий то тут при чем
Ну а теперь скажи такую вещь. Ты вообще разбирал то о чем говоришь? Репозиторий не отвечает за функционал пользователя. Дальше сам погугли, мне лень учить людей которые в этом не заинтересованы.
Проблема правильная. Решение любопытное. Доклад куцый. Стыдно что никто не упоминает Фаулера и не оперирует его терминологией. Только Николай вспомнил про Active Record. Но ни про Anemic, ни про Transaction Script ни слова. Никто не объясняет в какие объекты бизнес-транзакции помещать. В общем, вопросов на много больше чем ответов.
первый слайд и есть про anemic model
Я-то понимаю. Проблема в том что даже Фаулера не все понимают с его Anemic Model. И докладчик вместо того чтобы объяснить, ссылаясь на уже проделанную работу других в этой теме, сводит всё к аргументации "тут у нас True OOP, а вот тут нет". А давно устоявшуюся терминологию по вопросу почему-то подсказывают из зала. Тема отличная. Направление мыслей правильное. Но решения нет. Переделать всё на колбэки и Active Record это не решение. Отказаться от всех современных фреймверков это тоже не решение. И, что самое забавное, это притянутый за уши ORM, который к проблеме имеет посредственное отношение. А всего-то надо было взять какой-нибудь Spring Boot Hello World и показать на каждом слое как можно было сделать иначе.
@@wjblazkowicz а почему orm притянутый за уши? Это как я понял пример проблемы - что реляционность размазана по всему приложению
@@johnconstantine6331 притянутый за уши потому что никто на самом деле не мешает методы написать в классах сущностях. ORM это не запрещает. Обвинять его в этом сложно.
Есть такая вещь как DDD идея которой ядро энкапсулирующее бизнес логику, которая тестится юнит тестами. Все IO по краям - DB/REST/SOAP etc.
Тоже понял что речь о DDD, но все названия паттернов перекручены
Модель вместо агрегата
Users вместо репозитория
Даже про контексты было немного инфы
Что-то мне по сути докладов показалось, что человек просто любит декораторы и пытается везде их пропихнуть, даже там, где они не нужны
Вообще главная проблема - пытаться реалиционные даны натянуть на объекты ооп. А это абсолютно разные вещи, даже с точки зрения математики. Лучше решение - использовать статический класс для одного sql запроса(или несколько sql запросов С ОДНИМ РЕЗУЛЬТАТОМ), который на вход будет принимать данные БЕЗ использования структур(да, для запроса с 30 параметрами на вход использовать 30 параметров для функции) и на выходе выводить картеж. Структуры и объекты для параметров и результата sql не нужно использовать, чтобы не было соблазна переиспользовать их в других участках кода, то есть этого вообще не нужно делать, соответствено использовать структуры для параметров и результата sql бессмысленно. Если переиспользовать такие структуры - то твой код будет слишком связанный и слишком зависить от логики запроса
23:10 - Active Record. Какая прелесть.
Active Record без наследования?
Интересный доклад. Хорошее дополнение от Николая.
тема правильная, тема не раскрыта, стиль доклада вызывает желание убивать.
Хорошо бы чтобы на амазоне продаваемая книжка показала хотя бы один вразумительный пример использования. К сожалению пример содержит нечто похожее в самом выступлении - какой то мутный hello world.
Про MVC было продолжение на следующих выступлениях?
Ааа, блин, это тот самый yegor256, который топит за объекты. Вспомнил его. Обсуждали уже его подходы.
дак он же говорит нам про луковую архитектуру - в центре бизнес объект, остальное снаружи, на самом деле бизнес объект не обязательно по его словам должен сам реализовывать всё, например запись в БД, конвертирование себя в json и т.д....он может просто объявить интерфейсы для этого, да, теперь это уже не класс, а сборка, но все же...луковая же...если я неправ, то поправьте? Или же, то что он имеет ввиду копия эктив рекорд, только не обязательно объект в точности копирует реляционную модель?
Как я понял, он про то что объект должен сам в себе реализовать работу и с бд и уметь отдавать себя в xml, json итд.
Не похоже на луковую архитектуру, больше напоминает антипаттерн GodObject
@@thunderboy2208activeRecord
Шикарный доклад
39:40 Евгений Борисов?
я не бекенд разработчик, но уже наперед вижу очень много потенциальных проблем с таким подходом. Поэтому человек и не показывает сложные примеры.
Он вероятно никогда не работал на нормальном большом проекте. Причем тут ооп, процедуршина. Как тебе удобно писать, а потом всем поддерживать так и пиши. Где процедурно, где ооп, а где использую функциональшину. Я к примеру привык к функциональному подходу и много чего делаю с его помощью. Это позволяет быстрее писать. Его также можно и нормально поддерживать и дебажить, если привыкнуть. Правда соглашусь что писать тесты не всегда удобно под него. Но концепция какого-то большого объекта это полный изврат. Во первых почти полностью теряется переиспользование кода. С его подходами по выгрузке данных из базы или записи можно нарваться на большие проблемы с ресурсами, особенно если это какая-то большая живая система.
Нужно больше классов (c)
Прокси в спринге отлично выполняют роль этих ваших декораторов)
В некоторых сценариях это будет лучше
И кстати, с помощью спринг и рефлексии можно делать декораторы в императивном виде, и даже оборачивать конкретные методы с помощью простой аннотации
Почему все пиздят хибер за его скорость, что не оптимально работает и т.п. ??? и никто не делает докладов как надо правильно им пользоваться? Почему никто на докладах не рассказывает, что благодаря хиберу легке работать сразу несколькими таблицами >= 10 вместо того чтобы писать адские sql запросы с 10 join'ами???
Потому что с скл легко работать, если ты его знаешь?
чем проще работать с инструментом, тем больше надо знать, как устроены его внутренности) Иначе вместо удобства будет куча проблем.
Ну а в данном ролике больше речь не про "медленность" работы хибернейта, а про то, что можно как-то по-другому работать с данными с точки зрения ООП.
@@gaben-agent Вилами по воде. Никто так и не сказал как именно. Как-то можно, но мы не знаем как=) То что предложил автор доклада - изменения ради изменений, не применяемые даже самим автором нигде. Он говорит о том, что на практике не применялось, даже на средних по величине проектах. Я уже не говорю про большие системы. Ровно 0 плюсов от предложенного подхода я увидел для себя.
@@mexvision-3556 Ровно 0? Ну вообще-то код становится более прозрачным и объект принадлежит тебе. Логика не размазана по аннотациям и критериям.
Да, может практических применений не было, но доклад больше интересен с теоретической точки зрения. С научной, если хотите. Егор нас подталкивает задуматься о том, как можно писать код по другому, чтобы это больше походило на ООП и приводит небольшой пример. А конкретно какие буковки писать и куда вставлять чтобы всё сразу заработало... Ну это как-то слишком узко и скучно) Доклад и не ставит перед собой цели сразу дать практический аналог Хиберу, который работает из коробки и лучше Хибера.
@@gaben-agent Блять, чел, ты сам то вникал в то что он предлагает? =) Ахахаха, я просто ору с таких людей как ты, которые на серьезных щах, занимаются поиском истины в речах типа, который показывает CRUD класс и называет это объектом. Объект который вместо одного запроса в БД шлет по запросу на каждый геттер или сеттер. Затем чел предлагает ебануть декоратор. ДЕКОРТАТОР С КЕШИРОВАНИЕМ) Ведь это тоже в его понимании нормальный такой объект=))) Ебать. То есть сущности в контексте гибернейта, доктрины и прочих ОРМ - это хуйня. А CRUD обернут декоратором - это заебась. Вы блять фильтруйте инфу, парни. Это уже не смешно. Хоть немного свою голову подрубайте. Не стоит жрать всё то что тебе говорят типы с раскрученными ебальниками. Он туда книжки продавать пришел, а не мир изменять.
Я вот все смотрю Егора и он мне в принципе нравится 👍, но никак не могу понять шутит он или серьезно. Почему-то всегда кажется, что он просто стебется и проверяет компетентность публики, нет?
Понимаю о чем говорит егор и к этому и пришол. Все по полочкам в своих ячейках как интсрументы в мастерской и код не размазан по всему проекту(меньше спагетти)
Мне кажется такие практики которые тут обсуждаются ведут к нервным срывам программистов, и все хорошие патерны тут критикуются а плохие патерны привозносятся.
Спасибо, очень интересный доклад. В моём понимании, это доклад о противоречиях ООП.
@@Petr-kh1lt Согласен. Мне тоже кажется, что функциональный подход более продуманный и логичный.
Некие фантазии, абсолютно не практично выглядящие и пытающиеся решить надуманную проблему выстрелом себе в ногу.
При том с апломбом мессии.
Доклад прикольный, Егор харизматичный, идеи спорненькие....Золотая середина рулит..
тема правильная, но не раскрыта. Терминология не проработана. В комментах подсказывают особо больше полезности чем в докладе. Удивляет то что человек книгу написал, а самые простые вопросы вызывают негодование и удивление. Некоторые, как по мне, вообще в корне не правильно отвечены. Например где-то здесь th-cam.com/video/ckjAWXJWZEY/w-d-xo.html Егор говорит что все его обьекты имплементят один интерфейс. Странное решение которое и приводит к тому непониманию предмета публикой и дублированию изменений в коде. Обьект несёт КОНТРАКТЫ. Декорировать мы можем КОНТРАКТ и всё что мы делаем мы делаем по контракту. Когда приходит запрос на новый функционал - это новый контракт. В вызывающем коде мы получаем не пачку юзеров/постов/етц. - мы получаем пачку чего-то что реализует КОНТРАКТ! И тогда ни дублирования ни переписывания ни комбинаторного взрыва. Просто обьекты, которые реализуют множественные контракты.
Хотел бы я увидеть реальный рабочий пример от Егора скажем какой нибудь простенький MVC в виде библиотеки книг который на том же спринге пишется ~за час.
Я не хотел бы тратить время на монотонное создание сотен и тысяч файлов, вместо того что бы потратить час на разработку простенькой архитектуры
Хм, какой вы MVC хотите увидеть от человека, который считает MVC антипаттерном?
Простенькая библиотека книг, которая пишется за час на MVC, собирается за полчаса на MS Access без единой строчки кода. Вопрос задач, собираетесь ли вы свой прототип развивать и поддерживать.
Mvc во фронте уже раскусили: react предлагает совмещать разметку и логику в своих компонентах.
Что касается паттерна Repository, домены нам заменяют нехватку гибкости java в структурах данных, сам по себе репозиторий похож на тот самый любимый объект который знает как его сохранить и тд.
React предлагает полностью отделять разметку и логику.
Посмотрите на redux и прочее. Вся логика находится в отдельном методе, с которым оперируют через actions. Его легко тестировать.
Сам реакт используется только в качестве разметки
Сейчас он блоггер
Какой-то религиозный фанатик, а не разработчик. С какой стати ООП == прекрасный код, функциональный == плохой код?
Про apache spark смешно слушать, это по сути функциональный фреймворк.
он не говорит что функциональный код - плохой, он говорит что процедурный плохой
Функциональные мало от ооп отличается. Он говорит что процедурный сложнее поддерживать в больших приложениях. Всему своё место
Обидно, что так негативно восприняли
Так а толку. Если не нравится эта ОРМ, то сделайте форк и покажите как надо. github.com/hibernate/hibernate-orm
Да нет, приятно послушать. Несогласие не означает негатив. Егор - большой молодец!
Соглашусь, идти нужно от бизнес задачи, а не реляционной модели . То что, хибернейт медленный г..код не согласится только поклонник хибернейта. Но это ладно, есть более красивые реализации. Но и конкретного решения по теме я не увидел. Хоть бы ссылку на гитхаб дали.
Не благодарите github.com/
Не буду)
Вот какой-то true oo фреймворк автора github.com/yegor256/takes
Я реально согласен с тем чтоб классы не были по 1000-2000 и более строк ))
Хороший был stand-up. Особенно угарнул с шутки про получение xml для последующего форматирования в json.
Пока слушал совсем забыл что у нас существуют паттерны которые решают все эти проблемы.
Да кому нужны твои паттерны, ты пишешь код не правильно. И вообще, весь накопленный за десятилетия опыт миллионов программистов, который выносился в принципы ничего абсолютно не стоит. Так сказал таксист со своим бизнесом, который таксует для души=)
Какая нетерпеливая аудитория, жесть. Вот им прям надо сейчас что-то прокомментировать, так как у них видимо подгорает сильно) В итоге это превращается в базар, так как у каждого свои мысли, свои вопросы и попытки контраргументировать. Дайте закончить доклад, потом лезьте уже со своими вопросами. Ппц.
Это гораздо лучше чем пассивная аудитория
вот все классно, но возникает интересный вопрос - тупые объекты с данными (POJO) плохо, но вот мне надо вернуть из метода имя и фамилию пользователя и в каком виде я это должен вернуть по мнению автора
у Вас будет метод: user.serializeNameWithSurnameIntoJson(), без аргументов, который внутри не только выполнит сериализацию в String, но и запишет её в HttpServletResponse
короче, не знаю, как Вы, а я категорически против
и, если честно, пока не готов согласиться с Егором, что такой код более "чистый" и управляемый
@@ИгорьСелезнев-в2у и представьте что будет внутри этого метода, мы выберем из базы записи и сразу начнем пихать данные из ResultSet в какие небуть JsonObject, агрегируя их в JsonArray, мы шли в ООП за абстракцией, а в итоге будем работать с примитивами, не находите, причем наш User превращается в God Object, не находите
@@_ArturMamedov_ тут наверное подразумевается, что класс User - это statefull объекты, то есть Вы сперва методом user.loadById(), например, загрузили из базы, затем другим методом сериализовали в JSON, а так - да, god object, при этом, даже если сериализация и чтение из бд в разных объектах, все равно придется побегать к интерактивному подходу в коде, последовательно вызвав сперва чтение, затем сериализацию и запись в response, ну а в случае с Вашим примером так вообще получается, что мы процедурный код просто прячем "под ковёр" объекта.
Вобщем согласен с Вами, и получается, что мы только усложняем код и делаем его менее управляемым.
Вы точно смотрели видео? )
Вам ничего не может быть нужно "вернуть из объекта".
Идеологические противники втащили SQL в свой язык на уровне синтаксиса, чтобы только люди меньше смотрели в сторону функциональщины, а этот возмущается, что в Hibernate SQL размазан по коду...
вы ещё вижуал фокспро не видели!
Забавно слышать как ломает аудиторию и они аж с места кричат от боли
А ведь "делать mock этой сессии" - это и есть ООП во всей своей красе. Я всё-таки не до конца понимаю, что имеет в виду докладчик.
Егор разобрался в хибернейте, докладывает, что понял )))
"Надо доверять объектам, надо уважать объекты" - Надо встать перед ними на колени и молить о прощении за годы эксплуатации, предрассудков и гнета по отношению к ним. Давайте, всем залом бухайтесь на четвереньки и начинайте каяться и биться лбом об пол! Кто вообще позволил шизику нести со сцены весь этот бред?
Прям Objects Lives Matter))
Докладчик троль
Анемичные классы это называет, когда строят DTO, а все потому что в JAVA забрали возможность создавать модули, все только классами... Ограничения...
Процедуры и функции точно так же были придуманы, чтобы уменьшить количество информации в голове программиста. На самом деле любая модульная система реализует ту же задачу. У автора ООП головного мзга
single responsibility как раз таки нарушается, ваш объект отвечает за бизнес логику и за базу данных, такое себе
ORM реально какой-то бред, ненужная надстройка над нативным SQL, но к сожалению он удобен и безопасен, поэтому не смотря на убогость без него не обойтись
Немного в шоке был, увидев этот "декоратор", сочувствую.
дядька хорош
При данном подходе вся логика приложения со временем спустится в объект! И мы как раз получим не ООП, а старую процедурку!
У каждого объекта (сущнорсти) должно быть множественно число! Это вообще пиздец! Вы что там курите?
MVC - антипаттерн )) В завершении доклада нужно было произнести фразу "Земля плоская!"
Лол. Да, вся логика спустится в объекты. И, внезапно, это и есть ООП )
Это как раз то что Фаулер называет Rich domain model. Это как раз и есть ООП, когда обьекты сами знают что с собой делать, ты посылаешь ему сообщение и он что-то делает.
ru.wikipedia.org/wiki/Функционал
нет взять норм язык с монадами =)
Охренеть. Я понял теперь что такое лженаука и закостенелость мышления.
90% аудитории привыкло забивать гвозди молотком и когда им говорят, что гвозди можно не забивать а вкручивать шурупы электрическим шуруповертом - у чуваков происходит срыв шаблона, когнитивный ступор и жесткое отрицание существования иных парадигм.
Я не смог дойти до общения с аудиторией, но сам доклад -- это квинтэссенция той самой лженауки. Человек не понимает ни что такое модель, что она должна делать, не слышал про такие вещи, как CQRS и многое другое. Он действует именно как сторонник религии, искренне веря в чушь, которую произносит. Он просто не осознаёт свои ошибки в силу низкой квалификации, но судя по тому, что он пришёл с докладом -- он искренне считает, что что-то в этом понимает.
Подход вида "а давайте все выдавать в виде XML, а если нам нужно что-то иное, создадим прокси-обретку и будем парсить каждый раз XML, и никаких геттеров" - это тоже закостенелость мышления, догматизм в чистом виде.
ну так show me the code
Мне кажется, у Егора слабый научный бекграунд, так как он пытается лезть в архитектуру языков, при этом досконально не изуччив другие парадигмы и паттерны. Он смешал в одну кучу иммутабельность, ооп и фп. На гитхабе его проекты не впечатлили, больше похожи на курсачи.
@@gatos-su Идеи похожи на DDD но DDD продуман настолько хорошо, что тут с Users как то грусно стало
Исходя из слов Егора мы просто добавляем 1 абстракцию на обращение к БД, вместо ORM прослойки а далее добавляем по n-количеству абстракций для SRP. Мне кажется или в таком случае кэширующий декоратор объекта будет делать 2 вещи, а именно: 1) Обрабатывать объект 2) Использовать кэш для случаев, когда много обращений? Можно было добавить АОП и накинуть @Hasheble(class = "наш класс") и класс бы явно уменьшился и мы бы могли так же имплементировать 1 аспект для конкретного класса вместо построения одной абстракции над классом.
То что доклад про ООП не говорит о том, что ООП надо пихать постоянно и везде, поскольку как аспекты не называй они все равно аспекты
Откровенно говоря, такое объяснение ООП (такой пример - ужас) только путает людей и не дает четкого понимания, что такое ООП и как эта задача должна решаться.
1. Слой базы данных и предоставление доступа на запись и получение должен находится в отдельном классе. В нем должна быть реализована основная базовая логика работы с БД. Все классы логики, которые работают с базой, в качестве проперти должны иметь доступ к этому объекту. Тогда при смене БД нам не придется растекаться по всему проекту и искать вот такие вот классы пишущие себя в базу и исправлять их. Ужас.
2. Анемичные объекты плохо. Безусловно. И это действительно так. Но это не значит, что представленное решение, перестало быть анемичной моделью. Нет. Оно все еще анемичная модель, просто ее сеттер и геттер сильно повязан на базе. Перестала бы анемичная модель быть анемичной, когда та самая логика расчета значения тайтла, о котором говорил докладчик, была перенесена на уровень объекта, а не находилась извне. И тогда она перестанет быть анемичной. Вся логика, которая связана с пропертями объекта будет инкапсулирована в объект. А не наоборот, логика отдельно, а запись в базу в проперти. Фе.
3. ДТО не плохо. Взаимодействие между объектами логики, простая передача структур между методами, чтобы не делать 500 параметров, рано или поздно потребует выделение анемичных интерфейсов (те в которых описаны только проперти, и нет методов). Наследники интерфейсов - это те самые ДТО. Если у вас есть взаимодействие, между проектами, системами, слоями приложений, клиентом и бэком - вам обязательно нужно иметь ДТО. Потому что в этих прослойках не может существовать логика. Ее там быть не должно. Именно в этом суть и цель ДТО.
4. Объект и класс это не одно и тоже. ООП говорит о работе с объектами логики - классами. Объекты же это данные. И смешивать эти понятия не совсем корректно.
5. ActiveRecord гораздо более серьезный антипаттерн, чем использование ОРМ. Простое объяснение почему: а. попробуйте сменить с таким подходом тип БД и посмотрите, как удобно вам это получится сделать. б. Попробуйте разделить проект на разные базы - и вы увидете насколько это тяжело. в. Попробуйте переделать структуру базы данных - и вы умрете.
По сути правильная структура решения должна была бы выглядеть следующим образом.
1. Класс доступа к БД и не более того.
2. Классы отвечающие за запись в базу данных и работу с ней имеют доступ к объекту ОРМ и привязаны к определенной таблице в БД или связке таблиц. Они не знают о БД напрямую - они знают о ДТО таблицы которую обслуживают (и только они знают), и о том, какой интерфейс для объекта логики нужно вернуть наружу.
3. Классы ДТО для работы с БД, которые четко отображают структуру БД (не обязательно 1 к 1 если что, один ДТО может иметь в себе лишь часть полей из базы) и позволяют разрабу разобраться с тем, как это все хранится.
4. Объекты логики используют класс доступа к таблицам когда им необходимо. Они не знают вообще о БД. Вообще. Зато прекрасно знают об объектах логики. Трансферах, расчетах бюджета, обработке и тп.
И тогда, при смене БД или ее структуры - вам не нужно будет менять миллиард классов. Только классы связанные с БД. Если у вас ДИ вы просто переподключите нужный вам класс доступа к БД или к структуры в БД. И меняться это будет легко и понятно.
А представленный пример ужасен. Реально ужасен. И не удивлен, что люди вообще не поняли, в чем проблема с ОРМами
не знаю докладчика но чувак порет какую-то дичь. как будто сектант. нет ничего зазорного использовать классы как объекты хранения и передачи данных (DTO). тем более объектно-ориентированное программирование позволяет это делать и при этом соблюдены принципы SOLID. не надо засорять людям мозг.
DTO != VO
Чувак просто пропагандирует, что каждый объект должен уметь все и вмещать безграничный функционал в себя ))
Он сказал, объект должен содержать не более 70-100 строк кода, а не 3000-4000. Слушайте внимательно.
и? благодаря наследованию наследуем,наследуем,наследуем и в итоге конечный объект умеет все.. вникайте внимательнее
не каждый, и не всё )
как минимум исходный - будет уметь мало
зы. очень его код напоминает turbovision середины 90-х - лесенки new
все исходные сделать абстрактными) и не будет объектов умеющих очень мало)
@@КонстантинЪЪЪ он не про наследование, он про абстракции: декораторы, декораторы, декораторы
Куча ошибок в коде. Доклад хэйтера.
На вопросы начинает гадать. Неправильный подход. Наоборот типы и набор функций. В калькуляторе значения вводятся отдельно. Калькулятор объект.
вот у докладчика бомбанет, когда коммьюните отвергнет его идеи и через 10 лет его язык так и не станет мегапопулярным ))) это ж надо, столько обиды заиметь на имеющиеся инструменты и пойти свое колесо изобретать ))) А языки нынче модно писать...
OOP zombie
какой не приятный докладчик, жесть !!! не смогла его долго слушать, такой впечатление что он предлагает с Hibernate перейти на куриный бульон.
Не обижайте куриный бульон.
господи, какую чушь городит) харизматичный дядька)