Comments 16
Я 4 года работаю питон-программистом, и то не всё на ваших схемах смог понять.
такого типа код может внушать даже ужас, ну или там, чувство бессилия
10 лет программирования на python, senior developer. Этот код тоже внушает мне ужас и чувство бессилия ;) Type hints, docstring, naming conventions?..
Есть мнение, что совместить ООП и Python не удалось даже Гвидо.
А если серьёзно, то Питон не лучший язык для «вкатывания» в ООП. Как язык общего назначения Python позволяет использовать совершенно разные парадигмы, но это не значит, что он будет лучшим выбором (по крайней мере на этапе обучения).
А что было бы лучшим выбором на этапе обучения?
(я без язвительности, мне правда интересно)
Если нужен лучший выбор именно для обучения, то нужно брать специальный язык для обучения.
Но ведь обычно учатся не просто с целью "научиться". Вот от истинной цели и нужно отталкиваться. Хочется писать игры на Unity — изучай реализацию ООП в C#. Хочешь делать мобильные приложения — изучай реализацию ООП в Java/Kotlin.
Если хочешь просто запускать ML фреймворки на питоне, то ООП не сильно нужно и лучше потратить время на математическую статистику.
А что было бы лучшим выбором на этапе обучения?
Наверное, тот язык, примеры на котором приводятся в учебнике по ООП.
Чтобы иметь представление об ООП достаточно теории. И выше уже написали, что реализация ООП в каждом языке со своими особенностями.
Опять же, за время выяснилось, что ООП совсем не серебрянная пуля, как это казалось 30 лет назад.
И, наличие в языке поддержки классов и объектов, замена в коде функций на методы не делает автоматически этот код соответствующим парадигме ООП.
И когда тебе нужно изучать сразу нейронные сети на Питон без глубокого опыта Питон?
Ну идешь и изучаешь. Чтобы понимать код на современных ML-фреймворках глубокое понимание ООП не нужно.
у меня была только иллюзия ясности
А почему "была"?
Лучше все-таки сначала читать (Гради Буча например), а потом писать (статьи).
Не наоборот.
Вы явно путаете ООП и программирование с использованием классов и объектов. Простое оборачивание вашего процедурного кода в обертки из классов не делает его ОО кодом.
Идеально заходит следующая аналогия:
Представьте что у нас есть формочка для печенья
И сами печенюшки
Так вот формочка для печенья — это наш класс
А сами печеньки — это экземпляры класса
Наплодить этих печенек-объектов мы можем сколько угодно и все они будут похожи на формочку, но в то же время будут отличаться и от нее и друг от друга
Рассказываю популярно как объяснять новичкам что такое ООП
Вы популярно попытались объяснить не ООП, а в чём различие между классом и объектом. Но, к сожалению, эту аналогию в состоянии оценить только тот, кто уже в курсе реализациии ООП, а не новичок.
А тот, кто знаком, скажет, что если печенька — это объект, то класс — это рецепт, а не формочка.
ООП — это не про классы и объекты, это про соответствующий уровень абстракции структур, про иерархию наследования, управляемость и т.п. Где же тут вашим печенькам место?
Я новичок, очень сложно понять
Как совместить парадигму Объектно-ориентированного программирования и Python в голове новичка?