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