Я разработчик со стажем и, стыдно сказать, что всегда ленился разобраться в принципах solid. Александр, спасибо большое! За 12 минут этого видео всё стало предельно ясно!
i dont mean to be offtopic but does anybody know a method to log back into an instagram account..? I stupidly lost my login password. I would love any help you can offer me!
@@alextopsite , проблема не начать применять, а принять все эти "удобства" своим естеством и понять зачем. Что если мое нутро просто орет "зачем"? Чем плохо, например иметь один класс? Чем это неудобно? Никогда не испытывал неудобства. И тут вдруг мне говорят, это неудобно. ) А работать с кучей файлов удобно? Плодить тысячи файлов удобно? Удобно, когда хостер не хочет делать резервную копию от переизбытка маленьких файлов? ... Это как бы вот только, что на скорую руку. Удобство, понятие относительное. Но тут кто то "придумал" принципы и все теперь должны им следовать порождая новый геморрой. ) Барбары Лискоу предлагает свои тапки, а пусть походит в моих, мои мне удобнее, значит и ей будет удобно. )
@@JohnDoe_777 , забавно. А я думал, разраб, это тот кто думает своей головой, а не копирует бездумно. Вы выходит не разраб, а конструктор? Берете готовые кубики и складываете в конструкцию? ) Без обид.
В первом примере в случае с большим классом мы тоже будем менять только один класс. Наверное имелось ввиду, что причин для изменения большого класса из примера может быть 3 - это 1) изменение способа хранения, 2) изменение структуры данных и 3) изменение способа вывода, что не соответствует принципу Single Responsibility. Принцип говорит, что классы должны иметь только одну причину для изменения, а не "только одну ответственность". Есть еще одна проблема в описании первого принципа - для класса вывода есть как минимум 2 причины для изменения, собственно скорее всего то же можно сказать и о классе для хранения. Принцип Single Responsibility нарушен и в результате рефакторинга. Возможно использован слишком сложный пример.
С принципом подстановки Барбары Лисков пример ужасный. Такое впечатление, что автор примера вымучивал его под дулом пистолета. Там есть два класса: прямоугольник и квадрат, квадрат наследуется от прямоугольника. У прямоугольника есть два приватных поля: высота и ширина, и сеттеры + геттеры соответствующих полей. Квадрат наследуется от прямоугольника (получает поля высоту и ширину) и переопределяет сеттеры высоты и ширины. Сеттер высоты устанавливает и ширину и высоту переданным значением, сеттер ширины аналогично. Пока всё нормально (почти). Но дальше появляется метод вычисления площади. Как он работает? Он принимает три параметра: объект класса прямоугольник (или его наследник), ширину и высоту. Далее, он вызывает сеттер ширины, потом сеттер высоты, потом геттерами получает ширину и высоту и возвращает их произведение. С прямоугольником всё работает нормально, а у квадрата сначала ширина и высота устанавливается в 4, потом ширина и высота устанавливается в 5, вызываются геттеры и получается неверный ответ (не совсем так). Первый вопрос к методу: почему он неявно присваивает значения? У него в названии есть set? Тогда почему он что-то устанавливает объекту. Второй вопрос, кто так вообще делает? В нормальном мире создаётся объект, которому в конструктор передаются значения ширины и высоты. Либо, конструктор перегружается и устанавливаются значения по умолчанию. Что значит new Sqгare или new Rectangle без параметров? Прямоугольник с шириной 0? А почему 0? Должны быть инициализирующие значения. Сама суть ООП нам об этом говорит: прямоугольник - объект, со своими свойствами: ширина и высота. При его создании мы должны их указать (или получить по умолчанию). Потом мы можем их поменять сеттером, это ОК. В таком случае метод вычисления площади получает геттерами нужные значения и всё работает нормально. И не изменяет (неявно!) переданный ему объект. Кроме того, что вообще должен означать вызов calculate (new Square, 4, 5) ? Почему мы квадрату передаём два значения (ширина и высота), отличающихся между собой. Вопрос: чему равна площадь квадрата с шириной 4 и высотой 5 см? А это точно квадрат? А как наш код защищён от подобных ошибок? Почему клиент, который понятия не имеет о внутреннем устройстве класса, может делать подобные вызовы? В нормальном мире создаётся новая фигура Rectangle rect = new Rectangle (4, 5) или Square sq = new Square (4). Конструктор в прямоугольнике устанавливает значания ширины и высоты. Конструктор в квадрате вызывает конструктор прямоугольника со значениями (4, 4). В прямоугольнике определяется метод расчёта площади. Квадрат его не переопределяет. вызывается таким образом: int square = rect.calculateSquare() или int square = sq.calculateSquare() и всё работает замечательно. Если метод сторонний, ну ладно, но он не должен неявно устанавливать свойства объекта. Передали ему объект класса Rectangle и пусть вычисляет. Я не говорю, что такого принципа нет, или он не нужен. Я говорю только, что пример подобран ужасно.
@@xenm85 тогда это ещё хуже. Мало того, что не понятно, в чём заключается принцип Лисков, но ещё и получается, что уважаемые авторы нихрена не понимают в том, о чём пишут. Или им пофиг, ctrl+c ctrl+v.
Да нормальный пример, всё понятно. Просто если вы никогда не программировали это сложно понять, как не объясняй. Всё отлично человек объяснаяет, подача простая и понятная, информация подобрана хорошо. 5 баллов из 5.
@@xenm85 Не все 5 принципов равнозначны так за 10 лет в веб программировании ни разу не встречал проблему связанную с подстановкой Liskov, но это не значит что данной проблемы не существует. Скорее данная проблема актуальна для более больших программ - такие как операционные системы. Я сообще не фанат наследование и если отказаться от наследования то данной проблемы не существует )
Класс должен выполнять не одну какую-то работу, а должен выполнять что-то для одного чего-то или для одной какой-то группы. В книге Роберт Мартин приводил пример с классом Работник в котором обледенили методы работающие с разными отделами внутри их фирмы. И вот как раз по этой причине, что они работают для разных групп, его нужно было разделить. Но сам класс может много чего делать для этой группы.
В описании улыбнуло "Что такое SOLID принцы". Это прям для дам ищущих своих принцев. Ищите только SOLID принцев ))) Так же там же есть "Принцы открытости закрытости (Open/Closed)"
Я не согласен с тем пояснением для Single Responsibility, которое представлено в этом видео. У класса должна быть одна ответственность, да. Но, Order - это целый логический кусок, который вполне может быть в одном классе, который, соответственно, будет иметь одну зону ответственности - Order. Тут все дело в количестве сущностей, которые используют этот класс. Такие сущности в uml называются Actor. Разбивать класс на более мелкие по ответственности классы стоит только в том случае, если у них в результате будут отличатся эти самые Actor'ы. Иначе, вы просто создаете более сложное и запутанное приложение, которое конфликтует со вторым принципом Open/Close. То есть есл ивы без надобности разделяете один класс на три, но ваше количество Actor не увеличилось при этом, то вы просто увеличили его связанность и у уменьшили связность, без особых преимуществ. Самый простой для понимания пример - это класс формы в WnForm. На форме может быть куча кнопок и все они делают разные вещи, но в свою очередь класс Form имеет ответственность перед Form1 и больше не перед кем. Если мы разобьем этот класс, как предлагаете вы, то сложность программы возрастет многократно.
Спасибо за комментарий. Дело не в том чтобы слепо следовать этим правилам если у вас небольшой интернет магазин и в классе Order находится скажет ~10 методов большого смысла такое разделение не принесет но сложность возрастет. Свами здесь согласен. Но давайте попробуем забежать вперед. Ваш интернет магазин стал успешным и разросся до размеров амазона. Вы можете представить чтобы в амазоне все что каcается заказа находилось в одном классе ? Какой он будет ~1M строк кода? Думаю что такой класс будет сложно поддерживать. Чисто теоритически все программу можно написать в одном файле в и не парится с namespace в всей этой лабудой с ооп. Для компьютера нет разницы. Но вот человеку будет очень сложно разобраться. По этому и пытаются код разделять на какие-то куски которые были бы понятны логически. Лично я бы предпочел бы 10 классов с ~100 строк кода чем один в класс в ~1000 строк так как если раздробить большой класс на небольшие кусочки у них появится название которое будет подсказывать что оно делает
пожалуйста, помечайте "Clean Architecture" (и следующий из него SOLID) как торговую марку и частный взгляд создателей на то, как по их мнению надо писать код. "Чистая архитектур/код" это не ультимативные подходы.
С одной стороны, я понимаю как отстал в теории для собеседования... Но с другой стороны, забавно смотреть, как мне рассказывают на сколько удобнее носить чужие тапочки. В особенности тапочки Барбары Лискоу. Интересно, у нее какой размер, а то вдруг и вправду удобнее? )))
На мой взгляд пример с прямоугольником и квадратом спорный. Тут скорее всего корявая реализация с использованием. Я понимаю, что не всё из жизни можно переложить на принципы ООП, но это не тот случай. Из геометрии мы знаем, что квадрат - это частный случай прямоугольника у которого все стороны равны. Так почему при подсчёте площади передаётся new Square, а ширина и высота не равны друг другу? Так получается здесь котлеты с мухами в перемешку?!
Как раз отличный пример так как все это знаю т и и большенство будет ломать логику родителя зачем мол заниматься ерундой передавать два параметра когда можно один. Данную ошибку будет сложно отловить а если представить что параметров не 2 а 20 или 200 скажем это модуль аналитики - то вообще кошмар для разработчика
Может не совсем удачный пример - смысл в том что если мы в дочернем классе меняем поведение функции родителя например вместо S = a*b будем делать S = a*a что в частности верно (для квадрата) то в дальнейшем можно упустить из виду что наша реализацию считает площадь не как произведение сторон а как квадрат стороны. Скажу честно не самая распространенная проблема!
Не уверен, что принцип open/closed описан верно. То, что описано более подходит для полиморфизма. Принцип open/closed больше о наследовании, чем об имплементации
Вроде и неплохо объясняешь, но как же скучно... Я несколько раз чуть не заснул, хотя тема и интересна. Написали бы текст какой-то, проговорил бы его несколько раз перед записью. И при монтировании либо переходы плавные, либо обрезать незаконченные слова. А то в некоторых местах обрывается на полуслове и сразу же новая тема. В итоге пока переключишься с того, что не договорили в предыдущем предложении на новое, приходится перематывать назад. Честно, лучше статью почитать чем такое видео, оно сложно к восприятию.
Сделай лучше и поделись. Пока вижу у тебя нечем делиться. Ну можно же ведь просто комментироваться верно же ? Очередной комментатор я тебя даже банить не буду
@@vladislavstepanov7591 да с самим комментатором все не так) Аргументов нет, он просто "пукнул", обозначив свое влажное мнение, ни чем не подкрепив. Автору ролика спасибо за разъяснения, пригодится на ближайших моих собеседованиях )
Видео прикольное,просто о сложном,но площадь квадрата высчитывается точно так же как площадь прямоугольника :))
Одно из лучших видео по SOLID. Максимально просто, коротко и понятно. Большое спасибо!
Я разработчик со стажем и, стыдно сказать, что всегда ленился разобраться в принципах solid. Александр, спасибо большое! За 12 минут этого видео всё стало предельно ясно!
Разобраться это одно, а начать применять - это уже совсем другая история
Ты машинистка значит, а не разраб.
i dont mean to be offtopic but does anybody know a method to log back into an instagram account..?
I stupidly lost my login password. I would love any help you can offer me!
@@alextopsite , проблема не начать применять, а принять все эти "удобства" своим естеством и понять зачем. Что если мое нутро просто орет "зачем"?
Чем плохо, например иметь один класс? Чем это неудобно? Никогда не испытывал неудобства. И тут вдруг мне говорят, это неудобно. ) А работать с кучей файлов удобно? Плодить тысячи файлов удобно? Удобно, когда хостер не хочет делать резервную копию от переизбытка маленьких файлов? ...
Это как бы вот только, что на скорую руку.
Удобство, понятие относительное. Но тут кто то "придумал" принципы и все теперь должны им следовать порождая новый геморрой. )
Барбары Лискоу предлагает свои тапки, а пусть походит в моих, мои мне удобнее, значит и ей будет удобно. )
@@JohnDoe_777 , забавно. А я думал, разраб, это тот кто думает своей головой, а не копирует бездумно. Вы выходит не разраб, а конструктор? Берете готовые кубики и складываете в конструкцию? )
Без обид.
наверное вы единственный кто хорошо объяснил принцыпы спасибо за видео
Спасибо, очень доступно объяснил и с хорошими примерами.
Спасибо! Очень полезно!
Рассказываете очень доступно. Приятно слушать.
Жду с нетерпением еще интересных уроков!!
Спасибо большое будем стараться
Лучший туториал по SOLID, браво!
очень приятно изложение темы, музыка этому хорошо способствует. Спасибо
В первом примере в случае с большим классом мы тоже будем менять только один класс. Наверное имелось ввиду, что причин для изменения большого класса из примера может быть 3 - это 1) изменение способа хранения, 2) изменение структуры данных и 3) изменение способа вывода, что не соответствует принципу Single Responsibility. Принцип говорит, что классы должны иметь только одну причину для изменения, а не "только одну ответственность". Есть еще одна проблема в описании первого принципа - для класса вывода есть как минимум 2 причины для изменения, собственно скорее всего то же можно сказать и о классе для хранения. Принцип Single Responsibility нарушен и в результате рефакторинга. Возможно использован слишком сложный пример.
Спасибо, с конкретными примерами. Ясно и доступно)
С принципом подстановки Барбары Лисков пример ужасный. Такое впечатление, что автор примера вымучивал его под дулом пистолета. Там есть два класса: прямоугольник и квадрат, квадрат наследуется от прямоугольника. У прямоугольника есть два приватных поля: высота и ширина, и сеттеры + геттеры соответствующих полей. Квадрат наследуется от прямоугольника (получает поля высоту и ширину) и переопределяет сеттеры высоты и ширины. Сеттер высоты устанавливает и ширину и высоту переданным значением, сеттер ширины аналогично. Пока всё нормально (почти).
Но дальше появляется метод вычисления площади. Как он работает? Он принимает три параметра: объект класса прямоугольник (или его наследник), ширину и высоту. Далее, он вызывает сеттер ширины, потом сеттер высоты, потом геттерами получает ширину и высоту и возвращает их произведение. С прямоугольником всё работает нормально, а у квадрата сначала ширина и высота устанавливается в 4, потом ширина и высота устанавливается в 5, вызываются геттеры и получается неверный ответ (не совсем так).
Первый вопрос к методу: почему он неявно присваивает значения? У него в названии есть set? Тогда почему он что-то устанавливает объекту. Второй вопрос, кто так вообще делает? В нормальном мире создаётся объект, которому в конструктор передаются значения ширины и высоты. Либо, конструктор перегружается и устанавливаются значения по умолчанию. Что значит new Sqгare или new Rectangle без параметров? Прямоугольник с шириной 0? А почему 0? Должны быть инициализирующие значения. Сама суть ООП нам об этом говорит: прямоугольник - объект, со своими свойствами: ширина и высота. При его создании мы должны их указать (или получить по умолчанию). Потом мы можем их поменять сеттером, это ОК. В таком случае метод вычисления площади получает геттерами нужные значения и всё работает нормально. И не изменяет (неявно!) переданный ему объект. Кроме того, что вообще должен означать вызов calculate (new Square, 4, 5) ? Почему мы квадрату передаём два значения (ширина и высота), отличающихся между собой. Вопрос: чему равна площадь квадрата с шириной 4 и высотой 5 см? А это точно квадрат? А как наш код защищён от подобных ошибок? Почему клиент, который понятия не имеет о внутреннем устройстве класса, может делать подобные вызовы?
В нормальном мире создаётся новая фигура Rectangle rect = new Rectangle (4, 5) или Square sq = new Square (4). Конструктор в прямоугольнике устанавливает значания ширины и высоты. Конструктор в квадрате вызывает конструктор прямоугольника со значениями (4, 4). В прямоугольнике определяется метод расчёта площади. Квадрат его не переопределяет. вызывается таким образом: int square = rect.calculateSquare() или int square = sq.calculateSquare() и всё работает замечательно. Если метод сторонний, ну ладно, но он не должен неявно устанавливать свойства объекта. Передали ему объект класса Rectangle и пусть вычисляет.
Я не говорю, что такого принципа нет, или он не нужен. Я говорю только, что пример подобран ужасно.
Да просто этот пример зачастую везде описывают.
@@xenm85 тогда это ещё хуже. Мало того, что не понятно, в чём заключается принцип Лисков, но ещё и получается, что уважаемые авторы нихрена не понимают в том, о чём пишут. Или им пофиг, ctrl+c ctrl+v.
Да нормальный пример, всё понятно. Просто если вы никогда не программировали это сложно понять, как не объясняй. Всё отлично человек объяснаяет, подача простая и понятная, информация подобрана хорошо. 5 баллов из 5.
@@eugeniabashieva2536 вы видимо программировали. Приведите пример нарушения этого принципа в реальном коде
@@xenm85 Не все 5 принципов равнозначны так за 10 лет в веб программировании ни разу не встречал проблему связанную с подстановкой Liskov, но это не значит что данной проблемы не существует. Скорее данная проблема актуальна для более больших программ - такие как операционные системы. Я сообще не фанат наследование и если отказаться от наследования то данной проблемы не существует )
Очень понятно объяснил!
Классная подача и хорошие примеры, Спасибо!
Прекрасное объяснение, спасибо большое!
Спасибо за комментарий
Спасибо, все четко и понятно
Отличное, а главное понятное объяснение SOLID
благодарю!
Класс должен выполнять не одну какую-то работу, а должен выполнять что-то для одного чего-то или для одной какой-то группы. В книге Роберт Мартин приводил пример с классом Работник в котором обледенили методы работающие с разными отделами внутри их фирмы. И вот как раз по этой причине, что они работают для разных групп, его нужно было разделить. Но сам класс может много чего делать для этой группы.
Спасибо Александр!
Лайк однозначно)
Лайк поставил видео крутое, но "принцЫп"...:D
да есть косяк спс
АрхЕтиктура ООП в начале еще.
Спасибо большое!
На примере ларавела удобно рассказывать)
Очень структурировано, спасибо!
Коротко и понятно, спасибо
В описании улыбнуло "Что такое SOLID принцы". Это прям для дам ищущих своих принцев. Ищите только SOLID принцев )))
Так же там же есть "Принцы открытости закрытости (Open/Closed)"
Хаха и правда смешно получилось
так у Order и у OrderView один Актор. Это вы описали принцип чистого кода, в книге Чистая архитектура Роберта Мартина сказано о подобной путанице.
А это пхп на примере?
оно самое
@@livecodingschool8906 благодарю!)
@@livecodingschool8906 спасибо за объяснения)
Spasibo druq.
Спасибо
Люблю делать класс монстр!
Видимо, не приходилось переделывать класс-монстр в связи с изменениями в проекте.
Круто. Но прям на первом слайде опечатка. И на втором тоже.
dependency inversion можно достичь, используя паттерн фабрика. спасибо за видео
Я не согласен с тем пояснением для Single Responsibility, которое представлено в этом видео. У класса должна быть одна ответственность, да. Но, Order - это целый логический кусок, который вполне может быть в одном классе, который, соответственно, будет иметь одну зону ответственности - Order. Тут все дело в количестве сущностей, которые используют этот класс. Такие сущности в uml называются Actor. Разбивать класс на более мелкие по ответственности классы стоит только в том случае, если у них в результате будут отличатся эти самые Actor'ы. Иначе, вы просто создаете более сложное и запутанное приложение, которое конфликтует со вторым принципом Open/Close. То есть есл ивы без надобности разделяете один класс на три, но ваше количество Actor не увеличилось при этом, то вы просто увеличили его связанность и у уменьшили связность, без особых преимуществ. Самый простой для понимания пример - это класс формы в WnForm. На форме может быть куча кнопок и все они делают разные вещи, но в свою очередь класс Form имеет ответственность перед Form1 и больше не перед кем. Если мы разобьем этот класс, как предлагаете вы, то сложность программы возрастет многократно.
Спасибо за комментарий. Дело не в том чтобы слепо следовать этим правилам если у вас небольшой интернет магазин и в классе Order находится скажет ~10 методов большого смысла такое разделение не принесет но сложность возрастет. Свами здесь согласен. Но давайте попробуем забежать вперед. Ваш интернет магазин стал успешным и разросся до размеров амазона. Вы можете представить чтобы в амазоне все что каcается заказа находилось в одном классе ? Какой он будет ~1M строк кода? Думаю что такой класс будет сложно поддерживать. Чисто теоритически все программу можно написать в одном файле в и не парится с namespace в всей этой лабудой с ооп. Для компьютера нет разницы. Но вот человеку будет очень сложно разобраться. По этому и пытаются код разделять на какие-то куски которые были бы понятны логически. Лично я бы предпочел бы 10 классов с ~100 строк кода чем один в класс в ~1000 строк так как если раздробить большой класс на небольшие кусочки у них появится название которое будет подсказывать что оно делает
@@livecodingschool8906 , прям аж интересно стало... что же там в order озона такого понаписано на 1м кода. )
А фоновая музыка зацикленная словами и безумно отвлекающая это специально или так получилось?
пожалуйста, помечайте "Clean Architecture" (и следующий из него SOLID) как торговую марку и частный взгляд создателей на то, как по их мнению надо писать код. "Чистая архитектур/код" это не ультимативные подходы.
это один из способов как можно писать код чтобы потом в этом можно разобраться, но естественно не единственный )
@@livecodingschool8906 это неправда)
все хорошо объяснил спасибо только последний не понял в основном из за некачественного звука.
за трек на фоне тоже плюс)
С одной стороны, я понимаю как отстал в теории для собеседования... Но с другой стороны, забавно смотреть, как мне рассказывают на сколько удобнее носить чужие тапочки. В особенности тапочки Барбары Лискоу. Интересно, у нее какой размер, а то вдруг и вправду удобнее? )))
не совсем понял ваш пример класса квадрат ,просто вы там параметры не павилно задали
принцип Лисков нужен для низкоуровневого кодинга, а для PHP, JS это мусор - правильно?
и для PHP и JS тоже актуально но достаточно редко встречается - зависит на сколько много у вас OOP кода
музыка на фоне только мешает
На мой взгляд пример с прямоугольником и квадратом спорный. Тут скорее всего корявая реализация с использованием. Я понимаю, что не всё из жизни можно переложить на принципы ООП, но это не тот случай. Из геометрии мы знаем, что квадрат - это частный случай прямоугольника у которого все стороны равны. Так почему при подсчёте площади передаётся new Square, а ширина и высота не равны друг другу? Так получается здесь котлеты с мухами в перемешку?!
Как раз отличный пример так как все это знаю т и и большенство будет ломать логику родителя зачем мол заниматься ерундой передавать два параметра когда можно один. Данную ошибку будет сложно отловить а если представить что параметров не 2 а 20 или 200 скажем это модуль аналитики - то вообще кошмар для разработчика
@@livecodingschool8906 я не про это, а про то что выглядит, как минимум, странно - создание квадрата и передача в параметрах двух разных величин.
Площадь прямоугольника єто вісота умноженная на ширину, площать квадрата можно тоже посчитать как произведение вісоті на ширину
Может не совсем удачный пример - смысл в том что если мы в дочернем классе меняем поведение функции родителя например вместо S = a*b будем делать S = a*a что в частности верно (для квадрата) то в дальнейшем можно упустить из виду что наша реализацию считает площадь не как произведение сторон а как квадрат стороны. Скажу честно не самая распространенная проблема!
Надо бы микрофончик получше... а то немного тише чем у других..... приходится громкость накручивать
Не уверен, что принцип open/closed описан верно. То, что описано более подходит для полиморфизма. Принцип open/closed больше о наследовании, чем об имплементации
как-то не идеально, но лайк
Всё понятно кроме Лисков...
Вроде и неплохо объясняешь, но как же скучно... Я несколько раз чуть не заснул, хотя тема и интересна. Написали бы текст какой-то, проговорил бы его несколько раз перед записью. И при монтировании либо переходы плавные, либо обрезать незаконченные слова. А то в некоторых местах обрывается на полуслове и сразу же новая тема. В итоге пока переключишься с того, что не договорили в предыдущем предложении на новое, приходится перематывать назад. Честно, лучше статью почитать чем такое видео, оно сложно к восприятию.
Что ты тут сказал нихера ж не понятно - 9:55
Принцип открытости/закрытости не понимаю.
Это про то, чтобы не делать методы private, а делать их protected или что?
нет это про то чтобы не изменять логику методов а дополнять и расширять
А что такое архЕтИктура??? 😂🤦♀️
Музыка нарушает принципы solid😂
пля как ты туго рассказываешь
я представляю как бы ты про фп рассказывал))
принцИп, не принцЫп
Ты, конечно, невероятно красив, но, полагаю, если бы 80% места занимал код, а не твоё лицо, всё же было бы лучше.
хаха - следующее видео скринкаст только хард коде
Озвучка статьи с хабры, лол
в описание есть ссылочка
@@livecodingschool8906 Вот и вспомнилось да, всё оттуда
Мудень в кадре сам не понимает о чем рассуждает. Очередной учитель.
Сделай лучше и поделись. Пока вижу у тебя нечем делиться. Ну можно же ведь просто комментироваться верно же ? Очередной комментатор я тебя даже банить не буду
Чувак все плохо))) Данное видео не рекомендуеться для понимания солид)
что же с ним не так ? )
дк что не так?
@@vladislavstepanov7591 да с самим комментатором все не так) Аргументов нет, он просто "пукнул", обозначив свое влажное мнение, ни чем не подкрепив.
Автору ролика спасибо за разъяснения, пригодится на ближайших моих собеседованиях )
Автор не умеет объяснять(((
Спасибо