Учу питон на степике уже год, но часто сюда прихожу за конкретикой, хотел бы, чтобы у меня был такой преподаватель как ты. Ты единственный кто смог доходчиво объяснить мне про рекурсию и многие другие подводные камни. Больше всего мне по душе то, то диктор не торопится,объясняет все размеренно Спасибо огромное! Надеюсь, что в ближайшем будущем попаду на твой стрим)
Добрый день) вот все люди делают уроки по ооп на основе собачек и кошечек, но я не могу найти пример/объяснение реального примера классов и из-за этого тяжело понять как применять ооп в реальном проекте. Было бы круто если бы вы сделали такой ролик, спасибо
По идее наследование от ABC излишне, когда достаточно использовать только декоратор abstractmethod. И нужно оно исключительно для наглядности. Никак не могу придумать кейсы, где использование наследования от ABC было бы must have
Нет, наследование от ABC это не просто наглядность, это инструмент, который приносит ограничение на создание экземпляров класса, это имеет очень большое значение при построении абстрактностей, которые не должны использоваться напрямую и нужны только для наследования
Например, родительский абстрактный класс для обработки медиа, назовём его MediaProcessor, и зададим два (или сколько угодно) абстрактных метода в стиле resize и crop. Сам по себе этот класс не должен использоваться, потому что медиа может быть разное, он только предоставляет нам набор контрактов, которые мы должны реализовать для каждого типа медиа. Например, это будут ImageProcessor и VideoProcessor, которые уже будут реализовывать конкретную логику ресайза и кропа картинок и видео, и их мы и будем использовать напрямую. В любой момент мы можем добавить новый обработчик, например, DocumentProcessor, наследовать его от MediaProcessor и реализовать все контракты, и использовать таким же способом, как и остальные обработчики
@@pythonclinic , так то же самое можно сделать и без наследования от ABC. Достаточно определить декоратором abstractmethod нужные методы: этого достаточно, чтобы нельзя было создать экземпляр класса MediaProcessor. Дальше наследуемся от него и реализовываем эти методы в классах наследниках. Хотелось бы видеть кейс, где без наследования от ABC просто не обойтись.
Не забрасывай канал, у тебя хорошо получается более глубоко обьяснить ООП пайтнона и функциональное программирование чем у 90% питонистов в ютубе
Учу питон на степике уже год, но часто сюда прихожу за конкретикой, хотел бы, чтобы у меня был такой преподаватель как ты. Ты единственный кто смог доходчиво объяснить мне про рекурсию и многие другие подводные камни.
Больше всего мне по душе то, то диктор не торопится,объясняет все размеренно
Спасибо огромное!
Надеюсь, что в ближайшем будущем попаду на твой стрим)
спасибо большое за отзыв)
Спасибо, стало намного понятней!
Спасибо за видео. Можно ещё в копилку тем добавить видео про wheel. Что это такое, для чего нужно, когда применяется.
добавил в список)
Добрый день) вот все люди делают уроки по ооп на основе собачек и кошечек, но я не могу найти пример/объяснение реального примера классов и из-за этого тяжело понять как применять ооп в реальном проекте. Было бы круто если бы вы сделали такой ролик, спасибо
принято)
На достаточно высоком уровне и, в то же время, последовательно и ПОНЯТНО.
Спасибо!
Да, я б тоже хотел новые видео. Не плохо, воообще-то.
По идее наследование от ABC излишне, когда достаточно использовать только декоратор abstractmethod. И нужно оно исключительно для наглядности.
Никак не могу придумать кейсы, где использование наследования от ABC было бы must have
Нет, наследование от ABC это не просто наглядность, это инструмент, который приносит ограничение на создание экземпляров класса, это имеет очень большое значение при построении абстрактностей, которые не должны использоваться напрямую и нужны только для наследования
@@pythonclinic , а можно какой-нибудь простенький пример, самостоятельно в голову ничего не приходит ни мне, ни моему помощнику chatgpt:)
Например, родительский абстрактный класс для обработки медиа, назовём его MediaProcessor, и зададим два (или сколько угодно) абстрактных метода в стиле resize и crop. Сам по себе этот класс не должен использоваться, потому что медиа может быть разное, он только предоставляет нам набор контрактов, которые мы должны реализовать для каждого типа медиа. Например, это будут ImageProcessor и VideoProcessor, которые уже будут реализовывать конкретную логику ресайза и кропа картинок и видео, и их мы и будем использовать напрямую. В любой момент мы можем добавить новый обработчик, например, DocumentProcessor, наследовать его от MediaProcessor и реализовать все контракты, и использовать таким же способом, как и остальные обработчики
@@pythonclinic , так то же самое можно сделать и без наследования от ABC. Достаточно определить декоратором abstractmethod нужные методы: этого достаточно, чтобы нельзя было создать экземпляр класса MediaProcessor. Дальше наследуемся от него и реализовываем эти методы в классах наследниках.
Хотелось бы видеть кейс, где без наследования от ABC просто не обойтись.
@@pythonclinic, я понял: надо было код написать сразу
А про slots уже было?
ещё нет
Очень нудно! Не смог даже досмотреть!
Спасибо!