Python Advanced. Продвинутый курс: wiki.merionet.ru/merion-academy/courses/python-advanced-prodvinutyj-kurs/?YT& Мы в VK Видео: vk.com/video/@merion_academy Мы в Дзене: wiki.merionet.ru/merion-academy
L вообще не про абстрактные классы. Он про то, что подклассы должны быть способны заменить родителя, не нарушая его контракт. Метод подкласса может ослаблять предусловия родителя и делать более строгими постусловия, а наоборот - нельзя . Например, если метод родителя мог принимать любые числа, то подкласс не должен требовать только положительные, так как это сделает более строгим предусловие. Также нельзя из метода подкласса выбрасывать исключение, если от родительского класса это не ожидалось.
SOLID принципы следует использовать в случае, если в каких-то определённых частях приложения потенциально могут быть частые незначительные изменения в связи с новыми требованиями бизнеса. Это может быть, например, создание нового функционала, который похож на уже существующий(добавление нового способа оплаты), или небольшое изменение поведения текущего(пользователь теперь должен ввести новые данные для оплаты). Стоит отметить, что эти принципы НЕ спасают от случаев, когда нужно внести кардинальные изменения, ломающие всю логику приложения. Если проект маленький, его дальнейшая поддержка не планируется или есть какие-то специфические и важные требования(короткий дедлайн, экономия памяти и т.д.), возможно, SOLID лучше пренебречь.
все эти понятия легкодоступны для понимания, как и солид в целом. Лучше бы объяснили (например сейчас я изучаю) как работает «рантайм» операционок, куда более сложная и интересная тема, потому что достаточно адекватных, сжатых и неблевотных статей я не нашел. А драи, киссы и тому подобное изучается за 3 минуты поиска в интернете.
Жесть, душнилы. Я всё это применяю и знаю, просто если уж SOLID решили разобрать и примеры привести, то новичкам и другие принципы написания кода, какими бы они простими ни были, будут полезны, особенно с примерами. Звучит легко, а как применить не совсем ясно и когда это вообще целесообразно. Нужно уметь мыслить с точки зрения совсем новичка, который только пришёл в индустрию. А целевая аудитория канала именно такая. Опытный человек почитал бы статью, документацию или какую-нибудь заумную книгу.
Просто дать описание понятиям - это ещё не научить этим пользоваться. - "Как мне побеждать в игре?" - "Главный принцип: не получай урон" - "Ой, спасибо, так стало понятнее..."
Да. Но очень желательно при этом задать свои стандарты говнокода. Иначе может получиться, что код не достаточно говнистый будет получаться у некоторых сотрудников.
Хз как можно о S рассказывать без рассказа об акторах. SRP: принцип единственной ответственности каждый программный модуль/класс имеет одну и только одну причину для изменения ( Модуль/класс должен отвечать за одного и только за одного актора. ). Впринципе модуль/класс может делать разные вещи в единном контексте только если причиной для изменения будет единственный актор. Под актором здесь понимается группа, состоящая из одного или нескольких лиц, желающих изменения поведения программного модуля/класса. Авторы не рассказывают об этом и потом новички будут плодить кучу классов. Пусть сами для начала разберутся с SOLID
Привет, классный канал, на 9 минуте небольшая ошибка, наследование от abc не делает класс абстрактным. Попробуйте создать инстанс этого класса, все будет ок. А вот добавление туда декораторов abstractmethod сделает класс абстрактным
SOLID и микросервисы ребята не совместимые. По логике можно сказать, что на базе SOLID сделана идея микросервисов. Ждем ролик про DDD, чтобы, нам легушатам, понять а куда двигаться в этой вашей IT-шечке
Кто может тот делает, кто не может тот учит, кто не может учить тот руководит. Классика. Ещё говорят, что в периоды упадка реальной экономики расцветает экономика отложенного удовлетворения экономических потребностей, например всякие образовательные курсы итп.
По вашему мнению получается, что в принципе единственной ответственности, вообще не может быть более 1 метода… Несколько я знаю смысл совершенно в другом, а именно что за ответом может обратиться менеджер, директор, финансист. И правильно будет написать несколько классов которые делают отчеты, но для разных направлений. А не просто разделить методы по классам. Этим должно занимать разделение интерфейсов.
Я считаю, что нужно создавать отдельные классы для каждого действия допустим для получения данных и для установки в хранилище. Также нужно реализовать паттерн фасад, который управляет доступом к этим классам. Далее, если актеру Бухгалтер нужно получить данные он обращается к фасаду, который в свою очередь провайдит его до класса, выдаеющего эти данные. Если другому актеру, допустим, отдел кадров понадобилось получать как-нибудь данные иначе (Формула изменилась, например), то мы добавляем метод в класс который отвечает за получение данных и также добавляем провайд в класс реализующий фасад и уже этот актор будет взаимодействовать с нужным ему методом. И конечно же к фасаду мы имеем доступ через интерфейсы, для соблюдения полеморфизма) А в видео, по моему личному мнению, есть нарущение SRP, просто потому что Employee, формально, не может посчитать сколько он получит з.п. Если конечно не поразумевался подсчет подсчет оставшихся дянег у клиента
@@KinoArchuve 1) Хз к чему ваши рассказы про фасад к солиду и моей претензии на SRP. Куча текста не о чем. 2) Как вы собираетесь реализовывать ООП, если вам надо создать объект(Например машину), вы серьезно будете создавать куча классов с машиной и одним методом ? ))) 3) То о чем вы говорите обычно используется для бизнес логики. Привет медиатору которой реализует интерфейс irequest с одним лишь методом handle. 4) И нет как раз таки метод подсчета зарплаты не противоречит, в том же DDD мы описываем ентитям поведение, и вот вы удивитесь в зависимости от сложности объекта и поведений будет много.
Принципы solid противоречат computer science и оптимизации кода (особенно абстракции и бесконечное дерево наследований). Хоть применение принципов могут быть полезны для чтения кода человеком (хотя лично меня это очень бесит, особенно в багфиксинге, когда ты лазишь по сотням родительских классов, пока не найдешь саму реализацию). Про оптимизацию (особенно в интерпимтируемых языках): огромное количество классов и абстракций увеличивает количество обращений интепретатора (то есть когда мы вызываем метод на энд поинте (последнем классе), интепретатор поэтапно опускается в родительские классы пока не дойдет до самой реализации, а потом также поэтапно поднимает return, тем самым все эти действия замедляют работу программы, тк на каждый такой шаг необходимо как минимум один такт процессора, а в питоне вообще штук десять). А теперь про память: сам solid код очевидно весит больше, и хотя кажется что какая разница 2 килобайта или 5, у нас ведь на компах по 16 гигабайт оперативы, так вот - не забывайте про микроконтроллеры и прочие низкопроизводительные устройства, где каждый байт на счету. Так что из-за вас солидщики у нас лагают игрушки и приходится постоянно обновлять железо.
Ну а как поддерживать код в долгую разным разработчикам? Это просто ужасно, когда ты заходишь и видишь, что все в одном файле. А при изменении у тебя валится вся программа и уже тебе, а не компьютеру надо читать все это, чтобы найти ошибку
@@KinoArchuve ну, я же не говорю что надо пользоваться только функциональным программированием, от ооп ни кто не отказывается, да и не обязательно все хранить в одном файле. Я говорю о том что, например в одном классе синглтоне типа "МФУ" можно сделать и методы печати, сканирования, отправка факсом (никто уже ими не пользуется, ну да ладно). То есть все функции (вместе с реализацией) засунуть в один класс, не нужно никаких абстракций и наследований. А если все поля класса называть по нормальному и писать анотации, то все будет и так читабельно-понятно. А если говорить про бесконечные наследования абстракций в разных файлах то это тоже не очень понятно, особенно если тебе надо как-нибудь изменить/дополнить реализацию.
@@KinoArchuveя же не говорю, чтоб все хранить в одном файле, один файл - один смысл или класс. Типа в файле users прописать одноименный класс User со всеми полями и методами с реализацией. А когда тебе надо добавить админ функции, просто добавь миксин Admin с методами админа к этому классу и все. Не надо наследоваться от самого user'a, так будет только сложнее, тк теперь у тебя пользователи будут разными instance и их уже будет сложно сравнивать, складывать или, например, в цикле проходить по пользователям и вызывать админ-метод, и к каждому пользователю писать проверку - зачем это нужно, если саму проверку можно засунуть в миксин. В принципе это будет даже понятнее. А если каждый разработчик будет в своем файле писать релизацию, то как потом все это объединять. А про то что весь код рушиться при изменении какого-то метода, ну так сначала тестируй/дебаж, а уж потом коммить. P.s. Искать (скролить или ctrl + click по методу) реализацию в одном файле намного удобнее, чем ctrl-tab'аться по разным файлам.
Solid это сделка с дьяволом. Ты продаешь оптимизацию и память компьютера за быструю и удобную работу для программистов. Но по сути в 90% случаев люди работают не с игровым движком и не с микроконтроллерами, а перекладывают json’ы, так что оптимизация правда зачастую ненужна
Так в микроконтроллерах вообще без ООП пишут. Тупо функция main и из неё куча вызовов других функций. если что я про ардуинки и стмы с прошивками на си, за микропитон не скажу, но там вроде тоже из ООП только модули в качестве классов.
Советую диктору произносить английские слова без попытки произнести без акцента - получаетмя полностью наоборот и режет слух. А так видео очень информативно!
@@merionacademy , мне нужен именно полноценный гайд: дизайн, фронт и бэк на ноде, деплой на хост( админ панель, статистика) есть такой? Может у вас есть чат со специалистами? Этакий форум? 🥺
Думаю принцыпы солид придуманы только чтоб спрашивать на собеседовании. Человек на практике достаточно быстро разбирается зачем абстракции. Через 5 рефакторингов понимает как лучше организовывать код. А эта теория - сложная для понимания херня. Которую можно понять только после того как сам на практике к таким же выводам. А потом понял что оказывается у этого есть названия
Для небольших проектов, естественно, лучше отказаться от подобных вещей. Все эти принципы и архитектурные подходы созданы, чтобы замедлять рост сложности поддержки приложений со временем его роста. Если рост не намечается, то и смысл от всех этих прикольных аббревиатур и подходов пропадает. Всё относительно и зависит от проекта. Увы, нету серебрянной пули
невозможно нормально смотреть, подача на уровне аутиста, рофл лол кек и тд, лучше бы вместо мемов углубились бы в тему, на кеки чебуреки уходит половина видео , на что я трачу свое время?
Python Advanced. Продвинутый курс: wiki.merionet.ru/merion-academy/courses/python-advanced-prodvinutyj-kurs/?YT&
Мы в VK Видео: vk.com/video/@merion_academy
Мы в Дзене: wiki.merionet.ru/merion-academy
Как же шикарно у вас сделаны видосы! Текст, визуализация, отсылки к классике мемологии.. Браво!👏
И юморок завернут шикарно
SOLIDное видео
Метод ITS = ITakSoidet всë равно по статистике как был, так и останется единственным широко применяемым методом. Мечтатели.
выдал базу.
То же самое PSIT - Пока Сойдёт И Так
@@Torbjorn-ph7rt да, точно, надо обязательно дать надежду😀
Еще принцип EVPP = это временно, потом перепишем
Но всё же в СНГ пространстве широко используется и более популярен PH - Pohuy Normalno
L вообще не про абстрактные классы. Он про то, что подклассы должны быть способны заменить родителя, не нарушая его контракт. Метод подкласса может ослаблять предусловия родителя и делать более строгими постусловия, а наоборот - нельзя . Например, если метод родителя мог принимать любые числа, то подкласс не должен требовать только положительные, так как это сделает более строгим предусловие. Также нельзя из метода подкласса выбрасывать исключение, если от родительского класса это не ожидалось.
SOLID принципы следует использовать в случае, если в каких-то определённых частях приложения потенциально могут быть частые незначительные изменения в связи с новыми требованиями бизнеса. Это может быть, например, создание нового функционала, который похож на уже существующий(добавление нового способа оплаты), или небольшое изменение поведения текущего(пользователь теперь должен ввести новые данные для оплаты). Стоит отметить, что эти принципы НЕ спасают от случаев, когда нужно внести кардинальные изменения, ломающие всю логику приложения.
Если проект маленький, его дальнейшая поддержка не планируется или есть какие-то специфические и важные требования(короткий дедлайн, экономия памяти и т.д.), возможно, SOLID лучше пренебречь.
именно, так и появляется оверинженеринг
Очень доходчиво и наглядно. Благодарю
Ждём теперь KISS, DRY, YAGNI и другие заклинания
все эти понятия легкодоступны для понимания, как и солид в целом. Лучше бы объяснили (например сейчас я изучаю) как работает «рантайм» операционок, куда более сложная и интересная тема, потому что достаточно адекватных, сжатых и неблевотных статей я не нашел. А драи, киссы и тому подобное изучается за 3 минуты поиска в интернете.
DRY - не повторяйся
KISS - не переусложняй
Жесть, душнилы. Я всё это применяю и знаю, просто если уж SOLID решили разобрать и примеры привести, то новичкам и другие принципы написания кода, какими бы они простими ни были, будут полезны, особенно с примерами.
Звучит легко, а как применить не совсем ясно и когда это вообще целесообразно. Нужно уметь мыслить с точки зрения совсем новичка, который только пришёл в индустрию.
А целевая аудитория канала именно такая. Опытный человек почитал бы статью, документацию или какую-нибудь заумную книгу.
Просто дать описание понятиям - это ещё не научить этим пользоваться.
- "Как мне побеждать в игре?"
- "Главный принцип: не получай урон"
- "Ой, спасибо, так стало понятнее..."
Теперь жду видео про паттерны!
Как всегда интересно и вовремя!
Прошу, делайте больше образовательных видео!
Обожаю вас когда в качестве примера приводите код на пайтоне, повторяю его просто смотря ваши ролики - гениально и просто Карл! Гениально и просто!
Так, постойте, т.е. если я создам свою it компанию, то я смогу официально утвердить говнокод как стандарт к которому должны все стремиться?
Да. Но очень желательно при этом задать свои стандарты говнокода. Иначе может получиться, что код не достаточно говнистый будет получаться у некоторых сотрудников.
Ты и без всего этого можешь утвердить свой говнокод, как стандарт. Вопрос только в том, кто ему будет следовать
@@макс-х9п9л корпорация LLC "GOVNOCODE & CO"
@@-Sergeyтаких выгонят как профнепригодных)
Вы молодцы! Порекомендую вас друзьям, спасибо за понятное объяснение ❤
Работал когда-то в РУП "БРТПЦ", что на знаке-примере аббревиатур, не очень доступных для быстрого понимания )
Спасибо за ролик, оченькласный
Спасибо, merionacademy) либо автор сам решил выпустить видео на эта тему, либо прочитал мой комментарий)
Чистый кот. 😺
Хз как можно о S рассказывать без рассказа об акторах.
SRP: принцип единственной ответственности каждый программный модуль/класс имеет одну и только одну причину для изменения ( Модуль/класс должен отвечать за одного и только за одного актора. ). Впринципе модуль/класс может делать разные вещи в единном контексте только если причиной для изменения будет единственный актор. Под актором здесь понимается группа, состоящая из одного или нескольких лиц, желающих изменения поведения программного модуля/класса.
Авторы не рассказывают об этом и потом новички будут плодить кучу классов. Пусть сами для начала разберутся с SOLID
8:30 класс square наследуется от ОЧЕПЯТКИ!!!
Ага, а затем на 9:10 в этом же классе нет абстрактного метода get_area().
Молодцы - реклама [почти] в конце.
Как вы думаете, если исключить рекламу, откуда брать деньги на производство роликов на этом канале? Интересны ваши мысли!
8:37
Класс Square у вас унаследован от Shape, а не от Figure
8:38 Почему написано Regtangle?
меня больше смущает, что говорят "наследуется от FIgure", а на деле от Shape, который вообще не объявлен
Использовал бы лучше для примеров Яваскрипт, ну или C# какой-нибудь
Нет никакого Ява скрипта, там буква j это Джей где здесь ты видишь я?
@@LudoChil Я из Германии, у нас говорят яваскрипт 🤷♂️
Привет, классный канал, на 9 минуте небольшая ошибка, наследование от abc не делает класс абстрактным. Попробуйте создать инстанс этого класса, все будет ок. А вот добавление туда декораторов abstractmethod сделает класс абстрактным
Дождался!
💥
Про сравнение GRASP и SOLID 🙏🏼
SOLID и микросервисы ребята не совместимые. По логике можно сказать, что на базе SOLID сделана идея микросервисов.
Ждем ролик про DDD, чтобы, нам легушатам, понять а куда двигаться в этой вашей IT-шечке
8:48 - Shape где)
Расскажите, пожалуйста , про Kerberos
Голову ломаю, не могу понять
Вся надежда на вас 🥹
Давай про GRASP
04:46 речь про инкапсуляцию идёт, а не про абстракцию
Один из ЛУЧШИХ it кналов на РУССИ, я считаю, что один из лучших в всём мире. Идея для видео - Свяи в БД(o-to-o; m-to-o; m-to-m;)
опачки, новый видосик)
Годнота! А можно видео про Бабушку (тьфу, Барбару Лисков). А то Аду Лавлейс все знают...
В России разных ИТ-курсов стало больше чем казино в 90-е. )) Видимо очень выгодный бизнес.
Кто может тот делает, кто не может тот учит, кто не может учить тот руководит. Классика. Ещё говорят, что в периоды упадка реальной экономики расцветает экономика отложенного удовлетворения экономических потребностей, например всякие образовательные курсы итп.
или неожиданный скачок спроса на IT специалистов , которым требуются знания. Спрос - всегда формируют реалии :)
давай видео про язык С
По вашему мнению получается, что в принципе единственной ответственности, вообще не может быть более 1 метода…
Несколько я знаю смысл совершенно в другом, а именно что за ответом может обратиться менеджер, директор, финансист. И правильно будет написать несколько классов которые делают отчеты, но для разных направлений. А не просто разделить методы по классам. Этим должно занимать разделение интерфейсов.
Я считаю, что нужно создавать отдельные классы для каждого действия допустим для получения данных и для установки в хранилище. Также нужно реализовать паттерн фасад, который управляет доступом к этим классам. Далее, если актеру Бухгалтер нужно получить данные он обращается к фасаду, который в свою очередь провайдит его до класса, выдаеющего эти данные. Если другому актеру, допустим, отдел кадров понадобилось получать как-нибудь данные иначе (Формула изменилась, например), то мы добавляем метод в класс который отвечает за получение данных и также добавляем провайд в класс реализующий фасад и уже этот актор будет взаимодействовать с нужным ему методом. И конечно же к фасаду мы имеем доступ через интерфейсы, для соблюдения полеморфизма)
А в видео, по моему личному мнению, есть нарущение SRP, просто потому что Employee, формально, не может посчитать сколько он получит з.п. Если конечно не поразумевался подсчет подсчет оставшихся дянег у клиента
@@KinoArchuve 1) Хз к чему ваши рассказы про фасад к солиду и моей претензии на SRP. Куча текста не о чем.
2) Как вы собираетесь реализовывать ООП, если вам надо создать объект(Например машину), вы серьезно будете создавать куча классов с машиной и одним методом ? )))
3) То о чем вы говорите обычно используется для бизнес логики. Привет медиатору которой реализует интерфейс irequest с одним лишь методом handle.
4) И нет как раз таки метод подсчета зарплаты не противоречит, в том же DDD мы описываем ентитям поведение, и вот вы удивитесь в зависимости от сложности объекта и поведений будет много.
4:41 Два раза повторили Class One.
А где в веб применяется солид?
На фуллстек проектах конечно же
Shape = Figure
Даешь чистый код. Да здравствует дядюшка Боб
То чувство когда примеры из жизни непонятные, а когда пишешь код проще, я уже в матрице 😅
Видос классный, душнилам из комментов предлагаю пройти в треды хабра
Принципы solid противоречат computer science и оптимизации кода (особенно абстракции и бесконечное дерево наследований). Хоть применение принципов могут быть полезны для чтения кода человеком (хотя лично меня это очень бесит, особенно в багфиксинге, когда ты лазишь по сотням родительских классов, пока не найдешь саму реализацию).
Про оптимизацию (особенно в интерпимтируемых языках): огромное количество классов и абстракций увеличивает количество обращений интепретатора (то есть когда мы вызываем метод на энд поинте (последнем классе), интепретатор поэтапно опускается в родительские классы пока не дойдет до самой реализации, а потом также поэтапно поднимает return, тем самым все эти действия замедляют работу программы, тк на каждый такой шаг необходимо как минимум один такт процессора, а в питоне вообще штук десять). А теперь про память: сам solid код очевидно весит больше, и хотя кажется что какая разница 2 килобайта или 5, у нас ведь на компах по 16 гигабайт оперативы, так вот - не забывайте про микроконтроллеры и прочие низкопроизводительные устройства, где каждый байт на счету.
Так что из-за вас солидщики у нас лагают игрушки и приходится постоянно обновлять железо.
Ну а как поддерживать код в долгую разным разработчикам? Это просто ужасно, когда ты заходишь и видишь, что все в одном файле. А при изменении у тебя валится вся программа и уже тебе, а не компьютеру надо читать все это, чтобы найти ошибку
@@KinoArchuve ну, я же не говорю что надо пользоваться только функциональным программированием, от ооп ни кто не отказывается, да и не обязательно все хранить в одном файле. Я говорю о том что, например в одном классе синглтоне типа "МФУ" можно сделать и методы печати, сканирования, отправка факсом (никто уже ими не пользуется, ну да ладно). То есть все функции (вместе с реализацией) засунуть в один класс, не нужно никаких абстракций и наследований. А если все поля класса называть по нормальному и писать анотации, то все будет и так читабельно-понятно. А если говорить про бесконечные наследования абстракций в разных файлах то это тоже не очень понятно, особенно если тебе надо как-нибудь изменить/дополнить реализацию.
@@KinoArchuveя же не говорю, чтоб все хранить в одном файле, один файл - один смысл или класс. Типа в файле users прописать одноименный класс User со всеми полями и методами с реализацией. А когда тебе надо добавить админ функции, просто добавь миксин Admin с методами админа к этому классу и все. Не надо наследоваться от самого user'a, так будет только сложнее, тк теперь у тебя пользователи будут разными instance и их уже будет сложно сравнивать, складывать или, например, в цикле проходить по пользователям и вызывать админ-метод, и к каждому пользователю писать проверку - зачем это нужно, если саму проверку можно засунуть в миксин. В принципе это будет даже понятнее. А если каждый разработчик будет в своем файле писать релизацию, то как потом все это объединять. А про то что весь код рушиться при изменении какого-то метода, ну так сначала тестируй/дебаж, а уж потом коммить.
P.s. Искать (скролить или ctrl + click по методу) реализацию в одном файле намного удобнее, чем ctrl-tab'аться по разным файлам.
Solid это сделка с дьяволом. Ты продаешь оптимизацию и память компьютера за быструю и удобную работу для программистов. Но по сути в 90% случаев люди работают не с игровым движком и не с микроконтроллерами, а перекладывают json’ы, так что оптимизация правда зачастую ненужна
Так в микроконтроллерах вообще без ООП пишут. Тупо функция main и из неё куча вызовов других функций. если что я про ардуинки и стмы с прошивками на си, за микропитон не скажу, но там вроде тоже из ООП только модули в качестве классов.
а точно ооп это про классы, а не про типы?
Он систематизировал и объединил их, но никак не написал ибо принципы сформулированы были до него.
Советую диктору произносить английские слова без попытки произнести без акцента - получаетмя полностью наоборот и режет слух. А так видео очень информативно!
Алеееееее. Мне нужна помощь в разработке сайта. Есть тематический чат у кого , или автор мне поможет?
Пройдите на курс про фронтенд разработке и дело в шляпе 🙂
@@merionacademy , мне нужен именно полноценный гайд: дизайн, фронт и бэк на ноде, деплой на хост( админ панель, статистика) есть такой? Может у вас есть чат со специалистами? Этакий форум? 🥺
ебать, это что за марафон годноты на канале мерион ?
Во 2ом классе метод не переопределен а создан новый. Следовательно 2ой класс не соответствует принципу Барбары и Лисков
16 минут годноты
Абстракция, как услышал не понял о чем речь, мне доступно, инкапсуляция, наследование и полиморфизм😂
Но ведь это отсылка на Metal Gear Solid
ДАЁШЬ ЧИСТЫЙ КОД
Роберт Мартин и его брат Джордж - оба упоротые, но каждый на своём.
46 cекунд назад ура ура SOLID ДАА БАБУШКА
Принципы созданы, чтобы их нарушать
Солит? Это про кого-то из Питера?
Ну конечно...
даешь чистый код
Я мечтаю
254
Так это же перезказ книги "Чистая архитектура" только со своими примерами и я не уверен, что все они верные
cleam code
Думаю принцыпы солид придуманы только чтоб спрашивать на собеседовании.
Человек на практике достаточно быстро разбирается зачем абстракции. Через 5 рефакторингов понимает как лучше организовывать код.
А эта теория - сложная для понимания херня. Которую можно понять только после того как сам на практике к таким же выводам. А потом понял что оказывается у этого есть названия
С принципом подстановки Барбары Лисков полный провал.
perviy
Забыли упомянуть, что отказ от этих принципов может увеличить скорость работы до 20 раз
😂
еба*ь все в програме в процедуре, не вникай чел
И на столько же замедлить скорость разработки. Достойно🗿
Для небольших проектов, естественно, лучше отказаться от подобных вещей. Все эти принципы и архитектурные подходы созданы, чтобы замедлять рост сложности поддержки приложений со временем его роста. Если рост не намечается, то и смысл от всех этих прикольных аббревиатур и подходов пропадает. Всё относительно и зависит от проекта. Увы, нету серебрянной пули
изучать солид и ооп с помощью питона...
Таймкоды? Нее, нафик... (
Вот мы так же считаем!
SOLID не актуален, если ты функциональщик
SRP актуален, т.к. одна ф-ция выполняет своё одно действие. Может ещё кто добавит? Мне было бы тоже интересно.
Это слишком спорные и сложные вещи для такого формата, тем более с притянутым за уши Python. Редкое видео, которое не зашло совсем :(
кал
орийность черешни 50-56 ккал на 100 г продукта!
@@merionacademy от которой мы дрищем жидким поносом уже 30 лет всей индустрией
вам просто чуть поменьше черешни надо употреблять, а еще советуем не смешивать с хинкалями, это гарантировано взрывная сразу же
невозможно нормально смотреть, подача на уровне аутиста, рофл лол кек и тд, лучше бы вместо мемов углубились бы в тему, на кеки чебуреки уходит половина видео , на что я трачу свое время?
Как думаете, корректно ли сравнивать людей с аутистами по причине того, что важи ожидания не совпали с просматриваемым контентом?
спасибо