В целом, объяснение на примерах намного лучше теоретических абстрактных описаний, однако я бы рекомендовал перед записью написать сценарий материала, чтобы объяснение не было таким скомканым. Спасибо.
*2 принцип (OCP) для понимания пример хороший, но на практике в большинстве случаев это будет наоборот не хороший код/не хорошее решение:* В примере уже был написан метод, который мы так или иначе модифицировали (или добавление условия или разбиением условного блока на методы в разных классах), оба решения это модификация, оба примера это нарушение OCP. 1.Вот так на рил проекте, перекраивать дизайн уже существующих класов - не ок, наловите багов даже с автотестами (если вам еще дадут на них деньги). 2.Если так дробить весь код (все методы и классы) проекта, его будет не возможно читать (на каждое действие кода др.файл). А если у заказчика поменяется бизнес логика, то вам будет проще переписать все с нуля. 3.Для чистого выполнения этого принципа без нарушений, требуется с самого начала правильно проэктировать дизайн классов (чтоб будущая функциональность могла расширять уже существующие классы), что опять же разбивается о почти любое изменение требований заказчика (что на рил проэктах просто база). 4.Невозможно писать код только расширением, т.е. нельзя закрыть все классы от модификаций. Заказчик найдет багу, для которой вам нужно будет модифицировать уже написанный класс, или будете ради солида писать новый? 5.Никто польностью не покрывает этим принципом весь код проекта, откройте любой сорс, тойже джанги. А с отдельными классами, где вам это действительно нужно, это хороший принцип. ps с другими принципами ситуация такая же
а как быть в случае "главной" функции ? где например сначала приходят данные с запроса, потом эти данные отправляются в функцию и оттуда приходят новые, потом в другую и так еще раз 10
@@RunBullочень много. просто попробуй декомпозицию. Что такое декомпозиция? Это разбиение большой и сложной задачи на маленькие, максимально независимые друг от друга части. Придерживайся принципа - S.
Пятый принцип, как писали когда-то в с++ репортс, и есть следствие выполнения 2-го и 3-го принципов. Если хотите расширять код без модификации старых классов, хотите соблюдения Лисков, и вам нужно полиморфное поведение типов, решение следующее - наследуйте нафиг все классы от интерфейсов. И да, сегрегируйте эти самые интерфейсы достаточно грамотно, используя в дальнейшем множественное наследование от интерфейсов. В примере на 4-й принцип имхо следует просто написать даа или четыре интерфейса, а потом множественно наследовать нужное поведение… имхо. За ролик спасибо! Убедился в общем окончательно, что и в питоне можно писать норм код.
create_or_update в народе называется upsert, достаточно частая операция в бд. Лично я не вижу преимущества get_or_create перед "if something: create else update". Явное лучше неявного. Кстати джанго не является примеров эталонной архитектуры.
Очень хорошее объяснение. Отличные примеры. Респект
В целом, объяснение на примерах намного лучше теоретических абстрактных описаний, однако я бы рекомендовал перед записью написать сценарий материала, чтобы объяснение не было таким скомканым. Спасибо.
Подписываюсь. Или перезаписать скомканные моменты можно.
Очень толково. Без воды, самая суть.
Спасибо! Очень хорошее объяснение
Спасибо. Просто и понятно.
Ты перевернул мне понятия, и наконец-то я их понял!
Супер 👍
*2 принцип (OCP) для понимания пример хороший, но на практике в большинстве случаев это будет наоборот не хороший код/не хорошее решение:*
В примере уже был написан метод, который мы так или иначе модифицировали (или добавление условия или разбиением условного блока на методы в разных классах), оба решения это модификация, оба примера это нарушение OCP.
1.Вот так на рил проекте, перекраивать дизайн уже существующих класов - не ок, наловите багов даже с автотестами (если вам еще дадут на них деньги).
2.Если так дробить весь код (все методы и классы) проекта, его будет не возможно читать (на каждое действие кода др.файл). А если у заказчика поменяется бизнес логика, то вам будет проще переписать все с нуля.
3.Для чистого выполнения этого принципа без нарушений, требуется с самого начала правильно проэктировать дизайн классов (чтоб будущая функциональность могла расширять уже существующие классы), что опять же разбивается о почти любое изменение требований заказчика (что на рил проэктах просто база).
4.Невозможно писать код только расширением, т.е. нельзя закрыть все классы от модификаций. Заказчик найдет багу, для которой вам нужно будет модифицировать уже написанный класс, или будете ради солида писать новый?
5.Никто польностью не покрывает этим принципом весь код проекта, откройте любой сорс, тойже джанги. А с отдельными классами, где вам это действительно нужно, это хороший принцип.
ps с другими принципами ситуация такая же
а как быть в случае "главной" функции ? где например сначала приходят данные с запроса, потом эти данные отправляются в функцию и оттуда приходят новые, потом в другую и так еще раз 10
у меня страдает читаемость из за этого, у меня такие главные функции обычно на 200-400 строк
@@RunBullочень много. просто попробуй декомпозицию. Что такое декомпозиция?
Это разбиение большой и сложной задачи на маленькие, максимально независимые друг от друга части.
Придерживайся принципа - S.
Пятый принцип, как писали когда-то в с++ репортс, и есть следствие выполнения 2-го и 3-го принципов. Если хотите расширять код без модификации старых классов, хотите соблюдения Лисков, и вам нужно полиморфное поведение типов, решение следующее - наследуйте нафиг все классы от интерфейсов. И да, сегрегируйте эти самые интерфейсы достаточно грамотно, используя в дальнейшем множественное наследование от интерфейсов. В примере на 4-й принцип имхо следует просто написать даа или четыре интерфейса, а потом множественно наследовать нужное поведение… имхо.
За ролик спасибо! Убедился в общем окончательно, что и в питоне можно писать норм код.
😁 вот оно 👍
7:00 А если у нас пользователь был сначала normal, потом стал vip, а потом supervip. Mы ему что каждый раз будем класс менять?
2:00 Возможно вы учили фреймворк джанго. Так вот там встроенных методов с and и or в названии выше крыши. get_or_create, create_or_update и т. д.
create_or_update в народе называется upsert, достаточно частая операция в бд.
Лично я не вижу преимущества get_or_create перед "if something: create else update". Явное лучше неявного. Кстати джанго не является примеров эталонной архитектуры.
Круть, а как ты одновременно на нескольких строках пишешь?
нажимаешь alt и не отпуская выбереш строк
С первого просмотра пока не все понял. Пересмотрю еще разок, когда переварю инфу
топчик
Ты карлик ?
я да.