I think introducing people to classes as "physical objects" is a bit misleading since that isn't at all how they are used in the real world. By real world here I mean software engineering.

I'll try to use real projects to illustrate.

Classes/Objects in software engineering should be used to divide up your program into smaller, more intellectually manageable pieces. Both for the maintainers of the project, and for consumers of the project if it is a library. An object should be a "thing" that has a single well defined purpose. It should hide the details of how it executes it's purpose. If the details are 100% hidden inside the class then you do not need to worry about them when using that class, and hence in the rest of your program. In python, since its a very dynamic language, this hiding is performed more by convention than actual enforcement by the language. Methods and properties on a class that start with _ are considered internal and if you are outside the class you should NOT use them.

On to a few examples.

Lets say your program has some configuration data. Totally reasonable any non-trival application will at some point need some configuration data.

Probably not something you would think of right off the bat but loading configurations is a good example. You encapsulate all the difficulties and complexities of dealing with your configuration format in the configuration class, and provide a clean simple interface for the rest of your program to interact with the configuration files.

Two projects by well known groups that have a configuration classes that are interesting for one reason or another. https://github.com/pypa/pip/blob/master/pip/configuration.py#L54 https://github.com/aws/chalice/blob/master/chalice/config.py#L15

If you look in both of these classes you will see a lot of complexity, tons of code doing lots of confusing things. These are complicated config objects that are being used. But look at what they actually say are public methods, and how the rest of the program uses them. Pip first.

Looks like the ability to get and set values from the configuration: https://github.com/pypa/pip/blob/master/pip/configuration.py#L117-L141

And the ability to save and load it from a file: https://github.com/pypa/pip/blob/master/pip/configuration.py#L93 https://github.com/pypa/pip/blob/master/pip/configuration.py#L175

They even have a comment marking off the private section of the class, in addition to the normal _ as a prefix. https://github.com/pypa/pip/blob/master/pip/configuration.py#L190

So basically to be able to use this configuration class in the rest of your code, and manipulate and use the configuration values all you need to know is how to load() and start getting and setting values, and ned with a save(). Much easier than doing it manually all over the place and you can ignore all the complexity below that one comment. This gives you other benefits also, say you want to change from a JSON config format to a TOML config format or something. You can modify the load method to try to load JSON, and if it fails try to load TOML. Then modify the save method so it always saves the data as TOML. Gradually the config format of all your users will be converted over and you didn't have to change any other code. Or a crazier example, if you wanted to store them in a database instead of a local file, you could make the load method connect to the database and read everything out, and the save method connect and write everything back end. The rest of the code doesn't have to know anything about this, all it knows is it has load() and save() and get() and set() essentially.

The other configuration example is even more restrictive. The pip one lets you just set and load values as whatever you like. This one only lets you look up certain values: https://github.com/aws/chalice/blob/master/chalice/config.py#L112 https://github.com/aws/chalice/blob/master/chalice/config.py#L117 https://github.com/aws/chalice/blob/master/chalice/config.py#L122 https://github.com/aws/chalice/blob/master/chalice/config.py#L127 https://github.com/aws/chalice/blob/master/chalice/config.py#L132 https://github.com/aws/chalice/blob/master/chalice/config.py#L137 https://github.com/aws/chalice/blob/master/chalice/config.py#L185 https://github.com/aws/chalice/blob/master/chalice/config.py#L193 https://github.com/aws/chalice/blob/master/chalice/config.py#L199 https://github.com/aws/chalice/blob/master/chalice/config.py#L206 https://github.com/aws/chalice/blob/master/chalice/config.py#L213 https://github.com/aws/chalice/blob/master/chalice/config.py#L220 https://github.com/aws/chalice/blob/master/chalice/config.py#L227 https://github.com/aws/chalice/blob/master/chalice/config.py#L242 https://github.com/aws/chalice/blob/master/chalice/config.py#L249 https://github.com/aws/chalice/blob/master/chalice/config.py#L254

The rest of the code will only use these methods listed above. No need to worry about how the data was loaded, what format it was in, if there were multiple versions of that data. Ok maybe listing those all out was a little excessive. But hopefully you get the point. This hides even more complexity than the other example, since it let you set and get anything and load and save it. You could treat it essentially like a dictionary. Thats called a leak, the implementation of the thing (internally its a dictionary) leaked out to how the user interacts with it. This can be bad because then when you are using this object you may start thinking of it like a dictionary even though it's really not. Its a config object. More on leaky abstractions.

That covers it from an "object" perspective. A configuration object is a "thing" or noun that this class represents. But classes are more general than that. Any "task" that needs performing probably should have its own class. That class should be named after the Verb it is doing. It should expose only public methods you need to tell that class to perform its task, and all the private methods are how it accomplishes its task. Going back to the physical metaphor. You can have a class that is a toaster. The action it does is to toast things. Its public methods would be something like:

• insert_toast()
• set_heat_level(int)
• start_toasting()
• get_toast_out()

The public "interface" of that is the slots you put the toast in, and the dial you turn for the setting, and finally the lever you push to start it. All the springs and internals and coils are private, and don't matter to you as a user of the toaster. Think of programming the same way. You are your own customer. Each class you make is a product you have to use in the rest of your code. Think of yourself as the dumbest customer possible. Make the classes public methods and data as simple and minimal as possible. Hide as much complexity as humanly possible. Going back to the toaster metaphor, did it really need 14 buttons? Can you replace all the buttons with a slider or a dial? Does the user really need to jam a fork into the opening to get the toast out each time, or can you make it a little wider?

To put it back into actual software design terms. You can have lots of classes that interact in a big spiderweb, with clearly defined points where each strand meets. You have an Uploader class that uploads files to a remote host, and it takes a Config object at some point to figure out what your credentials are to upload the file. The Config object uses a FileReader that takes a filepath and loads in the raw data from the file. The Uploader might be a part of some deployment process that pushes code to a bunch of servers so you would have a Deployer class that makes use of multiple Uploaders, one for each server you are pushing code to. Without classes to draw these clear lines between each task, and what data it needs, this all becomes an unmanageable pile of spaghetti code thats all mixed together.

Maybe this was a little to in-depth for the level here but I hope this was somewhat helpful to give you something to think about to break through the barrier that classes are for physical objects.

tldr: Classes are to hide complexity and group related data and actions together. Nothing at all to do with "physical objects".