Я ЧУДОМ не зная почти ничего стал Джуниором, сейчас смотрю на остальные вакансии и жёстко дристаю понимая что я почти нихера не знал и попал на работу :). Сейчас хочу выучить ВСЁ по требованиям, набрать коммерческого опыта и жить спокойно
Тема крутая. Однозначно лукас :) 6:27 стрелочная функция getPrice не возвращает цену (нет return) 10:51 какая цель иметь интерфес с геттерами для все моделей автомобилей. Только недавно на sOlid говорил же что ненадо так делать 10:50 Класс реализует интерфейс. Интерфейс может наследовать другой интерфейс... 12:00 Итого мы получили три независимых класса...хотя цель была разделить интерфейсы.. Условно если у нас есть API ядро, которое ожидало этот класс с тремя методами, то теперь такого больше нет... Результат должен был быть class Foo implements BarInterface, BazInterface, BazzzInterface { ... } При условии что при плохой архитектуре было class Foo implements FooInterface { ... } где FooInterface это сумма методов и свойст из BarInterface, BazInterface, BazzzInterface Все остальное мне понравилось, и примеры интересные
А в инверсии зависимостей так ли нужны два класса XmlHttpService и XmlHttpRequestService? Почему не реализовать один класс абстракцию с реализацией всего что нужно?
@@12345_qwerty Как я понимаю это был пример, который илюстрировал что зависимость от наследника - плохо. В супер классе могла быть логика, и могло быть еще несколько наследников...для примера все упрощено Однако с именами классов чересчур напутано...на то он и плохой пример, который нельзя делать в проекте :)
Наследовать машины от цены - это ООП курильщика ))) Они не являются ценами, они имеют цены. Соответственно грамотнее будет использовать композицию, или агрегацию вместо наследования :)
Это вполне нормальное решение, просто сделано чуть через жопу. В идеале создается интерфейс IPriceProcessable например, у него есть метод getPrice который и реализуется классом. Я правда хз, как с этим обстоят дела в TS.
Очень хорошая идея с данной рубрикой. Зачастую лень сидеть гуглить и разбираться в той или иной тематике (например, что такое REST, SOLID и тд) и хочется просто посмотреть короткий ролик. Будем ждать новых видео :)
Очень неплохо. OCP вроде немного не о том, этот принцип говорит о том, что некоторые модули, чье API используется другими, должны закрываться для изменения, чтобы не влиять на тех, кто его использует. LSP - это из области контрактного программирования, если по-простому, то наследники должны расширять базовый класс, а не сужать или изменять его. Кстати, если квадрат и прямоугольник будут неизменяемыми, то наследование возможно. Для понимания SRP неплохо прочитать про Low coupling/ High cohesion, т.к. SRP именно эти принципы пытается описать другими словами.
Спасибо, хорошое объяснение. В объяснении SOLID всегда возникает ряд неточностей, полный список примеров сложно привести. Главное чтобы люди улавливали суть, а еще лучше умели анализировать свой код на предмет нарушения и реализации SOLID
Да какой там ооп в реакте? Какой solid? Я уже забыл, когда использовал последний раз слово class в реакте, создавая компонент. Все на функциях и хуках. Не, из пальца там, наверное, можно что-то высосать и с умным лицом задвигать об этом, используя непонятные слова. Но на реальных проектах в реальном мире, - я вас умоляю.
6:32 надеюсь у вас опечатка. ф-я getPrice принимает только каталог машин, и во-первых, у нее нет аргумента определающего фильтр. во-вторых ф-я ничего не возвращает, просто в цикле вызывает геттер класса CarPrice. как к этому относиться?
Действительно крутые рекомендации. Смотрю и вижу свои будущие проблемы в коде. Сразу разведу и проблем не будет. Пока смотрел поймал себя на мысли, что теперь я пишу код так. Кто я после этого. Это же совершенно другой уровень. Спасибо Евгений за контент. Полюбому надо посмотреть еще пару раз и повторить руками.
Спасибо большое! Поскольку я не знаю языка, на котором были примеры, то понятными для меня оказались лишь первые два принципа. Но, и на этом большое спасибо!
Для демонстрации принцыпа подстановки Лисков используется крайне спорный пример, обсуждаемый во многих форумах. Главная претензия к этому примеру в том, что нельзя наследовать квадрат от прямоугольника так как они используют разные параметры. От сюда вытекает нарушение принцыпа Лисков, так как методы использующие прямоугольник не подходят (без модефикаций) к Квадрату
спаибо весьма позновательно. У меня вот вопрос по ' O ' , а можно ли считать реализацию декораторов в тс и native декоратор в жс реализацией данного пункта ?
Я не понял проблематику которая затрагивалась в примере принципа Барбары Лисков. У нас есть класс прямоугольника и класс квадрата, и если мы отдадим инстанс класса квадрата в функцию changeShapeSize. То как вообще интерфейс решит проблему того, что в квадрате будут меняться сразу и высота и ширина?
в чистом js нет понимания интерфейсов и абстракции. Typescript - это мощь, синтаксис учится буквально за пару дней, а с ним ООП станет намного понятнее и ближе
Подскажиье. 2 пригцип. Если не создавать интерфейс, а в класс ауто добавить ф-ю getPrice(), которая возвращала бы цену, заданую в конструкторе при создании new Auto(name, price). Это можно считать теми же я только в профиль, или есть ращница? Спасибо
Никак не въезжаю. То ли примеры такие подбирают везде дурацкие, то ли идея сама по себе непонятная, то ли я чего-то не понимаю. Из всех примеров, какие я встречал по всему интернету, я могу сделать только один вывод: принципы эти сводятся к тому, чтобы превратить простую парадигму класс-наследник-объекты в чрезмерно разветвлённую структуру из бесконечно растущего количества наследников, отличающихся порой только значениями свойств. Если кто-то реально использует эти принципы, приведите, пожалуйста, пару-тройку примеров, где и почему вы их используете?
самый лучший примеры для таких принципов слишком сложны для понимание к примеру исходные коды фреймворов Laravel и Symfony и они в открытом доступе, просто наследуешь базовой контроллер и твой контроллер превращается в супер мутант монстра который способен на все, аналогично работает все компоненты этих фреймворков
Спасибо большое за видео! Можно было бы разбить на короткие, но более подробные видео как с паттернами, но это все мои хотелки ... Ждем продолжения серии ! :)
Пример в Инверсии зависимостей был слишком сложными, прийшлось еще отдельно детально его разбирать, что бы понять что к чему. А так в целом, хороший видос, много полезного узнал. Спасибо.
У меня вопрос насчет принципа единственной ответственности (кстати, слова "единый" и "единственный" - паронимы, я бы не стал их взаимозаменять). Итак, "2:20 - итак принцип единой ответственности звучит он как у модуля должна быть только одна причина для изменения или класс должен отвечать только за что-то одно". А вот цитата из Роберта Мартина "Чистая архитектура": "Из всех принципов SOLID наиболее трудно понимаемым является прин цип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соот ветствующего сути. Услышав это название, многие программисты решают: оно означает, или класс должен отвечать только за что-то одно". Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы исполь зуем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID - это не принцип единственной ответственности." Тут возникает сразу несколько вопросов, и самый первый - кому же верить?
5:36 вообще не понимаю суть функции по всему циклу же не пройдет, на первом же єлементе попадет либо в case, которьій подходит, либо в default откуда сразу же return вообще не поняла смьісл
Принцип открытости и закрытости - тут нужно ловить баланс. Пример, изменился функционал цены, что лучше? Бегать по всем классам и изменять? Или, как в "неправильном примере", в одном классе в одной функции поменять. Очень сложный вопрос! Если функционал сложный и имеет множество условий в плоть до комбинаторики, то лучше разнести по классам. Если логика попроще, лучше запихнуть в один класс. Еще ошибка - решать данный принцип классами, а не структурой данных. В правильном примере зачем создавать кучу классов? Когда можно решить вопрос объектом содержащим все цены с ключами ссылками, при этом цикл гонять не надо {audi:{tradePrice:100, retailPrice:200}, bmw:{tradePrice:150, retailPrice:250}}. Ну и принцип O противоречит принципу S разбивая функциональность на несколько классов.
Я ж объяснил в самом начале, почему описанные подходы проблематично показывать на JS). Там везде только объекты, максимум класс. Ни абстракций, ни интерфейсов
4:00 и ещё переписать весь код, который работал со старым классом... 🎉 Вообще, твоё объяснение SOLID самое лучшее в русском сегменте... Видно, что ты знаешь о чем рассказываешь в отличие от дебила Серёжи немчинского, например... От меня лайк. Спасибо!
Спасибо за видио, с меня лайк. Если вы пишите в TS interface, вы ведь просто делаете описание данных, и когда создаете сущности показываете чему они должны соответствовать, в противном случае ts начнет ругаться. Не совсем понял почему мы имплементируемся в классах от интерфейса
Вы как раз описали почему) Интерфейсы это в первую очередь "описание интерфейса", и по класике их кроме как с классами и не использовать. Это в ts можно просто сказать, что какой-то объект имплементирует какой-то интерфейс
Получается класс Rectangle ( в примере принципа Барбары Лисков ) противоречит принципу единственной ответственности? Ведь у него как минимум 3 метода для изменения
И кстати это вполне нормальная ситуация когда сделав код по одному принципу, конфликтуешь с другим. Но в примере противоречия нет - все 3 метода работают с параметрами одной сущности и нет каких-то «левых» манипуляций
@@YauhenKavalchuk Спасибо за ответ! В этом случае непонятно тогда, в чем принцип единственной ответственности, если суть принципа: "Есть только один повод для изменения". Тогда нужно раскрыть более подробно принцип единственной ответственности. ( это не претензия, я не знаю как правильно, а наоборот пытаюсь понять )
Javascript динамически типизированный язык, и соответственно интерфейсы там не нужны / не реализуемы. Те цели которые достигаются посредством интерфейсов, а это лёгкое тестирование и другие о которых говорил автор, для JS не является проблемой. Динамическая природа JS одновременно и сила и слабость
@@GreyFoxTube То что интерфейсы в javascript не реализуемы - согласен, а то что не нужны - сомневаюсь. Наверно было бы неплохо знать набор интерфейсов, которым следует объект, чтобы точно знать, что в данном объекте необходимые методы точно реализованы и их можно вызывать. Например, если у этого объекта класса Car есть интерфейс "плавание", то значит инкапсулировано свойство герметичность и реализован и доступен метод плыть(). А если есть интерфейс "полёт" ...
@@andreygokhan6893, я лично согласен, что динамически типизированным языкам не хватает строгости. Но в целом, в индустрии разработки, где используются динамически типизированные языки, прибегают к соглашениям (конвенциям) в компании и частично обходятся линтерами. Без компиляторов и статических анализаторов, конечно, не так эффективно. Тем не менее работают
10:00 в коде ошибка, написано interface Figure { setWidth(width: number): void; setHeight(width: number):void; } А должно быть setHeight(height: number): void;
Принцип подстановки Барбары Лисков. Я бы изобразил абстракцию реализовав в ней метод расчета площади и от неё наследовался бы, реализуя метод установки ширины и высоты. Вопрос. Это же тоже сохраняет принцип подстановки. Нет?
Пример с квадратом считаю "высосанным из пальца"\некорректным В функции setWidth можно было сделать "пустое" тело, у функции setHeight сделать только this.height = height, а также переопределить функцию areaOf: areaOf() { return this.height * this.height} Тогда никаких ошибок бы не возникло
Женя, какие есть идеи по применению SOLID принципов относительно чистого JavaScript, а не TypeScript ? нет интерфейсов, есть прототипы, ну и классы как синтаксический сахар. Однако очень требуется SOLID )
У вас очень крутой канал, спасибо за ваш труд. У меня возник такой вопрос: В примере Open-closed, функция getPrice изначально выводила цену конкретного автомобиля, после применения на ней рефакторинга, метод стал выводить цены всех автомобилей, а как применить open-closed к задаче с выводом конкретной цены автомобиля?
В примере про общий интерфейс у фигуры не должно быть установки ширины и высоты, фигура может быть и окружность и треугольник. Там должен быть только метод получения площади.
6:24 почему нельзя сделать класс, в котором атрибутами объекта будут являться название и цена? Массив соответственно будет из инстансов этого класса. Функция будет забирать значение цены из атрибута
Интерфейс это особеность тайпскрипта ? Или и в ванильном джс есть ? Походу настал момент когда мне надо освоить тайпскрипт. А что такое лоу и хай модуль, как понять, что он лоу или хай. Или вся разница в том кто кого включает в себя ?
"L": не сразу понял, но потом дошло! совместимость это да, это правильно! гласное не нарушать при этом "S" (не штамповать "универсальных солдат" в коде)!
Принципы SOLID можно изучать вечно и каждый раз познавать что то новое, особенно когда применяешь часто на практике) Спасибо!
то чувство когда ты джун, тебе нужно знать все, зашел сюда, поставил лайк и решил, что на собесе скажу просто как это расшифровывается)
🤣
Сегодня на собеседовании слил этот вопрос) три тим лида ржали с меня
@@zakharkulbachenko3433 прошел собес?
@@DENDYTWOO видимо он умер
Я ЧУДОМ не зная почти ничего стал Джуниором, сейчас смотрю на остальные вакансии и жёстко дристаю понимая что я почти нихера не знал и попал на работу :). Сейчас хочу выучить ВСЁ по требованиям, набрать коммерческого опыта и жить спокойно
Спасибо за видео. Было бы прикольно посмотреть все эти принципы в функциональном программирование)
Пожалуйста
Евгений выражаю вам мою искреннюю благодарность за ваш труд! Как всегда все коротко, информативно, и разложенно по полочкам, лайк без вопросов!
Тема крутая. Однозначно лукас :)
6:27 стрелочная функция getPrice не возвращает цену (нет return)
10:51 какая цель иметь интерфес с геттерами для все моделей автомобилей. Только недавно на sOlid говорил же что ненадо так делать
10:50 Класс реализует интерфейс. Интерфейс может наследовать другой интерфейс...
12:00 Итого мы получили три независимых класса...хотя цель была разделить интерфейсы..
Условно если у нас есть API ядро, которое ожидало этот класс с тремя методами, то теперь такого больше нет...
Результат должен был быть
class Foo implements BarInterface, BazInterface, BazzzInterface { ... }
При условии что при плохой архитектуре было
class Foo implements FooInterface { ... }
где FooInterface это сумма методов и свойст из BarInterface, BazInterface, BazzzInterface
Все остальное мне понравилось, и примеры интересные
Спасибо за детальные объяснения нюансов!
А в инверсии зависимостей так ли нужны два класса XmlHttpService и XmlHttpRequestService? Почему не реализовать один класс абстракцию с реализацией всего что нужно?
@@12345_qwerty Как я понимаю это был пример, который илюстрировал что зависимость от наследника - плохо.
В супер классе могла быть логика, и могло быть еще несколько наследников...для примера все упрощено
Однако с именами классов чересчур напутано...на то он и плохой пример, который нельзя делать в проекте :)
Принцип инверсии зависимостей - хороший принцип, главное не увлекаться уровнями абстракций.
Отличное видео. Оно настолько минималистично, насколько это нужно, чтобы быть максимально понятным. Эталон. Спасибо.
Спасибо коллега, побольше такого контента и если можно расскажи про CI/CD
Это следующее видео в этом плейлисте, проверяй!
Особлива подяка за приклади на TS
👍
Принцип подстановки Барбары Лисков - хороший принцип. На практике, обычно, соблюдается сам собой. В голове держать надо.
Благодарю. Хорошее объяснение.
Всегда пожалуйста
Наследовать машины от цены - это ООП курильщика ))) Они не являются ценами, они имеют цены. Соответственно грамотнее будет использовать композицию, или агрегацию вместо наследования :)
а еще лучше , если это Typescript, добавить интерфейс/абстактный клас, который будет содержать метод getPrice.
@@dmytrokucheriavyi605 А этого в этом видео разве не делает автор?
Согласен. Пример с ценами крайне неудачный
Это вполне нормальное решение, просто сделано чуть через жопу. В идеале создается интерфейс IPriceProcessable например, у него есть метод getPrice который и реализуется классом. Я правда хз, как с этим обстоят дела в TS.
@@ИванКрасуля-г5ы в твоём случае ты о шарпе, так.
Спасибо! Может в будущих видео будет время рассказать о low, high level modules. Пока что нет четкого понятия. Супер что будут уроки по TypeScript!
Подумаю
Все здорово, но принцип Лисков не раскрыт, как и проблема квадрат прямоугольник. В вашем примере проблема осталась.
Подскажите где посмотреть более корректный пример?
@@АлександрКундрюков-и7с если найдешь скинь пожалуйста)
@@АлександрКундрюков-и7с ota-solid.now.sh/
ota-solid.now.sh/
Почему же осталась? Интерфейс создан, в каждом дочернем классе методы будут переопределены, и вызываться будет версия конкретного метода.
10:21 Сущности не должны зависеть от интерфейсов , которые они используют? Или которые не используют? Или которые они не используют?
сущности НЕ должны зависеть от интерфейсов, которые НЕ используют
спасибо)
Пожалуйста
огромное спасибо за видео! все по делу, понятно и без воды! очень благодарен!
Спасибо за отзыв)
Очень хорошая идея с данной рубрикой. Зачастую лень сидеть гуглить и разбираться в той или иной тематике (например, что такое REST, SOLID и тд) и хочется просто посмотреть короткий ролик. Будем ждать новых видео :)
Очень неплохо. OCP вроде немного не о том, этот принцип говорит о том, что некоторые модули, чье API используется другими, должны закрываться для изменения, чтобы не влиять на тех, кто его использует. LSP - это из области контрактного программирования, если по-простому, то наследники должны расширять базовый класс, а не сужать или изменять его. Кстати, если квадрат и прямоугольник будут неизменяемыми, то наследование возможно. Для понимания SRP неплохо прочитать про Low coupling/ High cohesion, т.к. SRP именно эти принципы пытается описать другими словами.
Спасибо за видео, отличное объяснение.
Пожалуйста)
Спасибо, хорошое объяснение. В объяснении SOLID всегда возникает ряд неточностей, полный список примеров сложно привести. Главное чтобы люди улавливали суть, а еще лучше умели анализировать свой код на предмет нарушения и реализации SOLID
Спасибо за отзыв)
Спасибо за полезное видео. Интересно также увидеть как можно реально применить принципы solid в проекте например на react.
Да какой там ооп в реакте? Какой solid? Я уже забыл, когда использовал последний раз слово class в реакте, создавая компонент. Все на функциях и хуках.
Не, из пальца там, наверное, можно что-то высосать и с умным лицом задвигать об этом, используя непонятные слова.
Но на реальных проектах в реальном мире, - я вас умоляю.
6:32 надеюсь у вас опечатка. ф-я getPrice принимает только каталог машин, и во-первых, у нее нет аргумента определающего фильтр. во-вторых ф-я ничего не возвращает, просто в цикле вызывает геттер класса CarPrice. как к этому относиться?
🤔
Мужик, очень здорово объяснил. Чудесная подача материала, ты большой молодец, продолжай в том же духе)
Успехов!
Спасибо большое
Действительно крутые рекомендации.
Смотрю и вижу свои будущие проблемы в коде. Сразу разведу и проблем не будет.
Пока смотрел поймал себя на мысли, что теперь я пишу код так. Кто я после этого. Это же совершенно другой уровень. Спасибо Евгений за контент.
Полюбому надо посмотреть еще пару раз и повторить руками.
Спасибо большое за отзыв
Спасибо большое! Поскольку я не знаю языка, на котором были примеры, то понятными для меня оказались лишь первые два принципа. Но, и на этом большое спасибо!
Пожалуйста. Язык TypeScript - он просто добавляет типизацию
Отличное видео, вкратце и понятно, но думаю разрабам с низким уровнем будет сложновато, и возможно стоит посмотреть более подробный разбор принципов
👍
Для демонстрации принцыпа подстановки Лисков используется крайне спорный пример, обсуждаемый во многих форумах. Главная претензия к этому примеру в том, что нельзя наследовать квадрат от прямоугольника так как они используют разные параметры. От сюда вытекает нарушение принцыпа Лисков, так как методы использующие прямоугольник не подходят (без модефикаций) к Квадрату
¯\_(ツ)_/¯
спаибо весьма позновательно. У меня вот вопрос по ' O ' , а можно ли считать реализацию декораторов в тс и native декоратор в жс реализацией данного пункта ?
Я скажу так, по описанию похоже, но концептуально немного другое
Супер! Много читал/смотрел из разных источников. И мало что понимал. Теперь почти всё понял. Спасибо!)
Очень качественное обьяснение спасибо огромное !!!)))
Пожалуйста!
Спасибо, очень коротко, доступно и понятно
Пожалуйста)
Классное видео! Спасибо за работу!
Пожалуйста
Я не понял проблематику которая затрагивалась в примере принципа Барбары Лисков.
У нас есть класс прямоугольника и класс квадрата, и если мы отдадим инстанс класса квадрата в функцию changeShapeSize. То как вообще интерфейс решит проблему того, что в квадрате будут меняться сразу и высота и ширина?
Идеально понятное объяснение принципа SOLID, оргомнейший лайкос !!!
Спасибо
Супер , я вообще не знал что есть такие понятия. Случайно наткнулся та это видео. Спасибо большое))
Ничего не понятно, но очень интересно. Видимо я один тут плохо понимаю объяснение. Судя по всему надо ООП в js хорошо знать.
OOP в JS? :D
в чистом js нет понимания интерфейсов и абстракции. Typescript - это мощь, синтаксис учится буквально за пару дней, а с ним ООП станет намного понятнее и ближе
Подскажиье. 2 пригцип. Если не создавать интерфейс, а в класс ауто добавить ф-ю getPrice(), которая возвращала бы цену, заданую в конструкторе при создании new Auto(name, price). Это можно считать теми же я только в профиль, или есть ращница? Спасибо
Ну по сути можно, но это уже нарушает принцип ООП об абстракции
Просто и понятно, супер пояснение, спасибо!
Пожалуйста)
SOLID противоречит KISS
и как их совместить?
Никак. Различные принципа - это лишь рекомендации, которые периодически могут противоречить. Всё не применить)
Спасибо за Ваш труд! Жду с нетерпением следующее видео!
Никак не въезжаю. То ли примеры такие подбирают везде дурацкие, то ли идея сама по себе непонятная, то ли я чего-то не понимаю.
Из всех примеров, какие я встречал по всему интернету, я могу сделать только один вывод: принципы эти сводятся к тому, чтобы превратить простую парадигму класс-наследник-объекты в чрезмерно разветвлённую структуру из бесконечно растущего количества наследников, отличающихся порой только значениями свойств.
Если кто-то реально использует эти принципы, приведите, пожалуйста, пару-тройку примеров, где и почему вы их используете?
самый лучший примеры для таких принципов слишком сложны для понимание к примеру исходные коды фреймворов Laravel и Symfony и они в открытом доступе, просто наследуешь базовой контроллер и твой контроллер превращается в супер мутант монстра который способен на все, аналогично работает все компоненты этих фреймворков
Отлично объяснил. Спасибо!
Пожалуйста
Хорошее объяснение. Не зная тайп скрипт я даже всё понял. Про OCP только поверхностно. Как расширять классы не рассказал
Спасибо, всё предельно понятно)
Пожалуйста
Спасибо тебе друже! Очень рад что нашел твой канал хотя не часто захожу сюда и как вижу зря!
Спасибо за классный разбор принципов SOLID
Спасибо за отзыв
Спасибо большое за видео!
Можно было бы разбить на короткие, но более подробные видео как с паттернами, но это все мои хотелки ...
Ждем продолжения серии ! :)
"Реально хочу надеяться..." клевый оборот речи
🤣
Отличное объяснение, хоть и с нюансами некоторыми) спасибо, жду ещё видео такого формата
Понравилось, спасибо! Лисков немного подкачал.... палец вверх!
за теслу лайк) А объяснение очень компатное и понятное, спасибо)
Спасибо
Супер
Коротко и ясно
Спасибо
Zdorovo!
Tol'ko u menya voprosov stalo bol'she?
¯\_(ツ)_/¯
Принцыпы сухпайка)
?
действительно просто, подписчиков мало
ещё бы разобрать grasp и gof
Нормально подписчиков для it канала, очень хороший результат
Готовлюсь к собеседованию и такие видео очень сильно помогают огромное спасибо
Пожалуйста
А зачем на скриншоты листингов приклеен какой-то светофорчик вверху?
Для красоты
@@YauhenKavalchuk да, красота требует жертв.
Отличный и понятный ролик
Невероятно !! )
👍
Как раз то, что искал - спасибо!
Пример в Инверсии зависимостей был слишком сложными, прийшлось еще отдельно детально его разбирать, что бы понять что к чему.
А так в целом, хороший видос, много полезного узнал. Спасибо.
Пожалуйста
Предлагаю тему к следующему видео: Просто о шаблоне MVC
👍 ну да, как вариант
У меня вопрос насчет принципа единственной ответственности (кстати, слова "единый" и "единственный" - паронимы, я бы не стал их взаимозаменять).
Итак,
"2:20 - итак принцип единой ответственности звучит он как у модуля должна быть только одна причина для изменения или класс должен отвечать только за что-то одно".
А вот цитата из Роберта Мартина "Чистая архитектура":
"Из всех принципов SOLID наиболее трудно понимаемым является прин цип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соот ветствующего сути. Услышав это название, многие программисты решают: оно означает, или класс должен отвечать только за что-то одно".
Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы исполь зуем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID - это не принцип единственной ответственности."
Тут возникает сразу несколько вопросов, и самый первый - кому же верить?
Классно объяснил! Спасибо. Все очень понятно. Зачот!
Почему в примиере Лисков не использовать абстрактный класс для фигур?
Решил не усложнять дополнительной абстракцией
5:36 вообще не понимаю суть функции
по всему циклу же не пройдет, на первом же єлементе попадет либо в case, которьій подходит, либо в default
откуда сразу же return
вообще не поняла смьісл
Принцип открытости и закрытости - тут нужно ловить баланс. Пример, изменился функционал цены, что лучше? Бегать по всем классам и изменять? Или, как в "неправильном примере", в одном классе в одной функции поменять. Очень сложный вопрос! Если функционал сложный и имеет множество условий в плоть до комбинаторики, то лучше разнести по классам. Если логика попроще, лучше запихнуть в один класс. Еще ошибка - решать данный принцип классами, а не структурой данных. В правильном примере зачем создавать кучу классов? Когда можно решить вопрос объектом содержащим все цены с ключами ссылками, при этом цикл гонять не надо {audi:{tradePrice:100, retailPrice:200}, bmw:{tradePrice:150, retailPrice:250}}. Ну и принцип O противоречит принципу S разбивая функциональность на несколько классов.
Спасибо огромное!
Пожалуйста
Спасибо, интересно послушать о solid с примерами на родном js)
Я ж объяснил в самом начале, почему описанные подходы проблематично показывать на JS). Там везде только объекты, максимум класс. Ни абстракций, ни интерфейсов
@@YauhenKavalchuk , имел ввиду typescript, конечно. Спасибо, что поправили
4:00 и ещё переписать весь код, который работал со старым классом... 🎉
Вообще, твоё объяснение SOLID самое лучшее в русском сегменте... Видно, что ты знаешь о чем рассказываешь в отличие от дебила Серёжи немчинского, например... От меня лайк. Спасибо!
Спасибо большое за отзыв
Спасибо! Полезная информация!
А что за музыка на фоне в начале?
Уже не помню, что-то из медиатеки UA-cam
@@YauhenKavalchuk 😢
Спасибо за видио, с меня лайк.
Если вы пишите в TS interface, вы ведь просто делаете описание данных, и когда создаете сущности показываете чему они должны соответствовать, в противном случае ts начнет ругаться. Не совсем понял почему мы имплементируемся в классах от интерфейса
Вы как раз описали почему)
Интерфейсы это в первую очередь "описание интерфейса", и по класике их кроме как с классами и не использовать. Это в ts можно просто сказать, что какой-то объект имплементирует какой-то интерфейс
Получается класс Rectangle ( в примере принципа Барбары Лисков ) противоречит принципу единственной ответственности? Ведь у него как минимум 3 метода для изменения
И кстати это вполне нормальная ситуация когда сделав код по одному принципу, конфликтуешь с другим. Но в примере противоречия нет - все 3 метода работают с параметрами одной сущности и нет каких-то «левых» манипуляций
@@YauhenKavalchuk Спасибо за ответ!
В этом случае непонятно тогда, в чем принцип единственной ответственности, если суть принципа: "Есть только один повод для изменения". Тогда нужно раскрыть более подробно принцип единственной ответственности.
( это не претензия, я не знаю как правильно, а наоборот пытаюсь понять )
А вот по принципу Single Responsibility, сколько методов может содержать класс?
Сколько угодно, ограничений нет. Главное что-бы класться отвечал за что-то одно
13:08 прошупрощения, не понимаю почему в параметры конструктура передается интерфейс с модификатором private
kendaleiv.com/typescript-constructor-assignment-public-and-private-keywords/
Про grasp ещё можно рассказать
👍
👍
👍
А в javascript есть что-то похожее на interface и implement или есть какой-то способ их имитации?
Нет. В JS это всё классы
Javascript динамически типизированный язык, и соответственно интерфейсы там не нужны / не реализуемы. Те цели которые достигаются посредством интерфейсов, а это лёгкое тестирование и другие о которых говорил автор, для JS не является проблемой. Динамическая природа JS одновременно и сила и слабость
@@GreyFoxTube То что интерфейсы в javascript не реализуемы - согласен, а то что не нужны - сомневаюсь. Наверно было бы неплохо знать набор интерфейсов, которым следует объект, чтобы точно знать, что в данном объекте необходимые методы точно реализованы и их можно вызывать. Например, если у этого объекта класса Car есть интерфейс "плавание", то значит инкапсулировано свойство герметичность и реализован и доступен метод плыть(). А если есть интерфейс "полёт" ...
@@andreygokhan6893, я лично согласен, что динамически типизированным языкам не хватает строгости. Но в целом, в индустрии разработки, где используются динамически типизированные языки, прибегают к соглашениям (конвенциям) в компании и частично обходятся линтерами. Без компиляторов и статических анализаторов, конечно, не так эффективно. Тем не менее работают
И все таки спасибо мне как раз для собеседования и нужно было хоть какое то представление иметь))
10:00 в коде ошибка, написано
interface Figure {
setWidth(width: number): void;
setHeight(width: number):void;
}
А должно быть setHeight(height: number): void;
Да, пропустил( Исправлю в репозитории
Вроде все так знакомо, но синтаксис какой-то непонятный ... не C++ ли это часом?
TypeScript
Принцип подстановки Барбары Лисков.
Я бы изобразил абстракцию реализовав в ней метод расчета площади и от неё наследовался бы, реализуя метод установки ширины и высоты.
Вопрос. Это же тоже сохраняет принцип подстановки. Нет?
Если я правильно понял описание, то нет
Спасибо за видео
Пожалуйста
Пример с квадратом считаю "высосанным из пальца"\некорректным
В функции setWidth можно было сделать "пустое" тело, у функции setHeight сделать только this.height = height, а также переопределить функцию areaOf: areaOf() { return this.height * this.height}
Тогда никаких ошибок бы не возникло
Возможно… но это самый распространённый пример
Вот вроде бы понимаю все, но при написании программы не могу применять этот ООП, выходит процедурный способ всегда
🤔🤷♂️
Дякую
Пожалуйста
Женя, какие есть идеи по применению SOLID принципов относительно чистого JavaScript, а не TypeScript ? нет интерфейсов, есть прототипы, ну и классы как синтаксический сахар. Однако очень требуется SOLID )
Ну нет интерфейсов, это не проблема. Используйте всё с классами)
В Liskov subtitution подразумевается же, что класс-наследник не должен менять при переопределении поведение метода родительского класса
Спасибо, очень круто, думаю на repeat будет долго))) про ооп было бы тоже не плохо в таком формате:) огромное спасибо!
Круто, спасибо за видео
это typescript?
Да
У вас очень крутой канал, спасибо за ваш труд.
У меня возник такой вопрос: В примере Open-closed, функция getPrice изначально выводила цену конкретного автомобиля, после применения на ней рефакторинга, метод стал выводить цены всех автомобилей, а как применить open-closed к задаче с выводом конкретной цены автомобиля?
А зачем вам тогда функция? У вас есть класс, который уже отдаёт цену
В примере про общий интерфейс у фигуры не должно быть установки ширины и высоты, фигура может быть и окружность и треугольник. Там должен быть только метод получения площади.
👍
6:24 почему нельзя сделать класс, в котором атрибутами объекта будут являться название и цена? Массив соответственно будет из инстансов этого класса. Функция будет забирать значение цены из атрибута
11:53 проще сделать AutoSet с единственным методом set()
🤔
Класс для каждого типа авто? Даже не знаю, стоит ли дальше смотреть...
Интерфейс это особеность тайпскрипта ? Или и в ванильном джс есть ? Походу настал момент когда мне надо освоить тайпскрипт. А что такое лоу и хай модуль, как понять, что он лоу или хай. Или вся разница в том кто кого включает в себя ?
Интерфейсов в JS нету.
"L": не сразу понял, но потом дошло! совместимость это да, это правильно! гласное не нарушать при этом "S" (не штамповать "универсальных солдат" в коде)!
👍