SOLID принципы js. Объяснение принципов на примере framework Angular. solid design principles

[@grommaks]

Приветствую друзья! Зацените как я разбил полосу прокрутки. KZbin делает интерфейс удобным! ✌️ Это видео далось мне трудно, по этой причине на этой неделе будет только одно видео, зато аж на 40 минут по очень важной теме :) Я не тратил времени на просьбу поставить лайк и подписаться, по этому оставлю это в комментариях 🐶 Пиши, что еще ты хотел бы видеть у меня на канале? Хорошего настроения тебе мой друг 😎😸✌️

[@Sergei546]

Очень полезный урок! Спасибо! Насчёт React, аналога pipe там тоже не наблюдал, заменяю просто самописной функцией, которая что-либо делает с данными, приходящими в props в момент отрисовки компоненты

[@grommaks]

Часто делают компонент который является пайпой. Но в этом случае не понйтно как в аттрибутах использовать что-то подобное :) По этому функция это идеальное решение для реакт ;)

[@IngvarLosev]

Спасибо, по больше таких уроков.

[@VictorKorovin-s9q]

Классное объяснение, спасибо. Поставил лайк, хотя пришлось плюсонуть знакомую цифру - 404 )

[@johnd1431]

Отличнейшее видео, огромное спасибо

[@viss23]

Спасибо за видео, мне повезло что я на него наткнулся.

[@grommaks]

Рад что мое видео помогло Вам :)

[@user-san-chous]

Интересный факт (из книги "Чистая архитектура", которую начал читать). Single Responsibility в SOLID на самом деле значит не то, что одна структура - одна задача (т.е. что каждый кусок кода должен делать что-то одно, как пишут). На самом деле это другой принцип, который тоже существует, но не входит в SOLID. А здесь же Single Responsibility означает, что модуль должен отвечать только за одного пользователя (ну или группу, разумеется, автор называет это actor) и в итоге иметь только одну причину для изменений. И по словам автора, этот принцип из всех самый сложный для понимания. Там есть хорошие примеры того, что имеется в виду, но здесь их расписывать долго. Хотя будучи 2 года в разработке (коммерческой), множество раз слышал именно этот вариант) в т.ч. от других известных блогеров. Но эту путаницу можно отследить, как она появлялась в разных источниках, включая украинскую и русскую Википедии, где в одну кучу намешали два этих принципа. А вот в английской википедии не заморачивались, а просто взяли выдержки из книги)) И можно даже найти разъяснение Роберта Мартина. Все-таки он придумал этот принцип)

[@grommaks]

Single responsibility относится ко всему :) Метод, класс, модуль, библиотека, приложение, сервис(микросервис) Мой главный посыл, что юнит должен отвечать за одну зону ответственности (тут уже нужно решать внутри команды что это значит, везде по разному), и за одну зону ответственности отвечает один юнит Например мне нужно сгенерировать дату в приложении, должен быть один путь сделать это и только один, этот юнит можно расширить по необходимости, но он останется одним юнитом

[@user-san-chous]

@@grommaks да, я понимаю) и понимаю важность. Но в то же время это, кажется, вполне понятным (а в книге принцип описан, как самый сложный для понимания). Я говорю чисто только о теории, что вкладывает на данный момент автор этого принципа в его понятие в составе SOLID. Просто, как интересный факт. Ведь в книге он так прямо говорит, что не это имел в виду и что само название, видимо, вводит в заблуждение большинство разработчиков. На самом деле первый и второй вариант очень похожи. Но все-таки это не одно и то же. И в оригинале в этот принцип автор (он же автор книги) вложил немного иную суть. Это все есть в первых двух абзацах раздела "Принцип единственной ответственности". Хотя если гуглить, то все наводят именно первый вариант трактовки)

[@grommaks]

@@user-san-chous многое из того что придумали в оригинале трактуется по другому :) как песни могут вызывать разные эмоции Автор писал свои принципы десятки лет назад, стоит прислушиваться к мнению авторов (Мартина или меня) но надо анализировать контекст своего приложения P.S. Спасибо за дополнение, надеюсь скоро доберусь до этой инфы, заинтересовался что же там такого написано :)

[@photoskins6503]

Це шедевр! Де ти був раніше?

[@grommaks]

Дякую за відгук

[@Re_p1ay]

Зашёл просто чтобы посмотреть рекламу Всем добра....и денег 😁

[@grommaks]

Спасибо 😅

[@bukanaka]

Информация очень топовая, растём до мидла)

[@НиколайВладимирович-к5ф]

Спасибо за видео! 40:02 Есть желание послушать про DI в Angulare

[@grommaks]

Обязательно) nestjs использует angular di framework. Спасибо за отзыв) это меня мотивирует

[@grommaks]

Забыл сюда прикрепить ссылку, думаю будет полезно новеньким которые увидят запрос тут kzbin.info/www/bejne/aIndh6qpi5h7qrM Надеюсь смогу снять вторую версию ближайшим временем

[@sergeisychov9810]

Спасибо. Крутое видео. Осталось где-то найти работу, чтобы набить руку по этим принципам)))))))

[@Сайхан-н4б]

спасибо

[@Kulibins1]

Почему так мало подписчиков? Материалы автора хороши.

[@grommaks]

Растем по немногу) Ваши коментарии помогают ютубу продвигать мои видео) а мне получать удовольствие от разработки уроков и расти по качеству контента ;) Спасибо за отзыв)

[@grommaks]

Ух какое качество звука у меня год назад было) явно видео требует того, чтобы я его переснял)

[@bukanaka]

@@grommaks Эт я как раз попал сюда

[@MrVIPKent]

Є бажання відео про DI. Макс не зупиняйся! Ти кращий!

[@grommaks]

По DI є два плейліста) може буде ще

[@MrVIPKent]

@@grommaks Макс головне не зупиняйся!

[@roman_freedom]

Спасибо за видео! Сделай пожалуйста видео о Change detection and NgZone

[@grommaks]

Сделал не так давно видео об Render в Angular. Если еще актуально то вот kzbin.info/www/bejne/mGikeoSHbdqjf6s , а так может пригодится новым зрителям)

[@roman_freedom]

@@grommaks большое спасибо! Это всегда актуально

[@user-san-chous]

Спасибо тебе большое. Тебе надо бы запилить курс для новичков по Ангуляру. И подписчиков станет много, либо на Юдеми можно выложить - спрос будет большой, так как в рунете среди Аналогов только Минин, а он не лучший эксперт... Ну и микрофон бы поменять на более качественный))

[@grommaks]

С микрофоном решил проблему) по поводу курса думаю скоро начну над ним работу

[@markostr]

Спосибо !

[@yuriiyurii6656]

Amazing

[@ilnurryazhapov]

вообще супер пупер круто только микрофон нужно получше

[@grommaks]

1) слегка слышно дыхание (думаю на петличку смогу писать более качественно) 2) есть небольшой шум (думаю дополнительная обработка звука поможет) 3) с громкостью все нормально Правильно все понял? :) мои уроки Git вообще с печальной гарнитурой :) переписывать нужно будет весь курс :)

[@romanryaboshtan9270]

40:15 Хотелось бы про DI в обычном JS

[@grommaks]

Трах тиби дох: kzbin.info/www/bejne/fHfClqyXeNeNepo Приятного просмотра)

[@dimon.digital]

Понимаю что от наследования нужно избавляться, но как реализовать шаблон Абстрактный Класс без наследования, класс который относится как один у многих?!

[@grommaks]

Через наследование, в JS через декораторы или наследование или миксины. Больше вопрос, а нужен ли этот паттерн? Я знаю лишь один случай его оправданного применения, это в SPI, но даже там сейчас делают не через наследование, а через помещении логики абстрактного класса в ядро, и через интерфейсы происходит переопределение этой логики . По типу если нет метода ngOnDestroy то вызови стандартный метод или вовсе не вызывай ничего

[@dimon.digital]

@@grommaks спасибо. Я имею ввиду стандартную базовую реализацию через extends TypeScript. Чтобы полностью избавиться от наследования нужно будет выпилить часть стандарта EcmaScript)) То есть от наследования в целом уже не избавиться полностью никогда, в контексте Angular и TypeScript

[@grommaks]

@@dimon.digital я не говорю что наследование не должно быть, наследование нужно использовать в тех местах где это нужно P.S. прошлое поколение приложений было построено исключительно на огромном количестве наследований. По этому с ними до сих пор боятся говоря что наследование это зло P.S.S. наследование зло как основа фреймворка, но не как явление в целом :) Но ни в реакт ни в ангулар проектах, даже в большинстве PHP проектах мне не приходилось использовать наследование для решения задач за последние 2-3 года работы, кроме явно жирных мест которые невозможно было быстро перевести на новый подход. 5-6 лет назад все было построено исключительно на наследовании...к примеру jQuery widgets, Magento 1

[@miraclechina1301]

Не понял нащёт принципа лисков как мне тогда передать значение какое то в класс если я должен использовать только родителя и его переменные, с принципами ООП не вяжется...

[@grommaks]

1) очередность параметров должна быть такой же 2) типы данных по параметрам должны быть теми же 3) новые параметры должны быть не обязательными 4) если меняете свой класс (супер класс) то нельзя добавлять обязательноые параметры (если есть шанс что класс был унаследован) Все это справедливо если мы говорим о подмене суперкласса подклассом. Представьте что код, который использует подкласс думает что он работает с суперклассом...и нужно сделать так, чтобы ничего не сломать

[@grommaks]

Если пришлете ссылку на гист, с конкретным примером где не понятно как правильно сделать, то смогу ответить ;)

[@miraclechina1301]

@@grommaks , спасибо Максим, но пока не могу, спасибо за вашу роботу но буду сам грести)

[@FerelUltra]

23:40. Как это наследование антипаттерн? И как это не один из китов Ооп? Непонятно.

[@grommaks]

Как это обычно бывает, сначала все фреймворки строились на базе наследования, теперь на базе Dependency Injection. Благодаря DI используют композицию вместо наследования, так как композиция дает больше гибкости и безопасности при доработки, то наследование искореняют со всех мест где это возможно сделать. Декораторы в Angular тому пример, зачем наследоваться от базового компонента если можно использовать декоратор. Реакт классовые компоненты уходят в пролшлое благодаря хукам (совершенно другой подход к решению той же самой проблемы) Во вью за счет миксинов решается вопрос расширения компонентов В PHP во многих решениях уходят от наследования, как в библиотеках так и во фреймворках Если кратко, если сказать что наследование это второе поколение создания расширяемого кода, то композиция это третье поколение. Естественно дальше может все поменяться, но сегодня такая ситуация

[@FerelUltra]

@@grommaks круто разъяснил. что тогда первое поколение расширяемого кода?

[@grommaks]

@@FerelUltra код в стиле СИ это первое поколение. Функции, процедуры и структуры данных В таком стиле написан линукс В таком стиле написан WordPress Еще можно отнести код где функции раскиданы по объектам, как правило как статические методы только используются, такие приложения любили называть как ООП приложения :) но на самом деле это все то же старое процедурное программирование, но с неймспейсами в виде объектов

[@FerelUltra]

@@grommaks примерно понял, спасибо!

[@artjomsfomenko757]

ставим лайк кто узнал C# конвертер

[@rexenpro2747]

не тыкай

[@grommaks]

🥲