Мне нравится твой подход и подача материала. Видно, как тебе нравится рассказывать это. И вижу тебе правда есть, что рассказать. Молодец. Хочу все твои видео посмотреть.
супер, спасибо. но я всё таки думаю, что ReaderActions не в той мере зависят от дизайнера, поскольку компонент не отвечает за визуальный вид кнопок, а отвечает только за то, чтобы отобразить кнопку и передать ей current handler
1. Да, модуль может быть процедурой, структурой данных или объектом в зависимости от парадигмы. Но когда речь идёт о SOLID, мы автоматически оказываемся в ООП. И тогда мы должны говорить в первую очередь о предметной области, о модели данных, о разделении модели и представления, об объектах - той же карточки, написанной на js/ts и которая не должна знать о существовании UI в принципе. Отсутсвие объекта Карточка или его деструктуризация в виде {cardId, title, content ...} уже нарушает принципы ООП, потому что объект неделим, целостен и должен скрывать свои данные от внешнего мира. В результате мы имеем дело не с объектами, а структурами данных (которые как раз открывают свои данные внешнему миру) и react-компонентами, что воплощает собой процедурное программирование, на котором ООП и SOLID не объяснить. В видео мы видим в итоге лишь модуляризацию UI-слоя. 2. Мне как раз всегда было понятно с "одной причиной для изменения" и не понятно с акторами. Все паттерны проектирования строятся на разбиении объектов по принципу "выделяй то, что меняется", и никаких акторов здесь мы не найдём. 3. Нужно не забывать, что Роберт Мартин использует свой опыт разработки интерпрайз-приложений на c++/java, где автоматизируется работа предприятия, взаимодействие отделов. И когда он упоминает бухгалтерию, администраторов, пользователей системы, он воспринимает их как часть предметной области, чьи объекты, связи и бизнес-логика должны быть отражены в программе.
полностью солидарен с вами, коллега, прям как с языка сняли, тоже не очень нравится такой подход объяснения SOLID у Михаила Непомнящего намного менее размазанно и в точку, применимо к REACT.... а тут какое то мессиво из непонятно чего намешано
Мне нравится твой подход и подача материала. Видно, как тебе нравится рассказывать это. И вижу тебе правда есть, что рассказать. Молодец. Хочу все твои видео посмотреть.
Очень жду следующих видео по остальным 4 принципам, очень круто!
Ну кстати, а нельзя ли прописать через дот нотацию все actions, которые могут быть переданы в чилды карточки? Такая же композиция
Дружище это круто. Сам читаю эту книгу и не до конца доходило. Теперь пазл сложился.
Благодарю за видео! Очень доходчиво! Вот с таким подходом можно будет писать качественный и понятный фронт
Спасибо за понятные объяснения)
Ещё было бы здорово на похожих примерах разобрать GRASP)
Разберу, но позже. До этого будет ещё много видосов про solid
Круто, посмотрю все выпуски
Годненько, очень нуно ) спасибо, "требую продолжения банкета!"
Очень круто, благодаря примеру на фронте всё стало куда понятнее!
ура наконец то! да еще и react!
супер, спасибо.
но я всё таки думаю, что ReaderActions не в той мере зависят от дизайнера, поскольку компонент не отвечает за визуальный вид кнопок, а отвечает только за то, чтобы отобразить кнопку и передать ей current handler
1. Да, модуль может быть процедурой, структурой данных или объектом в зависимости от парадигмы. Но когда речь идёт о SOLID, мы автоматически оказываемся в ООП. И тогда мы должны говорить в первую очередь о предметной области, о модели данных, о разделении модели и представления, об объектах - той же карточки, написанной на js/ts и которая не должна знать о существовании UI в принципе. Отсутсвие объекта Карточка или его деструктуризация в виде {cardId, title, content ...} уже нарушает принципы ООП, потому что объект неделим, целостен и должен скрывать свои данные от внешнего мира. В результате мы имеем дело не с объектами, а структурами данных (которые как раз открывают свои данные внешнему миру) и react-компонентами, что воплощает собой процедурное программирование, на котором ООП и SOLID не объяснить. В видео мы видим в итоге лишь модуляризацию UI-слоя.
2. Мне как раз всегда было понятно с "одной причиной для изменения" и не понятно с акторами. Все паттерны проектирования строятся на разбиении объектов по принципу "выделяй то, что меняется", и никаких акторов здесь мы не найдём.
3. Нужно не забывать, что Роберт Мартин использует свой опыт разработки интерпрайз-приложений на c++/java, где автоматизируется работа предприятия, взаимодействие отделов. И когда он упоминает бухгалтерию, администраторов, пользователей системы, он воспринимает их как часть предметной области, чьи объекты, связи и бизнес-логика должны быть отражены в программе.
полностью солидарен с вами, коллега, прям как с языка сняли, тоже не очень нравится такой подход объяснения SOLID у Михаила Непомнящего намного менее размазанно и в точку, применимо к REACT.... а тут какое то мессиво из непонятно чего намешано
Такие же мысли были во время просмотра видео
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
Такое можно только экстримКоде
Было бы здорово если бы это было залито на гитхаб
Сделай докер для ноды
Ок, сделаю
оригинальный "тэйк" на принцип S
очень кроту объяснаешь !