Изучал все принципы SOLID, но никак не мог понять, последний принцип, из-за его определения, смотрел видосы разных авторов, но так пояснять, это талант, спасибо всё сразу стало на свои места)
смотреть видео с терминами и сложными схемами🥵 смотреть видео где программист матерится на код😎😎😎 ну а говоря на самом деле, мне нравится такой подход к объяснению, ощущается не как нудная пара, а как будет с другом под пивко обсуждаю что нарыл в интернетах
Инъекцию удобно пояснять на примере уведомлений. покупка была, или форму отправили - надо отправить уведомление. Чтобы внутри контроллера не создавать отправку почты на конкретный сервер - передаём объект Нотификашн. А этот нотификейшн модет почту отправить через мейлчимп или печкина. А потом ещё и в телегу сможет научиться. При этом сам код Заказа или Формы вообще не трогаешь. Ну, в идеале, конечно
Надо бы привести примеры, которые часто попадаются в кейсах например финансовые транзакции или уж тогда простую html игру запилить. Чем голову делать с треугольниками, которые "в почти" любом api проекте просто не нужны.
Здравствуй. Слушай, ну как я понимаю принцип подстановки Лисков, так дело тут в том, что, если в коде мы используем Animal, то при подстановки туда Bird, наследника Animal, код не должен сломаться и мы должны получить ожидаемое поведение. Ну и желательно это всё делать через контракты, через интерфейсы. Например. Давайте сделаем вместо метода walk - move. И в случае move у Animal - мы переключаем свойство walking на true. А у Bird мы переписываем метод move и в нем меняется flying на true, а walking не трогается. Как я понимаю - вот это и есть то самое нарушение принципа. Да, и там и там move, но логика разная и получается разное поведение. Но не факт, что мое видение - правильное. Я сам только это всё изучаю и не зашел бы на этот ролик если был бы уверен во всем)
Скорее наоборот. При подстановке родителя вместо наследника код не должен ломаться, т.к. наследники должны расширять класс и не изменять уже то, что есть. "Подтипы должны быть заменяемы на своих базовые типы" @Р. Мартин
А как родитель будет заменять ребенка? Допустим у нас есть Animal и Bird (extends Animal). Animal имеет метод walk (vector: Vector); Bird имеет дополнительно метод fly (vector: Vector, altitude: number); Допустим у нас есть функция takeAFlight(bird: Bird, vector: Vector, altitude: number); Функция вызывает bird.fly(vector, altitude); Каким образом любой Animal может заменить Bird в этом примере? Ведь у Animal нету метода fly. Замена будет возможна только в случае того, если Bird является полностью копией Animal. В чем тогда смысл? Но если мы имеем функцию takeAWalk(animal: Animal, vector: Vector); Функция вызывает animal.walk(vector); То мы можем подставить вместо Animal любой экземпляр класса или интерфейса который соответствует контракту. Например Bird. И тут, как я понимаю, в этом и принцип, что мы не переписываем методы, мы только дополняем. Из-за чего мы можем подставлять любые подтипы вместо их родителей. Нарушением принципа будет переписать метод walk у Bird, например на walk(vector: Vector, speed: number). Тогда мы не можем передать в takeAWalk Bird. Ну или перепишем логику внутри так, что класс будет вести себя иначе и из-за чего появятся ошибки. @@darkspace6089
@@VanyaMate понятное дело, что родитель не сможет выполнить новые методы наследника, потому что просто о них не знает. Речь идёт о тех методах, которые известны обоим. Родитель обладает им, наследник его не меняет. В итоге в коде кого хочешь ставь - метод всё равно сработает одинаково
![Gunna - HIM ALL ALONG [Official Video]](http://i.ytimg.com/vi/w7Wf0h1Q8a4/mqdefault.jpg)
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
А стоп, это другой канал
Изучал все принципы SOLID, но никак не мог понять, последний принцип, из-за его определения, смотрел видосы разных авторов, но так пояснять, это талант, спасибо всё сразу стало на свои места)
Такое ощущение, что ремонтяш решил рассказать за программирование :)
Ремонтяш клёвый, спасеба)
смотреть видео с терминами и сложными схемами🥵
смотреть видео где программист матерится на код😎😎😎
ну а говоря на самом деле, мне нравится такой подход к объяснению,
ощущается не как нудная пара, а как будет с другом под пивко обсуждаю что нарыл в интернетах
Лампово загоняешь спасибо
подход в объяснении топ, супер что примеры на каждый принцип были, лойс
братан вперед вперед, контент в кайф можно вот этого вот почаще!))))
Посеба, постараюсь)
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Накидайте клувней этому господину
Спасибо за поддержку)
Инъекцию удобно пояснять на примере уведомлений. покупка была, или форму отправили - надо отправить уведомление.
Чтобы внутри контроллера не создавать отправку почты на конкретный сервер - передаём объект Нотификашн. А этот нотификейшн модет почту отправить через мейлчимп или печкина. А потом ещё и в телегу сможет научиться.
При этом сам код Заказа или Формы вообще не трогаешь. Ну, в идеале, конечно
Обмазывание интерфейсами - это ад. Стала тьма кода, разобраться сложнее. Очень умеренно надо это использовать.
Ну да, это просто ещё один инструмент)
Снова годнота, спасибо за твое существование)
Блен, спасибо)
0:34 "общепринятое дерьмо" этим всё сказано. Зачем делать видео на 15минут?
Общепринятое - не равно общеизвестное)
нормас, подписка)))
Надо бы привести примеры, которые часто попадаются в кейсах например финансовые транзакции или уж тогда простую html игру запилить. Чем голову делать с треугольниками, которые "в почти" любом api проекте просто не нужны.
Я не стал заморачиваться, поискал самые простые примеры, которые отображают суть
Здравствуй. Слушай, ну как я понимаю принцип подстановки Лисков, так дело тут в том, что, если в коде мы используем Animal, то при подстановки туда Bird, наследника Animal, код не должен сломаться и мы должны получить ожидаемое поведение. Ну и желательно это всё делать через контракты, через интерфейсы.
Например. Давайте сделаем вместо метода walk - move. И в случае move у Animal - мы переключаем свойство walking на true. А у Bird мы переписываем метод move и в нем меняется flying на true, а walking не трогается. Как я понимаю - вот это и есть то самое нарушение принципа. Да, и там и там move, но логика разная и получается разное поведение.
Но не факт, что мое видение - правильное. Я сам только это всё изучаю и не зашел бы на этот ролик если был бы уверен во всем)
Да, я это и пытался сказать, но косноязычие не позволило)
Скорее наоборот. При подстановке родителя вместо наследника код не должен ломаться, т.к. наследники должны расширять класс и не изменять уже то, что есть.
"Подтипы должны быть заменяемы на своих базовые типы" @Р. Мартин
Спс, я оставлю на всякий ссылку на подробную статью именно по этому принципу habr.com/ru/articles/83269/
А как родитель будет заменять ребенка?
Допустим у нас есть Animal и Bird (extends Animal).
Animal имеет метод walk (vector: Vector);
Bird имеет дополнительно метод fly (vector: Vector, altitude: number);
Допустим у нас есть функция takeAFlight(bird: Bird, vector: Vector, altitude: number);
Функция вызывает bird.fly(vector, altitude);
Каким образом любой Animal может заменить Bird в этом примере?
Ведь у Animal нету метода fly.
Замена будет возможна только в случае того, если Bird является полностью копией Animal. В чем тогда смысл?
Но если мы имеем функцию takeAWalk(animal: Animal, vector: Vector);
Функция вызывает animal.walk(vector);
То мы можем подставить вместо Animal любой экземпляр класса или интерфейса который соответствует контракту. Например Bird.
И тут, как я понимаю, в этом и принцип, что мы не переписываем методы, мы только дополняем. Из-за чего мы можем подставлять любые подтипы вместо их родителей.
Нарушением принципа будет переписать метод walk у Bird, например на walk(vector: Vector, speed: number).
Тогда мы не можем передать в takeAWalk Bird. Ну или перепишем логику внутри так, что класс будет вести себя иначе и из-за чего появятся ошибки.
@@darkspace6089
@@VanyaMate понятное дело, что родитель не сможет выполнить новые методы наследника, потому что просто о них не знает. Речь идёт о тех методах, которые известны обоим. Родитель обладает им, наследник его не меняет. В итоге в коде кого хочешь ставь - метод всё равно сработает одинаково
2:01 Метод валидации мейла вобще-то может относится к Персоне - если персона проверряет емейлы
Так можно что угодно связать. Метод подключения к БД может относиться к person - если person подключается к БД. Так что ли?)
@@bidlocode Вполне)
Понял тебя)
Пхп когда будет?
Я думаю никогда 🙅
Чувак, а у тебя уроки брать можно? Я бы без задней мысли взял бы у тебя пару платных уроков. Так понятно мне ещё никто не объяснял
Заходи в телегу да спрашивай, мы там бесплатно поможем чем можем)
Еще раз извинишься 8:57 за отрыжку - отпишусь, нах)
XD
Ты первый кого я увидел, кто в 2023 писали на var.
Примеры взяты из интернета, главное чтобы было понятно
@@bidlocode, ок не знал.