КАК ПИСАТЬ ХОРОШИЙ КОД? SOLID В ПИТОНЕ 

Очень хорошее объяснение. Отличные примеры. Респект

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

Очень толково. Без воды, самая суть.

Пятый принцип, как писали когда-то в с++ репортс, и есть следствие выполнения 2-го и 3-го принципов. Если хотите расширять код без модификации старых классов, хотите соблюдения Лисков, и вам нужно полиморфное поведение типов, решение следующее - наследуйте нафиг все классы от интерфейсов. И да, сегрегируйте эти самые интерфейсы достаточно грамотно, используя в дальнейшем множественное наследование от интерфейсов. В примере на 4-й принцип имхо следует просто написать даа или четыре интерфейса, а потом множественно наследовать нужное поведение… имхо. За ролик спасибо! Убедился в общем окончательно, что и в питоне можно писать норм код.

Спасибо. Просто и понятно.

Ты перевернул мне понятия, и наконец-то я их понял!

*2 принцип (OCP) для понимания пример хороший, но на практике в большинстве случаев это будет наоборот не хороший код/не хорошее решение:* В примере уже был написан метод, который мы так или иначе модифицировали (или добавление условия или разбиением условного блока на методы в разных классах), оба решения это модификация, оба примера это нарушение OCP. 1.Вот так на рил проекте, перекраивать дизайн уже существующих класов - не ок, наловите багов даже с автотестами (если вам еще дадут на них деньги). 2.Если так дробить весь код (все методы и классы) проекта, его будет не возможно читать (на каждое действие кода др.файл). А если у заказчика поменяется бизнес логика, то вам будет проще переписать все с нуля. 3.Для чистого выполнения этого принципа без нарушений, требуется с самого начала правильно проэктировать дизайн классов (чтоб будущая функциональность могла расширять уже существующие классы), что опять же разбивается о почти любое изменение требований заказчика (что на рил проэктах просто база). 4.Невозможно писать код только расширением, т.е. нельзя закрыть все классы от модификаций. Заказчик найдет багу, для которой вам нужно будет модифицировать уже написанный класс, или будете ради солида писать новый? 5.Никто польностью не покрывает этим принципом весь код проекта, откройте любой сорс, тойже джанги. А с отдельными классами, где вам это действительно нужно, это хороший принцип. ps с другими принципами ситуация такая же

Супер 👍

😁 вот оно 👍

топчик

Спасибо. Понятно все, кроме 5 принципа, который ты называл самым простым. Я вот его ни как не осмыслю. На хабре приводился пример, где есть класс, который ищет студентов, принадлежащих конкретной команде (синяя, красная, зеленая команды через Enum). И если этот высокоуровневый класс поиска наследовать от реализации низкоуровнего класса, который добавляет студента в команду - это плохо, т. к. он реализует это через список. Хорошо - типа создать абстракцию - класс поиска студентов в команде и в классах высокого уровня наследоваться от этой абстракции или допустим использовать в конструкторе и тогда типа все равно, как реализуется добавление студента в комманду - через список, словарь или кортеж. Звучит то принцип понятно, а вот в коде оказалось не так просто смысл уловить.

7:00 А если у нас пользователь был сначала normal, потом стал vip, а потом supervip. Mы ему что каждый раз будем класс менять?

Круть, а как ты одновременно на нескольких строках пишешь?

С первого просмотра пока не все понял. Пересмотрю еще разок, когда переварю инфу

а как быть в случае "главной" функции ? где например сначала приходят данные с запроса, потом эти данные отправляются в функцию и оттуда приходят новые, потом в другую и так еще раз 10

2:00 Возможно вы учили фреймворк джанго. Так вот там встроенных методов с and и or в названии выше крыши. get_or_create, create_or_update и т. д.

Ты карлик ?