Wow.. I finally found someone who makes some sense.
I think that OOP is an example of over-engineering.. I use OOP on the database side ALL THE TIME.
Stored procedure inherits from a couple of views.. THAT is practical OOP.
So so so true that MOST developers don’t understand the point of OOP. It is SUPPOSED to make you more efficent as a programmer, but it generally does NOT.
There’s one caveat to using Python as an introductory programming language: avoid the object-oriented features. You can’t dodge them completely, as fundamental data types have useful methods associated with them, and that’s okay. Just make use of what’s already provided and resist talking about how to create classes, and especially avoid talking about any notions of object-oriented design where every little bit of data has to be wrapped up in a class.
The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture. That’s easy to see just by comparing a procedural Python program with an object-oriented one. The latter is almost always longer, full of extra interface and indentation and annotations. The temptation is to start moving trivial bits of code into classes and adding all these little methods and anticipating methods that aren’t needed yet but might be someday.
When you’re trying to help someone learn how to go from a problem statement to working code, the last thing you want is to get them sidetracked by faux-engineering busywork. Some people are going to run with those scraps of OO knowledge and build crazy class hierarchies and end up not as focused on on what they should be learning. Other people are going to lose interest because there’s a layer of extra nonsense that makes programming even more cumbersome.
At some point, yes, you’ll need to discuss how to create objects in Python, but resist for as long as you can.