До этого момента оставались непонятки по принципу подстановки Лисков. Посмотрел, ещё раз перечитал, и теперь ясно понял, в чём суть. Спасибо Николай 😎👍
Хорошее видео. Пересматриваю видео такого рода и в этот раз добавилось понимание некоторых принципов, спасибо. Было бы интересно посмотреть как классы, реализующие эти принципы, использовать в рабочем коде так что бы опять не получилась лапша из кода.
Учил SOLID, около двух месяцев назад(не глубокое понимание ,больше зубрежка) прошло время и благодаря таким вот видео начинаю понимать ...Спасибо автору!!!
Прекрасное видео! Такая просьба - сделай, пожалуйста, урок по функциям. Только не эту муть, о которой есть миллион видосов - типа: def.., бла-бла.., имя должно описывать что функция делает.., аргументы икс, игрек и пр. Объясни доходчиво, как выстраивать взаимодействие нескольких функций, как они передают друг другу параметры, либо пользуются одними и теми же параметрами.., и как их исполнение должно запускаться в РЕАЛЬНОМ ПРИЛОЖЕНИИ! ))
Подумаю, пока можешь с этим плейлистом ознакомиться, думаю, что частично тема там затронута - Реальные задачи разработчиков th-cam.com/play/PLQC1AzOdryAF8auaJB65iW_zRRxKwl3Oa.html
"Класс должен иметь одну область ответственности..." Ок. Создадим класс Report, соответственно, его область отвественности - отчеты. Это одна область? Одна. Класс отвечает только за отчеты. При этом класс может содержать методы отправки, генерации отчетов и т.д. Мне кажется формулировки автора не совсем корректны... Ну или пример не удачный.
Генерацию отчетов я бы точно оставлял в классе отчета, отправку, согласен, можно вынести в абстрактный отправщик, чтобы можно было легче менять механизмы отправки (почта/мессенджеры и тд) при этом переиспользовав их логику
Проблема в формулировке. Сам Р. Мартин говорил, что SRP не про область ответственности, а про причины изменений. Название неудачное, что вводит в заблуждение. Ближе к изначальному значению будет: сущность должна изменяться под воздействием единственной группы заинтересованных лиц. Если 2 независимых группы могут требовать изменений внутри 1 сущности - её следует разделить.
@@IvanIvanov-gc8te Изменения происходят в результате новых/измененных требований пользователей продукта, разработчиков и т.д.. Если несколько из этих участников могут нуждаться в схожих изменениях, их можно объединить в группу вместо рассмотрения каждого в отдельности.
![Используй эти структуры данных из модуля collections [Upper Junior]](http://i.ytimg.com/vi/rsg_JVkhJm4/mqdefault.jpg)
![Используй эти структуры данных из модуля collections [Upper Junior]](/img/tr.png)
![ค้าง (STILL) - GEMINI [ OFFICIAL MV ]](http://i.ytimg.com/vi/Ftxx3hk5vkU/mqdefault.jpg)
Спасибо за ваш труд, жаль что Олег Молчанов перестал делать видео, но ваш канал тоже ценная находка для джунов)
До этого момента оставались непонятки по принципу подстановки Лисков. Посмотрел, ещё раз перечитал, и теперь ясно понял, в чём суть. Спасибо Николай 😎👍
Как всегда, отличный ролик с подробным и понятным объяснением темы. Спасибо!
Грамотно все! Спасибо!
Хорошее видео. Пересматриваю видео такого рода и в этот раз добавилось понимание некоторых принципов, спасибо. Было бы интересно посмотреть как классы, реализующие эти принципы, использовать в рабочем коде так что бы опять не получилась лапша из кода.
Спасибо🫶
Хорошие примеры.
Наверное трудно все спроектировать «на перед» и ничего не упустить.
Учил SOLID, около двух месяцев назад(не глубокое понимание ,больше зубрежка) прошло время и благодаря таким вот видео начинаю понимать ...Спасибо автору!!!
Спасибо автору, видео недооценино!
Круто. Я бы так же упомянул Prototype и утиную типизацию. Или вынес бы в отдельный ролик.
отличное объяснение
Спасибо
Прекрасное видео! Такая просьба - сделай, пожалуйста, урок по функциям. Только не эту муть, о которой есть миллион видосов - типа: def.., бла-бла.., имя должно описывать что функция делает.., аргументы икс, игрек и пр. Объясни доходчиво, как выстраивать взаимодействие нескольких функций, как они передают друг другу параметры, либо пользуются одними и теми же параметрами.., и как их исполнение должно запускаться в РЕАЛЬНОМ ПРИЛОЖЕНИИ! ))
Подумаю, пока можешь с этим плейлистом ознакомиться, думаю, что частично тема там затронута - Реальные задачи разработчиков
th-cam.com/play/PLQC1AzOdryAF8auaJB65iW_zRRxKwl3Oa.html
@@nikolaypavlin, здорово! Спасибо!
Автор, а есть на git код примеров? Спасибо!
Не выкладывал, если остались еще исходники - залью в гист и приложу
Вроде понятно на простых примерах, но когда надо большую программу реализовать с кучей зависимостей, функционала - мозг ломается )
"Класс должен иметь одну область ответственности..." Ок. Создадим класс Report, соответственно, его область отвественности - отчеты. Это одна область? Одна. Класс отвечает только за отчеты. При этом класс может содержать методы отправки, генерации отчетов и т.д. Мне кажется формулировки автора не совсем корректны... Ну или пример не удачный.
Генерацию отчетов я бы точно оставлял в классе отчета, отправку, согласен, можно вынести в абстрактный отправщик, чтобы можно было легче менять механизмы отправки (почта/мессенджеры и тд) при этом переиспользовав их логику
Проблема в формулировке. Сам Р. Мартин говорил, что SRP не про область ответственности, а про причины изменений. Название неудачное, что вводит в заблуждение. Ближе к изначальному значению будет: сущность должна изменяться под воздействием единственной группы заинтересованных лиц. Если 2 независимых группы могут требовать изменений внутри 1 сущности - её следует разделить.
@@jekaadept6269 "группы заинтерисованных лиц"? O_o это как?
@@IvanIvanov-gc8te Изменения происходят в результате новых/измененных требований пользователей продукта, разработчиков и т.д.. Если несколько из этих участников могут нуждаться в схожих изменениях, их можно объединить в группу вместо рассмотрения каждого в отдельности.