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

Рет қаралды 9,025

Андрей Иванов | Python

Күн бұрын

Пікірлер: 23

@Nonstop4ik 11 ай бұрын

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

@LizardTLT Жыл бұрын

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

@NotxctQ 5 ай бұрын

Спасибо! Очень хорошее объяснение

@terenpospolity 2 жыл бұрын

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

@rockkley9159 2 жыл бұрын

Подписываюсь. Или перезаписать скомканные моменты можно.

@izzzanaaami 2 жыл бұрын

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

@ДанилЕфимов-г9п 2 жыл бұрын

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

@__.X3.__ 8 ай бұрын

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

@КириллЧе-я5ы 11 ай бұрын

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

@RunBull 11 ай бұрын

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

@RunBull 11 ай бұрын

у меня страдает читаемость из за этого, у меня такие главные функции обычно на 200-400 строк

@Nonstop4ik 11 ай бұрын

@@RunBullочень много. просто попробуй декомпозицию. Что такое декомпозиция? Это разбиение большой и сложной задачи на маленькие, максимально независимые друг от друга части. Придерживайся принципа - S.

@andreybalin9314 Жыл бұрын

Супер 👍

@ahil7800 2 жыл бұрын

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

@ahil7800 2 жыл бұрын

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

@david_shiko 2 жыл бұрын

create_or_update в народе называется upsert, достаточно частая операция в бд. Лично я не вижу преимущества get_or_create перед "if something: create else update". Явное лучше неявного. Кстати джанго не является примеров эталонной архитектуры.