На 24:25 мы захардкодили в класс через new наши фильтры, и теперь класс: 1) Отвечает за создание списка фильтров и самих фильтров, которые мы будем применять к посту (Мы буквально явно создаём объекты внутри метода) 2) За применение созданного списка фильтров к посту 3) За сохранение нашего поста. Не много ответственности для одного класса?
Чудесное выступление, отличная подача. В силу опыта, я не смог всё переварить, но Вы, Александр, меня очень впечатлили) никогда еще не видел настолько хорошо подготовленных докладов)
24:52. можно еще сделать чтоб интерфейс фильтра имел дефолтную реальзацию принимал объект preparationservice и вызывал у него метод инит в который передавал бы себя а там происходило бы добавление в лист объекта фильтра
Я что-то не понял, как это "добавление нового фильтра не требует модификации старого кода". А в лист же новый фильтр надо добавить - значит код надо модифицировать
@@bormanbor8740 По идее, нужно создавать новый класс, в котором создаёшь новый список фильтров и применяешь их к изображению, но да, слишком много ответственностей на один класс
@@isey2851 подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый класс
@@isey2851 а тут что тогда написано? ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%BF%D0%BE%D0%B4%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8_%D0%91%D0%B0%D1%80%D0%B1%D0%B0%D1%80%D1%8B_%D0%9B%D0%B8%D1%81%D0%BA%D0%BE%D0%B2
Чистый код очень субьективная вещь, в вопросах речь зашла про золотую середину, проблема в том что ни одной достоверной матемвтически доказанной метрики/теоремы для этого нет, с солидом схожая история вопросы из зала в часности это подсветили, так же они не совсем универсальны и было бы лучше если бы они были переведены на прикладной уровень конкретного языка, например на RoR на котором я сейчас пишу код нет чистокровных интерфейсов да есть депенденси иньекшен как способ заигрывания с интерфкйсами или абстракциями но это не тоже самое, самое важный патерн это публичная оферта в рамках продукта - брейнсошиал
Принцип разделения интерфейсов объяснен правильно, но пример показан совершенно обратный сказанному. Интерфейс оставили один, только добавили к нему дополнительный метод. Теперь все реализующие классы должны будут тоже изменить свои реализации. Принцип инверсии зависимостей вообще никак не связан ни с интерфейсами, ни со Спрингом, например. Вопрос в том, получает ли класс свои зависимости сам, или ему их предоствляют. Таким образом DI можно осуществить и полностью на конкретных классах, без абстрактных классов или интерфейсов. По остальным принципам тоже есть вопросы...
@@isey2851 но ведь с точки зрения реального мира, у юзера есть посты и комменты, тогда именно юзер должен содержать список постов или комментов. Мы же сейчас не про БД, а про модель в бизнес-логике.
@@alexdayneko5084 не. Если говорить про объектную модель, то нет. Комменты у поста это не свойство поста, как и посты у юзера. А вот у коммента свойства аля text, header, publicationDate, publisher и тд
@@isey2851 все равно не понимаю. Может быть есть какие-нибудь книги или статьи с объяснением? Например, почему не может быть список постов свойством юзера? Это же отношение композиции, ведь пост юзера не может существовать без юзера
@@alexdayneko5084 Да просто логически подумай. Представь что форму о себе заполняешь, куда там посты то будут. Посты это не свойство юзера, они просто имеют к нему отношение с точки зрения пренадлежности. Пост не может без юзера существовать, но юзер без поста легко
В моменте с комментарием не проще было через event (Observable) запилить ? Сервис нотификаций подписан на эвент комментария - гораздо логичнее чем городить какие то левые классы. Об этом кстати был вопрос и ответ. Делегат круче работает в данном конкретном примере.
Ребзя, вы все такие рассказываете о солидах и так далее. Но куда не прийди на проект - кругом пизда и адища. Еще и применять эти принципы на практике не пробовали?
Отвратительный доклад. Монотонная речь, не раскрыты принципы SOLID (L, I - вообще не по теме, докладчик и сам, очевидно, не понимает этого принципа), примеры - не выразительные...
3:40 Это всё рассказанное - не стандарты, а практики, техники, паттерны... А стандарт - тоже есть. Уже лет 40 наверное. ЕСПД называется :) 14:43 Серьёзно - стало лучше? Было, пусть и в циклах, но - всё по делу и любой джун поймёт что написано. А предлагается добавить в код какие-то сущности, не относящиеся к задаче: stream. flatMap, map, collect... И всё для чего? Чтобы код стал понятен только тем, кто знает, что это за сущности?
@@vladimirlazarev2267 читаемость кода увеличилась в разы. Kiss никуда не делся, а писать код с кучей вложенных циклов потому что нет других идей никак не тянет на ход конём
Создаётся только одна сущность - коллекция, а всё, что вы описали - это методы Stream API, функциональное программирование, когда ты вместо того, чтобы писать КАК РЕАЛИЗОВАТЬ, пишешь буквально ЧТО РЕАЛИЗОВАТЬ, а добрые дяденьки уже реализовали простые вещи за тебя, такие как фильтрация, преобразование одного объекта в другой и т.д.
Критикуешь - предлагай, опишите в чем именно была ошибка, истолкуйте, как вы считаете, правильно. А коллеги, если посчитают действительно ценным вашу поправку - закрепят комментарий.
Кажется этот доклад для тех, кто уже разбирается в принципах SOLID... Почему слайд с описанием всех 5ти принципов так быстро проматывается? Кажется автор делал доклад на 1 час 20 минут, а ему сказали ужать на 45 минут. Дизлайк.
это точно, этот метод прям кровь из глаз вызвал. Пост ничего не знает про какие то там уведомления, не то, что кому из посылать, даже о их существовании не догадывается. 🤦♂️
Боже, насколько же это офигенный материал! 🤩 Автор, спасибо тебе от души!
На 24:25 мы захардкодили в класс через new наши фильтры, и теперь класс:
1) Отвечает за создание списка фильтров и самих фильтров, которые мы будем применять к посту (Мы буквально явно создаём объекты внутри метода)
2) За применение созданного списка фильтров к посту
3) За сохранение нашего поста.
Не много ответственности для одного класса?
Самый недооцененный доклад о принципах SOLID!
Отличный содержательный доклад, без воды!
Очень интересный, доступный и подробный доклад, спасибо!
Чудесное выступление, отличная подача. В силу опыта, я не смог всё переварить, но Вы, Александр, меня очень впечатлили) никогда еще не видел настолько хорошо подготовленных докладов)
Хороший доклад, видно что рассказчик неплохо разбирается в теме!
Очень крутой доклад, без воды и понятно
В первые три минуты уже услышал дельные вещи. Лайк сразу.
Потрясающий доклад. Очень структурированно, понятно и наглядно. Особенно с последней буквой (D).
Хороший доклад. Спасибо!
Талантливо!!! Жаль, что нет собственного канала на TH-cam 🙁
Интересно. Спасибо!
35:47 похоже ошибка, в "Реализации сервисного слоя" имплементация сервиса зависит от интерфейса DAO, а наоборот
где доступны коды?
неймінг з Impl в кінці те що треба 😂
24:52. можно еще сделать чтоб интерфейс фильтра имел дефолтную реальзацию принимал объект preparationservice и вызывал у него метод инит в который передавал бы себя а там происходило бы добавление в лист объекта фильтра
Вы сейчас описали Registry Pattern.
Я что-то не понял, как это "добавление нового фильтра не требует модификации старого кода". А в лист же новый фильтр надо добавить - значит код надо модифицировать
@@bormanbor8740 По идее, нужно создавать новый класс, в котором создаёшь новый список фильтров и применяешь их к изображению, но да, слишком много ответственностей на один класс
Принцип Liskov Substitutional вообще об иерархии и о предсказуемости поведения в иерархии
Можете расшифровать ? Принцип до боли простой конкретный, вы написали нечто очень абстрактное
@@isey2851 подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый класс
@@gatos-su вообще мимо Liskov Substitution
@@isey2851 а тут что тогда написано? ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%BF%D0%BE%D0%B4%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8_%D0%91%D0%B0%D1%80%D0%B1%D0%B0%D1%80%D1%8B_%D0%9B%D0%B8%D1%81%D0%BA%D0%BE%D0%B2
@@gatos-su чел, явно не то, что ты написал
Поднимите руку, кто считает, что лучше утром, а не вечером.
Принцип разделения интерфейса не показан. Пример не имеет отношения к разделению интерфейсов ввиду разделения метода, а не интерфейса.
Чистый код очень субьективная вещь, в вопросах речь зашла про золотую середину, проблема в том что ни одной достоверной матемвтически доказанной метрики/теоремы для этого нет, с солидом схожая история вопросы из зала в часности это подсветили, так же они не совсем универсальны и было бы лучше если бы они были переведены на прикладной уровень конкретного языка, например на RoR на котором я сейчас пишу код нет чистокровных интерфейсов да есть депенденси иньекшен как способ заигрывания с интерфкйсами или абстракциями но это не тоже самое, самое важный патерн это публичная оферта в рамках продукта - брейнсошиал
ОООчень полезное видео для меня оказалось, так как изучаю java )))
Принцип разделения интерфейсов объяснен правильно, но пример показан совершенно обратный сказанному. Интерфейс оставили один, только добавили к нему дополнительный метод. Теперь все реализующие классы должны будут тоже изменить свои реализации.
Принцип инверсии зависимостей вообще никак не связан ни с интерфейсами, ни со Спрингом, например. Вопрос в том, получает ли класс свои зависимости сам, или ему их предоствляют. Таким образом DI можно осуществить и полностью на конкретных классах, без абстрактных классов или интерфейсов.
По остальным принципам тоже есть вопросы...
ты путаешь dependecy inversion c ioc/dependency injection
Почему пост и комменты содержат ссылку на юзера, а не наоборот? Это результат какого-то долгого анализа или есть какое-то правило?
у поста или коммента один овнер, а у юзера их может быть много. ManyToOne/OneToMany
@@isey2851 но ведь с точки зрения реального мира, у юзера есть посты и комменты, тогда именно юзер должен содержать список постов или комментов. Мы же сейчас не про БД, а про модель в бизнес-логике.
@@alexdayneko5084 не. Если говорить про объектную модель, то нет. Комменты у поста это не свойство поста, как и посты у юзера. А вот у коммента свойства аля text, header, publicationDate, publisher и тд
@@isey2851 все равно не понимаю. Может быть есть какие-нибудь книги или статьи с объяснением? Например, почему не может быть список постов свойством юзера? Это же отношение композиции, ведь пост юзера не может существовать без юзера
@@alexdayneko5084 Да просто логически подумай. Представь что форму о себе заполняешь, куда там посты то будут. Посты это не свойство юзера, они просто имеют к нему отношение с точки зрения пренадлежности. Пост не может без юзера существовать, но юзер без поста легко
на скорости 1.5 вообще пушка
В моменте с комментарием не проще было через event (Observable) запилить ? Сервис нотификаций подписан на эвент комментария - гораздо логичнее чем городить какие то левые классы. Об этом кстати был вопрос и ответ. Делегат круче работает в данном конкретном примере.
i, j, k -это говорили что имена переменных целые , если начинались с этих букв в FORTRAN
Отличный доклад. Как написать код, в котором куча классов, между которыми сложно понять, что вообще происходит
Ребзя, вы все такие рассказываете о солидах и так далее. Но куда не прийди на проект - кругом пизда и адища. Еще и применять эти принципы на практике не пробовали?
Ну так очевидно же, SOLID это про чистый ООП, а то что у автора в презентации это процедурка завернутая в классы(сервисы).
Классный ментор
9:22 Train-o-Gram
9:47 - отношения без направлений на диаграмме классов - жирный дизлайк.
Отвратительный доклад. Монотонная речь, не раскрыты принципы SOLID (L, I - вообще не по теме, докладчик и сам, очевидно, не понимает этого принципа), примеры - не выразительные...
и не говори, он же поверил дяде бобу, который неверно сформулировал свои принципы SOLID, на самом деле дядя боб имел ввиду совсем не то ..
3:40
Это всё рассказанное - не стандарты, а практики, техники, паттерны...
А стандарт - тоже есть. Уже лет 40 наверное.
ЕСПД называется :)
14:43
Серьёзно - стало лучше?
Было, пусть и в циклах, но - всё по делу и любой джун поймёт что написано.
А предлагается добавить в код какие-то сущности, не относящиеся к задаче: stream. flatMap, map, collect...
И всё для чего? Чтобы код стал понятен только тем, кто знает, что это за сущности?
по поводу второго - так это же стримы из Java 8, непонятны только для тех, кто с ними не работает.
@@lexxx1994 Это понятно, но всему своё место.
Усложнять код только "потому что могу" - так себе идея.
@@vladimirlazarev2267 согласен, "keep it simple, stupid" никто не отменял)
@@vladimirlazarev2267 читаемость кода увеличилась в разы. Kiss никуда не делся, а писать код с кучей вложенных циклов потому что нет других идей никак не тянет на ход конём
Создаётся только одна сущность - коллекция, а всё, что вы описали - это методы Stream API, функциональное программирование, когда ты вместо того, чтобы писать КАК РЕАЛИЗОВАТЬ, пишешь буквально ЧТО РЕАЛИЗОВАТЬ, а добрые дяденьки уже реализовали простые вещи за тебя, такие как фильтрация, преобразование одного объекта в другой и т.д.
смотря данное видео я чувствую что я умнею XD прилив сил
Неверно истолкованы принципы solid, а именно l и i, коллеги, проверять такие вещи надо перед публикацией...
Критикуешь - предлагай, опишите в чем именно была ошибка, истолкуйте, как вы считаете, правильно. А коллеги, если посчитают действительно ценным вашу поправку - закрепят комментарий.
Слишком быстро говорит. Без пауз с перемотками невозможно понять.
На 1.5 самое то. Слайды на паузу, ну круто что есть пауза
Вступление жесть
нужно писать говнокод
это быстро, и самое главное дать клиенту то что он хочет, какая разница хорошый код или нет, главное что бы он работал
Особенно на галере. Там друг другу мердж-реквесты не отклоняют.
только потом настанет момент, когда нельзя уже реализовать быстро, а то и вовсе нельзя реализовать без перепиливания. Говнокод - это техдолг
Кажется этот доклад для тех, кто уже разбирается в принципах SOLID...
Почему слайд с описанием всех 5ти принципов так быстро проматывается?
Кажется автор делал доклад на 1 час 20 минут, а ему сказали ужать на 45 минут. Дизлайк.
Тоже заметил такое. Смотрел на скорости воспроизведения 1.5.
Может из-за этого?
мечтаю попасть в команду где нет говнокодеров!
нет таких :))
Спустя 3 года.
Мечтаю попасть в команду. Можно с говнокодерами.
максимально тяжело слушать несвязанную речь.
Отличная реклама epam (нет)
Из полезного - только рекомендация книги
Метод getLikeNotificationsRecipients(), добавленный для того, чтоб избежать нарушения принципа L, сам нарушает принцип L ...
это точно, этот метод прям кровь из глаз вызвал. Пост ничего не знает про какие то там уведомления, не то, что кому из посылать, даже о их существовании не догадывается. 🤦♂️
Очень крутой доклад, без воды и понятно!!!