SOLID ПРИНЦИПЫ простым языком (много примеров)

The thing is perfect well - годнота

👍👍👍👍👍

Оч и оч круто!
Дальше пойду смотреть про ооп!

Благодарю за проделанную работу тебя!

Внимательно изучил ролик. Очень здорово объяснил. Вспоминаю как когда то мне самому приходили идеи использовать принципы SOLID но деды сидели рядом и я боялся что с очередным пушом от меня буде создано слишком много классов)

Все понятно спасибо

Спасибо за видео, мало кто обладает такой подачей материала, при которой видео по сложной теме на 45 минут смотрится на одном дыхании, как если бы это было какое-то развлекательно-познавательное видео из Ютюба, где не нужно сильно мозги включать.

👏

По сути все SOLID принципы говорят примерно об одном и том же - создавай правильные абстракции и сущности и правильные связи между ними

Спасибо большое

Ни на кей кары ни на средний класс такие моторые не ставили 🤣🤣🤣 Аффтар надо высыпаться/выдыхать 😹😹😹

ооо, отображение через пропсы моя тема=))

Отличный видос!!! Отличная подача материала. Красавчег!!!

спасибо, вот ты реально толково всё пилишь. Дай тебе бог здоровья

Хороший ролик)

Спасибо большое, очень было полезно!

Спасибо очень доступно!

Гигантское спасибо за видео

отличное объяснение, большое спасибо!

очень круто делаете!! вы профессионал. спасибо. сколько вам лет? такой опыт уже большой у вас

About SINGLE RESPONSIBILITY you are wrong:

A module should have one, and only one, reason to change.

Software systems are changed to satisfy users and stakeholders; those users and
stakeholders are the “reason to change” that the principle is talking about. Indeed, we

can rephrase the principle to say this:

A module should be responsible to one, and only one, user or stakeholder.

Unfortunately, the words “user” and “stakeholder” aren’t really the right words to use
here. There will likely be more than one user or stakeholder who wants the system
changed in the same way. Instead, we’re really referring to a group—one or more
people who require that change. We’ll refer to that group as an actor.
Thus the final version of the SRP is:

A module should be responsible to one, and only one, actor.

so remake this video.

Благодарю за труды!

Когда речь идет про LSP очень путает определение "наследуемый"
Судя по всему вы имели в виду "наследующий", тот кто наследует, а не от кого наследуют (наследуемый)

Видео конечно старое и эта придирка душно выглядит, но все же это уже серьезная путаница в определении

1. Не стоит пытаться применить эти принципы сходу.
2. Таки Божественный объект не антипатерн, а точка отчета. Начинаем с него(если, конечно, не делали похожий код до этого и точно знаете какие объекты понадобятся) и дальше декомпозируем.

Спасибо, хорошее обьяснение

В конце аннимация креста, длинная перекладина желто-зелёный, а две короткие - красный и синий. Это по причине топологии 2RGB. Цвет соответственно кажется более насыщенным. Центральный кубик цвет неяркого серого, а количество кубиков 8, как бит в байте. Это даёт переход к однобайтному представлению цвета, что не совсем целесообразно. По серому цвету строится октаграмма неразличимого издалека цвета 2RGB, и возможно добавить ещё вариативности цветов засчёт контрольного зелёного. Прозрачный тессеракт таким образом включает четвертое измерение источников цвета - от зелёного луча до астрономического жёлтого. Синее и красное направление сохраняются, с учётом того, что красное перетекает в астрономически жёлтое и его избыток влияет на оценку размеров Солнца и самого тессеракта. Тень от источников усложняется с моделированием тени в зеркалах

Отличное и доходчивое изложение такой интересной и важной темы, спасибо за труд!!

Хочется верить, что метод "кушать" есть действительно у всех разработчиков)) аххахахахаххаха

Очень крутое объяснение!!! Лучше не нашел. Еще бы собесы онлайн проводил и цены не было б каналу)))

Очень хороший ролик. Спасибо большое!

если вспомнить видос про ооп, то получается что барбара лисков противоречит полиморфизму. Мы вообще не должны менять метод в дочернем классе, или у нас запрет только на его полный снос?

хочется патерны

для swift если override func someFunc() { super } дабы не оверайдить все что внутри тогда правило будет соблюдено .

Спасибо, теперь мне более понятна эта тема

Хороший видеоурок!!!

спасибо

Круто, спасибо!

огонь

В целом понятно, но сложно запомнить за что отвечает каждый из принципов. Потому что они все сливаются к одной методологии, разбиения на мелкие кирпичики и подставление как аргументы функции для наибольшего переиспользования в коде.

Спасибо большое! Читал книгу как-то, но понял значительно меньше из книги чем из этого небольшого ролика! Спасибо еще раз.

тимур, ты лучший!!

класс!

шЫкарно

но одного видео про солид явно не достаточно
расскажи больше о паттернах в целом
и еще раз про солид и как ты его исопльзуешь в реальных проектах
повторене мать учения так сказать

Я всегда ворчу, когда прилетают новые требования. Говорю: этого не было в ТЗ, теперь все переделывать. Но на самом деле, у меня хромает архитектура, стоит это признать 😢

👍👍👍

xorosho👍👍