В каком курсе Девмана рассматривается подробно ООП?

Короткий ответ: ни в каком из курсов и во всех одновременно.

Так же, как и ни в каком не рассматривается отдельно функциональный/императивный/процедурный подходы, нет отдельного курса и про ООП. Но в программе оно есть. Просто не такое, как вы, возможно, ожидали.

Обучение у нас построено на проектах. В обычных рабочих проектах, тех, что выполняют на работе питонистом — ООП-архитектура нужна очень редко. Часто её используют не к месту.

ООП – это не “новый уровень”

Среди новичков/джунов, а иногда даже мидлов, какое-то странное восприятие ООП как “нового уровня” в программировании. Частично это течёт из других языков, где ООП — основная парадигма программирования: тех же Java и C#. Скорее всего программисты из этих языков, когда переходят в Python, тащат в него привычные подходы программирования.

Питон поддерживает как ООП, так и ещё пару других подходов. Многие читают это так: “значит можно использовать любую! Мне вот ООП нравится, я на ООП пишу, а раз тебе нравится императивный подход — ну и пиши на нём, а ко мне не лезь”. Но это не так работает.

ООП и императивный подход – это скорее как молоток и отвёртка. У функциональщины есть свои границы применимости, у ООП – свои. Так же как отвёрткой нельзя забивать гвозди, а молотком – вворачивать шурупы. Делать все на свете операции одним инструментом, который тебе понравился — плохая идея, надо уметь выбирать.

А ведь есть ещё гаечный ключ (функциональный подход)… И про процедурный забыли! На самом деле разных инструментов ещё и не два, а целый ящик.

Если урок можно решить на 200 строк функциями, либо написать ту же функциональность, но на 600 строк + огромной древовидной структурой на классах, то выбор очевиден в пользу функций. Наш курс про чистоту кода. Если один пишет на 200 строк простой код, который легко менять, читать и поддерживать — он хорошо поработал. Если другой пишет то же самое на 600 строк, причём теряя в гибкости и усложняя тестирование и поддержку через ООП — поработал он плохо, и мы просим переделать.

Повторюсь, это не значит, что классы – плохие. А то, что они, бывает, не подходят под некоторые задачи. Есть задачи, где хороши функции, и есть где хороши классы.

Нельзя использовать ООП везде

А зачем ООП тогда нужно?

Так где оно уместно? Классы – отличное решение для библиотек, например. В том же requests они очень активно используются, response, который вы получаете от requests.get(...) – это объект класса Response. Или в Pillow, например, картинка – это объект класса Image.

С этим ООП вы столкнётесь в курсах Основы Python и API веб-сервисов, там же будет вызов методов (тот же requests.get(...)), например.

ООП используется в Django, в моделях и админке. Там ООП очень специфичное, разработчики Django сильно переиначили его. И именно этим специфичным ООП вы очень хорошо потренируетесь пользоваться в курсах Знакомство с Django: ORM и Django.

Они используются в тестировании, обычно тесты – это методы класса. Эта часть сейчас пропущена в курсе, но восполнить её будет не сложно за 2-3 дня, когда ты пройдёшь курс по Django. Тема не такая уж и большая, чтобы с твоим опытом на тот момент очень быстро понять азы и начать писать тесты.

ООП используется для переопределения всяких стандартных штук (кастомное исключение, логгеры) – это есть в курсе Чат-боты на Python.

Но нужнее всего ООП во время написания своей библиотеки или даже фреймворка. Но блин, как часто питонисты на работе пишут свои библиотеки? 😄 Это очень специфичная задача. Мы думаем сделать такой курс, где вы будете проектировать свою библиотеку, структуру классов и т.д. Но это будет курс совсем не для новичков или даже джунов.

Короче. В каждом курсе вы, на самом деле, используете ООП. Если какие-то фрагменты ООП в программу не попали – значит, они не были нужны для всех тех проектов, что вы реализуете по курсу. И тащить его за уши и выдумывать такие экзотические проекты, чтобы оно вдруг пригодилось – не видим смысла. Зачем учить что-то, что тебе не не пригодилось за всё это время, во всех этих проектах?

А полиморфизм, инкапсуляция и наследование?

Вооот, когда говорят про ООП, почему-то имеют ввиду именно эту, теоретическую часть.

Та часть ООП, которую тебе хочется, которую в деле стоит использовать только при проектировании библиотек и фреймворков, тоже есть в курсе. Но она будет там, где вам реально придётся её использовать: при подготовке к собесам. Вот там вас на каждом собесе будут спрашивать про полиморфизм, инкапсуляцию и прочие страшные слова. Я использовал эти концепции в своей работе за 5 лет раза три, наверное. Большинство питонистов, насколько я знаю, тоже. Короче, вот как надо будет по собесам ходить – тогда и зазубрите эту теорию, пройдёте собесы, и сразу же можно будет с чистой совестью всё это забывать.

Печально, что собеседования так сильно оторваны от практики, но что поделать 😦

Чтиво и видосики на тему

• Перестаньте писать классы – перевод выступления одного из core-разработчиков Python
• Stop writing classes – запись доклада