Просто о SOLID (Принципы SOLID)

[@alexandrkruglyak]

Принципы SOLID можно изучать вечно и каждый раз познавать что то новое, особенно когда применяешь часто на практике) Спасибо!

[@pavloskuibida6292]

то чувство когда ты джун, тебе нужно знать все, зашел сюда, поставил лайк и решил, что на собесе скажу просто как это расшифровывается)

[@YauhenKavalchuk]

🤣

[@zakharkulbachenko3433]

Сегодня на собеседовании слил этот вопрос) три тим лида ржали с меня

[@DENDYTWOO]

@@zakharkulbachenko3433 прошел собес?

[@extrageniuz]

@@DENDYTWOO видимо он умер

[@immortal_lnight]

Я ЧУДОМ не зная почти ничего стал Джуниором, сейчас смотрю на остальные вакансии и жёстко дристаю понимая что я почти нихера не знал и попал на работу :). Сейчас хочу выучить ВСЁ по требованиям, набрать коммерческого опыта и жить спокойно

[@АлексейЕфимов-к4о]

Евгений выражаю вам мою искреннюю благодарность за ваш труд! Как всегда все коротко, информативно, и разложенно по полочкам, лайк без вопросов!

[@sea-lucky7143]

Спасибо за видео. Было бы прикольно посмотреть все эти принципы в функциональном программирование)

[@YauhenKavalchuk]

Пожалуйста

[@grommaks]

Тема крутая. Однозначно лукас :) 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 Все остальное мне понравилось, и примеры интересные

[@YauhenKavalchuk]

Спасибо за детальные объяснения нюансов!

[@12345_qwerty]

А в инверсии зависимостей так ли нужны два класса XmlHttpService и XmlHttpRequestService? Почему не реализовать один класс абстракцию с реализацией всего что нужно?

[@grommaks]

@@12345_qwerty Как я понимаю это был пример, который илюстрировал что зависимость от наследника - плохо. В супер классе могла быть логика, и могло быть еще несколько наследников...для примера все упрощено Однако с именами классов чересчур напутано...на то он и плохой пример, который нельзя делать в проекте :)

[@dmitryfokin5205]

Принцип инверсии зависимостей - хороший принцип, главное не увлекаться уровнями абстракций.

[@СергейК-б9е]

Спасибо коллега, побольше такого контента и если можно расскажи про CI/CD

[@YauhenKavalchuk]

Это следующее видео в этом плейлисте, проверяй!

[@ЕгорФедоренко-с2щ]

Отличное видео. Оно настолько минималистично, насколько это нужно, чтобы быть максимально понятным. Эталон. Спасибо.

[@dmitryfokin5205]

Принцип подстановки Барбары Лисков - хороший принцип. На практике, обычно, соблюдается сам собой. В голове держать надо.

[@Cleannetcode]

Спасибо, хорошое объяснение. В объяснении SOLID всегда возникает ряд неточностей, полный список примеров сложно привести. Главное чтобы люди улавливали суть, а еще лучше умели анализировать свой код на предмет нарушения и реализации SOLID

[@YauhenKavalchuk]

Спасибо за отзыв)

[@Demasification]

Спасибо! Может в будущих видео будет время рассказать о low, high level modules. Пока что нет четкого понятия. Супер что будут уроки по TypeScript!

[@YauhenKavalchuk]

Подумаю

[@quieteroks]

Все здорово, но принцип Лисков не раскрыт, как и проблема квадрат прямоугольник. В вашем примере проблема осталась.

[@АлександрКундрюков-и7с]

Подскажите где посмотреть более корректный пример?

[@MOLOKOKEFIR]

@@АлександрКундрюков-и7с если найдешь скинь пожалуйста)

[@artemtereza669]

@@АлександрКундрюков-и7с ota-solid.now.sh/

[@artemtereza669]

ota-solid.now.sh/

[@justasid001]

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

[@eugenekuzmin4825]

Особлива подяка за приклади на TS

[@YauhenKavalchuk]

👍

[@alex330k47]

Для демонстрации принцыпа подстановки Лисков используется крайне спорный пример, обсуждаемый во многих форумах. Главная претензия к этому примеру в том, что нельзя наследовать квадрат от прямоугольника так как они используют разные параметры. От сюда вытекает нарушение принцыпа Лисков, так как методы использующие прямоугольник не подходят (без модефикаций) к Квадрату

[@YauhenKavalchuk]

¯\_(ツ)_/¯

[@256b]

Благодарю. Хорошее объяснение.

[@YauhenKavalchuk]

Всегда пожалуйста

[@denisklyachenko292]

Очень неплохо. OCP вроде немного не о том, этот принцип говорит о том, что некоторые модули, чье API используется другими, должны закрываться для изменения, чтобы не влиять на тех, кто его использует. LSP - это из области контрактного программирования, если по-простому, то наследники должны расширять базовый класс, а не сужать или изменять его. Кстати, если квадрат и прямоугольник будут неизменяемыми, то наследование возможно. Для понимания SRP неплохо прочитать про Low coupling/ High cohesion, т.к. SRP именно эти принципы пытается описать другими словами.

[@eugeniuszjarocki109]

Очень хорошая идея с данной рубрикой. Зачастую лень сидеть гуглить и разбираться в той или иной тематике (например, что такое REST, SOLID и тд) и хочется просто посмотреть короткий ролик. Будем ждать новых видео :)

[@albertrain7093]

Наследовать машины от цены - это ООП курильщика ))) Они не являются ценами, они имеют цены. Соответственно грамотнее будет использовать композицию, или агрегацию вместо наследования :)

[@dmytrokucheriavyi605]

а еще лучше , если это Typescript, добавить интерфейс/абстактный клас, который будет содержать метод getPrice.

[@Skyfauer]

@@dmytrokucheriavyi605 А этого в этом видео разве не делает автор?

[@alexeybobr4537]

Согласен. Пример с ценами крайне неудачный

[@ИванКрасуля-г5ы]

Это вполне нормальное решение, просто сделано чуть через жопу. В идеале создается интерфейс IPriceProcessable например, у него есть метод getPrice который и реализуется классом. Я правда хз, как с этим обстоят дела в TS.

[@NonAmericanFood]

@@ИванКрасуля-г5ы в твоём случае ты о шарпе, так.

[@ВасилийВасильев-ш4т]

10:21 Сущности не должны зависеть от интерфейсов , которые они используют? Или которые не используют? Или которые они не используют?

[@YauhenKavalchuk]

сущности НЕ должны зависеть от интерфейсов, которые НЕ используют

[@O_Hat]

Действительно крутые рекомендации. Смотрю и вижу свои будущие проблемы в коде. Сразу разведу и проблем не будет. Пока смотрел поймал себя на мысли, что теперь я пишу код так. Кто я после этого. Это же совершенно другой уровень. Спасибо Евгений за контент. Полюбому надо посмотреть еще пару раз и повторить руками.

[@YauhenKavalchuk]

Спасибо большое за отзыв

[@РоманКазаченко-ю4ю]

Мужик, очень здорово объяснил. Чудесная подача материала, ты большой молодец, продолжай в том же духе) Успехов!

[@YauhenKavalchuk]

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

[@ЯрославВапничний]

Спасибо за полезное видео. Интересно также увидеть как можно реально применить принципы solid в проекте например на react.

[@user-vk6te2eb4p]

Да какой там ооп в реакте? Какой solid? Я уже забыл, когда использовал последний раз слово class в реакте, создавая компонент. Все на функциях и хуках. Не, из пальца там, наверное, можно что-то высосать и с умным лицом задвигать об этом, используя непонятные слова. Но на реальных проектах в реальном мире, - я вас умоляю.

[@CrueL54]

Спасибо за видео, отличное объяснение.

[@YauhenKavalchuk]

Пожалуйста)

[@sanzharabdurahmanov5082]

Идеально понятное объяснение принципа SOLID, оргомнейший лайкос !!!

[@YauhenKavalchuk]

Спасибо

[@Gelen794]

Я не понял проблематику которая затрагивалась в примере принципа Барбары Лисков. У нас есть класс прямоугольника и класс квадрата, и если мы отдадим инстанс класса квадрата в функцию changeShapeSize. То как вообще интерфейс решит проблему того, что в квадрате будут меняться сразу и высота и ширина?

[@dmytrolambru2984]

Спасибо большое за видео! Можно было бы разбить на короткие, но более подробные видео как с паттернами, но это все мои хотелки ... Ждем продолжения серии ! :)

[@sergiopuccini]

"Реально хочу надеяться..." клевый оборот речи

[@YauhenKavalchuk]

🤣

[@ЕрвандАгаджанян-в3к]

Спасибо большое! Поскольку я не знаю языка, на котором были примеры, то понятными для меня оказались лишь первые два принципа. Но, и на этом большое спасибо!

[@YauhenKavalchuk]

Пожалуйста. Язык TypeScript - он просто добавляет типизацию

[@temirlanalmassov9408]

Отличное видео, вкратце и понятно, но думаю разрабам с низким уровнем будет сложновато, и возможно стоит посмотреть более подробный разбор принципов

[@YauhenKavalchuk]

👍

[@SochnayaShaurma]

Ничего не понятно, но очень интересно. Видимо я один тут плохо понимаю объяснение. Судя по всему надо ООП в js хорошо знать.

[@alexandertarasenko3038]

OOP в JS? :D

[@andriikrashivskiy7140]

в чистом js нет понимания интерфейсов и абстракции. Typescript - это мощь, синтаксис учится буквально за пару дней, а с ним ООП станет намного понятнее и ближе

[@alex330k47]

10:00 в коде ошибка, написано interface Figure { setWidth(width: number): void; setHeight(width: number):void; } А должно быть setHeight(height: number): void;

[@YauhenKavalchuk]

Да, пропустил( Исправлю в репозитории

[@vskovzgird]

Хорошее объяснение. Не зная тайп скрипт я даже всё понял. Про OCP только поверхностно. Как расширять классы не рассказал

[@O_Hat]

Принцип подстановки Барбары Лисков. Я бы изобразил абстракцию реализовав в ней метод расчета площади и от неё наследовался бы, реализуя метод установки ширины и высоты. Вопрос. Это же тоже сохраняет принцип подстановки. Нет?

[@YauhenKavalchuk]

Если я правильно понял описание, то нет

[@IvanFedulov]

6:32 надеюсь у вас опечатка. ф-я getPrice принимает только каталог машин, и во-первых, у нее нет аргумента определающего фильтр. во-вторых ф-я ничего не возвращает, просто в цикле вызывает геттер класса CarPrice. как к этому относиться?

[@YauhenKavalchuk]

🤔

[@grolcoon8798]

спасибо)

[@YauhenKavalchuk]

Пожалуйста

[@АлексейТишаков-с1ц]

спаибо весьма позновательно. У меня вот вопрос по ' O ' , а можно ли считать реализацию декораторов в тс и native декоратор в жс реализацией данного пункта ?

[@YauhenKavalchuk]

Я скажу так, по описанию похоже, но концептуально немного другое

[@Ledrunning]

Классное видео! Спасибо за работу!

[@YauhenKavalchuk]

Пожалуйста

[@olegpristashkin9078]

А вот по принципу Single Responsibility, сколько методов может содержать класс?

[@YauhenKavalchuk]

Сколько угодно, ограничений нет. Главное что-бы класться отвечал за что-то одно

[@Jorjeee]

Супер , я вообще не знал что есть такие понятия. Случайно наткнулся та это видео. Спасибо большое))

[@dsalodki]

действительно просто, подписчиков мало ещё бы разобрать grasp и gof

[@SlavaCh]

Нормально подписчиков для it канала, очень хороший результат

[@leoabalckin8270]

У меня вопрос насчет принципа единственной ответственности (кстати, слова "единый" и "единственный" - паронимы, я бы не стал их взаимозаменять). Итак, "2:20 - итак принцип единой ответственности звучит он как у модуля должна быть только одна причина для изменения или класс должен отвечать только за что-то одно". А вот цитата из Роберта Мартина "Чистая архитектура": "Из всех принципов SOLID наиболее трудно понимаемым является прин цип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соот ветствующего сути. Услышав это название, многие программисты решают: оно означает, или класс должен отвечать только за что-то одно". Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы исполь зуем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID - это не принцип единственной ответственности." Тут возникает сразу несколько вопросов, и самый первый - кому же верить?

[@zeb2296]

Отлично объяснил. Спасибо!

[@YauhenKavalchuk]

Пожалуйста

[@raul_duken]

Подскажиье. 2 пригцип. Если не создавать интерфейс, а в класс ауто добавить ф-ю getPrice(), которая возвращала бы цену, заданую в конструкторе при создании new Auto(name, price). Это можно считать теми же я только в профиль, или есть ращница? Спасибо

[@YauhenKavalchuk]

Ну по сути можно, но это уже нарушает принцип ООП об абстракции

[@MartinEden-ps6ld]

за теслу лайк) А объяснение очень компатное и понятное, спасибо)

[@YauhenKavalchuk]

Спасибо

[@ВладимирЗайчиков-т6и]

огромное спасибо за видео! все по делу, понятно и без воды! очень благодарен!

[@YauhenKavalchuk]

Спасибо за отзыв)

[@Ingvarsson-Ukr]

Пример в Инверсии зависимостей был слишком сложными, прийшлось еще отдельно детально его разбирать, что бы понять что к чему. А так в целом, хороший видос, много полезного узнал. Спасибо.

[@YauhenKavalchuk]

Пожалуйста

[@awwwesoman]

Спасибо за классный разбор принципов SOLID

[@YauhenKavalchuk]

Спасибо за отзыв

[@sfiirwuejnn]

В Liskov subtitution подразумевается же, что класс-наследник не должен менять при переопределении поведение метода родительского класса

[@МаксКондратенко-ц2е]

Спасибо за видио, с меня лайк. Если вы пишите в TS interface, вы ведь просто делаете описание данных, и когда создаете сущности показываете чему они должны соответствовать, в противном случае ts начнет ругаться. Не совсем понял почему мы имплементируемся в классах от интерфейса

[@dmitry.gashko]

Вы как раз описали почему) Интерфейсы это в первую очередь "описание интерфейса", и по класике их кроме как с классами и не использовать. Это в ts можно просто сказать, что какой-то объект имплементирует какой-то интерфейс

[@bierenika]

Женя, какие есть идеи по применению SOLID принципов относительно чистого JavaScript, а не TypeScript ? нет интерфейсов, есть прототипы, ну и классы как синтаксический сахар. Однако очень требуется SOLID )

[@YauhenKavalchuk]

Ну нет интерфейсов, это не проблема. Используйте всё с классами)

[@КоляСолдат]

Почему в примиере Лисков не использовать абстрактный класс для фигур?

[@YauhenKavalchuk]

Решил не усложнять дополнительной абстракцией

[@ПетрИльяш-ь6з]

Спасибо, интересно послушать о solid с примерами на родном js)

[@YauhenKavalchuk]

Я ж объяснил в самом начале, почему описанные подходы проблематично показывать на JS). Там везде только объекты, максимум класс. Ни абстракций, ни интерфейсов

[@ПетрИльяш-ь6з]

@@YauhenKavalchuk , имел ввиду typescript, конечно. Спасибо, что поправили

[@ПолдиСинтин]

А зачем на скриншоты листингов приклеен какой-то светофорчик вверху?

[@YauhenKavalchuk]

Для красоты

[@ПолдиСинтин]

@@YauhenKavalchuk да, красота требует жертв.

[@dizelvinable]

Супер! Много читал/смотрел из разных источников. И мало что понимал. Теперь почти всё понял. Спасибо!)

[@cherimolah9493]

6:24 почему нельзя сделать класс, в котором атрибутами объекта будут являться название и цена? Массив соответственно будет из инстансов этого класса. Функция будет забирать значение цены из атрибута

[@Radik7159]

13:08 прошупрощения, не понимаю почему в параметры конструктура передается интерфейс с модификатором private

[@whins]

kendaleiv.com/typescript-constructor-assignment-public-and-private-keywords/

[@MrSevenZZZ]

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

[@YauhenKavalchuk]

👍

[@alexaxenov974]

Очень качественное обьяснение спасибо огромное !!!)))

[@YauhenKavalchuk]

Пожалуйста!

[@teamplay5921]

Понравилось, спасибо! Лисков немного подкачал.... палец вверх!

[@АндрейКолмогоров-б9ы]

Спасибо, очень коротко, доступно и понятно

[@YauhenKavalchuk]

Пожалуйста)

[@bigdnotation]

Спасибо, всё предельно понятно)

[@YauhenKavalchuk]

Пожалуйста

[@vadimm3077]

Спасибо тебе друже! Очень рад что нашел твой канал хотя не часто захожу сюда и как вижу зря!

[@blagumur.kratos]

Просто и понятно, супер пояснение, спасибо!

[@YauhenKavalchuk]

Пожалуйста)

[@engel8486]

Отличное объяснение, хоть и с нюансами некоторыми) спасибо, жду ещё видео такого формата

[@kerimamanov7760]

Zdorovo! Tol'ko u menya voprosov stalo bol'she?

[@YauhenKavalchuk]

¯\_(ツ)_/¯

[@ФлексГрид]

Получается класс Rectangle ( в примере принципа Барбары Лисков ) противоречит принципу единственной ответственности? Ведь у него как минимум 3 метода для изменения

[@YauhenKavalchuk]

И кстати это вполне нормальная ситуация когда сделав код по одному принципу, конфликтуешь с другим. Но в примере противоречия нет - все 3 метода работают с параметрами одной сущности и нет каких-то «левых» манипуляций

[@ФлексГрид]

@@YauhenKavalchuk Спасибо за ответ! В этом случае непонятно тогда, в чем принцип единственной ответственности, если суть принципа: "Есть только один повод для изменения". Тогда нужно раскрыть более подробно принцип единственной ответственности. ( это не претензия, я не знаю как правильно, а наоборот пытаюсь понять )

[@user-ei9jd7pw4s]

Спасибо огромное!

[@YauhenKavalchuk]

Пожалуйста

[@Arman_127]

Готовлюсь к собеседованию и такие видео очень сильно помогают огромное спасибо

[@YauhenKavalchuk]

Пожалуйста

[@razvrat-i-kotiki]

9:34....либо лыжи не едут. Два примера одинаковы. В чем различия?

[@romanhrechuk7775]

Спасибо за Ваш труд! Жду с нетерпением следующее видео!

[@eugeniar7101]

5:36 вообще не понимаю суть функции по всему циклу же не пройдет, на первом же єлементе попадет либо в case, которьій подходит, либо в default откуда сразу же return вообще не поняла смьісл

[@MAKS-xz1pe]

Какой канал хороший👍И видос топ

[@YauhenKavalchuk]

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

[@vladyan01]

Вот вроде бы понимаю все, но при написании программы не могу применять этот ООП, выходит процедурный способ всегда

[@YauhenKavalchuk]

🤔🤷‍♂️

[@artyomovanton]

13:55 оговорка про реализацию в интерфейсе

[@YauhenKavalchuk]

🤔

[@JavaScriptcher]

Предлагаю тему к следующему видео: Просто о шаблоне MVC

[@YauhenKavalchuk]

👍 ну да, как вариант

[@StefanTheBlade]

Во втором примере (принцип открытости \ закрытости) с тем же успехом я могу ведь просто не создавать никакой абстракции и все будет отлично работать, у меня тот же самый метод getPrice в каждом объекте. Объясните пожалуйста зачем она (абстракция) нужна? Из другого ролика другого автора по этой же теме, я понял этот принцип так: класс должен быть ОТКРЫТ для расширения и ЗАКРЫТ для изменения (расширяем класс для внедрения нового, продвинутого функционала и при этом не изменяем базовый класс, на котором работает старый функционал. В итоге старый код с большей вероятностью продолжит работать без ошибок). Или я что то не правильно понял смотря это видео, или другой автор просто оказался ближе к истине.

[@YauhenKavalchuk]

Абстракцию можно и не создавать. Всё верно поняли - открыт для расширения, закрыт для изменения. Я ведь тоже делал акцент на этом)

[@Евгений-у2е8ы]

Спасибо, очень круто, думаю на repeat будет долго))) про ооп было бы тоже не плохо в таком формате:) огромное спасибо!

[@Epenckorn]

Никак не въезжаю. То ли примеры такие подбирают везде дурацкие, то ли идея сама по себе непонятная, то ли я чего-то не понимаю. Из всех примеров, какие я встречал по всему интернету, я могу сделать только один вывод: принципы эти сводятся к тому, чтобы превратить простую парадигму класс-наследник-объекты в чрезмерно разветвлённую структуру из бесконечно растущего количества наследников, отличающихся порой только значениями свойств. Если кто-то реально использует эти принципы, приведите, пожалуйста, пару-тройку примеров, где и почему вы их используете?

[@wickedtorpedo75]

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

[@rikkicase]

9:52 в итоге проблема с 9:30 ведь осталась.

[@АлександрКундрюков-и7с]

Подскажите где посмотреть более корректный пример?

[@АндрейТузов-л1к]

@@АлександрКундрюков-и7с В wikipedia идеальное описание этого принципа

[@sanyastorm]

Супер Коротко и ясно Спасибо

[@dmitryfokin5205]

Принцип открытости и закрытости - тут нужно ловить баланс. Пример, изменился функционал цены, что лучше? Бегать по всем классам и изменять? Или, как в "неправильном примере", в одном классе в одной функции поменять. Очень сложный вопрос! Если функционал сложный и имеет множество условий в плоть до комбинаторики, то лучше разнести по классам. Если логика попроще, лучше запихнуть в один класс. Еще ошибка - решать данный принцип классами, а не структурой данных. В правильном примере зачем создавать кучу классов? Когда можно решить вопрос объектом содержащим все цены с ключами ссылками, при этом цикл гонять не надо {audi:{tradePrice:100, retailPrice:200}, bmw:{tradePrice:150, retailPrice:250}}. Ну и принцип O противоречит принципу S разбивая функциональность на несколько классов.

[@andreygokhan6893]

А в javascript есть что-то похожее на interface и implement или есть какой-то способ их имитации?

[@YauhenKavalchuk]

Нет. В JS это всё классы

[@GreyFoxTube]

Javascript динамически типизированный язык, и соответственно интерфейсы там не нужны / не реализуемы. Те цели которые достигаются посредством интерфейсов, а это лёгкое тестирование и другие о которых говорил автор, для JS не является проблемой. Динамическая природа JS одновременно и сила и слабость

[@andreygokhan6893]

@@GreyFoxTube То что интерфейсы в javascript не реализуемы - согласен, а то что не нужны - сомневаюсь. Наверно было бы неплохо знать набор интерфейсов, которым следует объект, чтобы точно знать, что в данном объекте необходимые методы точно реализованы и их можно вызывать. Например, если у этого объекта класса Car есть интерфейс "плавание", то значит инкапсулировано свойство герметичность и реализован и доступен метод плыть(). А если есть интерфейс "полёт" ...

[@GreyFoxTube]

@@andreygokhan6893, я лично согласен, что динамически типизированным языкам не хватает строгости. Но в целом, в индустрии разработки, где используются динамически типизированные языки, прибегают к соглашениям (конвенциям) в компании и частично обходятся линтерами. Без компиляторов и статических анализаторов, конечно, не так эффективно. Тем не менее работают

[@yaroslavsvitlitskyi1864]

Спасибо за видео

[@YauhenKavalchuk]

Пожалуйста

[@Max-kr4ie]

Интерфейс это особеность тайпскрипта ? Или и в ванильном джс есть ? Походу настал момент когда мне надо освоить тайпскрипт. А что такое лоу и хай модуль, как понять, что он лоу или хай. Или вся разница в том кто кого включает в себя ?

[@YauhenKavalchuk]

Интерфейсов в JS нету.

[@Elator11777]

Как раз то, что искал - спасибо!

[@flashbackmovie8792]

Вроде все так знакомо, но синтаксис какой-то непонятный ... не C++ ли это часом?

[@YauhenKavalchuk]

TypeScript

[@user-genderZi]

Классно объяснил! Спасибо. Все очень понятно. Зачот!

[@eugeniyseliverstov1998]

Как можно установить такой же стиль оформления кода для VS Code. Кто знает, подскажите, плиз)

[@vr4836]

Невероятно !! )

[@YauhenKavalchuk]

👍

[@yuryzhuravlev2312]

Самое интересное что если отказаться от TS обратно к JS то это все будет не нужно. ))) Статическая типизация - напридумывали себе проблем а потом героически боремся с ними.

[@YauhenKavalchuk]

Ну, как есть

[@orkoteg09]

только в typescript есть абстракция и интерфейсы?? )))

[@YauhenKavalchuk]

Нет, просто канал о веб разработке, а это только JavaScript. Там таких понятий нет

[@backend1937]

У вас очень крутой канал, спасибо за ваш труд. У меня возник такой вопрос: В примере Open-closed, функция getPrice изначально выводила цену конкретного автомобиля, после применения на ней рефакторинга, метод стал выводить цены всех автомобилей, а как применить open-closed к задаче с выводом конкретной цены автомобиля?

[@YauhenKavalchuk]

А зачем вам тогда функция? У вас есть класс, который уже отдаёт цену

[@romanbush5164]

Принцыпы сухпайка)

[@YauhenKavalchuk]

?

[@Scrayerful]

Немного сбивает с толку пример со стоимостями машин: Почему не сделать базовый класс с полем цены, метод getPrice() так же определить в базовом классе, а вариации (Audi, BMW) уже сделать наследниками, в которых переопределяется поле цены ? И второй вариант вообще оставить один класс, а определять самоу стоимость в экземпляре (это вроде как не противоречит смыслу того, что машины стоят по разному) *если что я в js не разбираюсь, но думаю наследование и перегрузка полей там есть ?

[@PC-mv5jj]

👍

[@YauhenKavalchuk]

👍

[@devcrghome7061]

SOLID противоречит KISS и как их совместить?

[@YauhenKavalchuk]

Никак. Различные принципа - это лишь рекомендации, которые периодически могут противоречить. Всё не применить)

[@andrerussian4016]

Пример с квадратом считаю "высосанным из пальца"\некорректным В функции setWidth можно было сделать "пустое" тело, у функции setHeight сделать только this.height = height, а также переопределить функцию areaOf: areaOf() { return this.height * this.height} Тогда никаких ошибок бы не возникло

[@YauhenKavalchuk]

Возможно… но это самый распространённый пример

[@amtal6760]

"Аджайл" было бы неплохо поправить в описании. Покоробило от абстрактного класса цены, унаследованного автомобилями.

[@YauhenKavalchuk]

Поправил

[@t3m8ch79]

Отличный и понятный ролик

[@Михайло-п8у]

Начало 1:48

[@YauhenKavalchuk]

👍