14.1. Real-World Analogy: Filling Out a Form¶
You’ve most likely had to fill out paper or electronic forms numerous times in your life: for doctor’s visits, for online purchases, or to RSVP to a wed- ding. Forms exist as a uniform way for another person or organization to collect the information they need about you. Different forms ask for differ- ent kinds of information. You would report a sensitive medical condition on a doctor’s form, and you would report any guests you’re bringing on a wed- ding RSVP, but not the other way around.
In Python, class, type, and data type have the same meaning. Like a paper or electronic form, a class is a blueprint for Python objects (also called instances), which contain the data that represents a noun. This noun could be a doc- tor’s patient, an ecommerce purchase, or a wedding guest. Classes are like a blank form template, and the objects created from that class are like filled- out forms that contain actual data about the kind of thing the form repre- sents. For example, in Figure 15-1, the RSVP response form is like a class, whereas the filled-out RSVP is like an object.
Figure 15-1: Wedding RSVP form templates are like classes, and filled-out forms are like objects.
You can also think of classes and objects as spreadsheets, as in Figure 15-2.
Figure 15-2: A spreadsheet of all RSVP data
The column headers would make up the class, and the individual rows would each make up an object.
Classes and objects are often talked about as data models of items in the real world, but don’t confuse the map for the territory. What goes into the class depends on what the program needs to do. Figure 15-3 shows some objects of different classes that represent the same real-world person, and other than the person’s name, they store completely different information.
Figure 15-3: Four objects made from different classes that represent the same real-world person, depending on what the software application needs to know about the person
Also, the information contained in your classes should depend on your program’s needs. Many OOP tutorials use a Car class as their basic example without noting that what goes into a class depends entirely on the kind of software you’re writing. There’s no such thing as a generic Car class that would obviously have a honkHorn() method or a numberOfCupholders attribute just because those are characteristics real-world cars have. Your program might be for a car dealership web app, a car racing video game, or a road traffic simulation. The car dealership web app’s Car class might have milesPerGallon or manufacturersSuggestedRetailPrice attributes (just as a car dealership’s spreadsheets might use these as columns). But the video game and road traffic simulation wouldn’t have these attributes, because this information isn’t relevant to them. The video game’s Car class might have an explodeWithLargeFireball() method, but the car dealership and traf- fic simulation, hopefully, would not.