Classes and Objects

What You Already Know About Types and Values

You have been working with types and values since you started programming. When you write the number 5, you are creating a value of type int. When you write the text 'hello', you are creating a value of type str. Each of these values is a real, concrete thing that exists in your program. The type int is like a blueprint or template that describes what an integer is and what you can do with it. The value 5 is one specific instance of that blueprint. This relationship between a blueprint and the things made from it is exactly what classes and objects are.

The Class-as-Blueprint Model

A class is a definition you write that describes what kind of data and behaviors things of that type should have. It is not itself a real thing—it is a plan. When you create an object from a class, you are making a real instance of that plan. That object is the actual thing that exists in your program and holds real data. Think of a class like an architectural blueprint for a house. The blueprint is not a house; it is a description of what a house should look like and what rooms it should have. Each house built from that blueprint is a real object—a place where people actually live. The blueprint can be used to build many houses, and each house will have the same structure but different furniture, different colors, and different people living in it.

Built-in Types Are Already Classes

Python's built-in types like str, int, and list are not special magic—they are classes, just like any class you might write yourself. Every string you use in a program is a real object of the str class. Every list is a real object of the list class. This means that the relationship between the str class and the string 'hello' is exactly the same as the relationship between a Dog class you write and a Dog object you create. The str class defines what strings can do: they can be indexed, they can be concatenated, they have methods like upper() and lower(). Each time you write 'hello', you are creating one real object of the str class with specific data (the characters h-e-l-l-o).

Fields and Methods: What Objects Hold

A class can define fields—variables that belong to that class specifically—which are only usable through an actual object (instance) of that class. A class can also define methods—functions that belong to that class and can be called on objects. Fields hold the data that makes each object unique. Methods define the behaviors that objects of that class can perform. When you create an object, it gets its own copy of the fields defined by its class. Two objects from the same class will have the same field names and the same methods, but the values stored in those fields will be different for each object.

Multiple Objects, Same Class, Different State

Let's trace through what happens when you create two objects from the same class. Imagine you have a Dog class with fields for name, age, and breed. You create the first object: buddy = Dog('Buddy', 3, 'Golden Retriever'). Now buddy is a real object with its own data. You create a second object: max = Dog('Max', 5, 'Labrador'). Now max is a different real object with its own data. Both buddy and max follow the Dog class structure, but they are completely separate objects. Changing buddy's age does not change max's age. They share the same blueprint (the Dog class), but they are independent instances with independent state.

Common Mistakes and Misconceptions

• Confusing the class with the object

  The class is the blueprint; the object is the real thing made from the blueprint. They are different kinds of entities. You cannot store data in a class the way you can in an object.

  Fix: Remember: Dog is the class (the template). buddy is an object (a real instance). You define the class once, then create many objects from it.

• Thinking that built-in types like str and int are not classes

  Built-in types are classes just like any class you define. The str class defines what strings are and what they can do. Every string is a real object of the str class.

  Fix: Recognize that str, int, list, and other built-in types are classes. The value 'hello' is an object of the str class, just as buddy would be an object of the Dog class.

• Thinking that all objects of the same class must have identical data

  Objects share the same structure and methods, but each object stores its own data. The class defines what fields exist, not what values they hold.

  Fix: Each object has its own independent state. Two Dog objects will both have name, age, and breed fields, but the values in those fields are separate for each object.

Why This Matters

Understanding the difference between a class and an object is fundamental to object-oriented programming. It lets you write code that is organized, reusable, and clear. When you define a class, you are creating a reusable template. You can create as many objects from that template as you need, and each one will be independent. This is much more powerful than writing separate code for each individual thing. It also helps you understand how Python's built-in types work. When you call a method on a string like 'hello'.upper(), you are calling a method on a real object of the str class. Understanding that str is a class just like any class you write yourself makes the whole language more coherent.

Practice: Recognizing Classes and Objects

Summary

A class is a type definition—a blueprint that describes what kind of data and behaviors things of that type should have. An object is one real instance of that type. This is the same relationship that exists between the int type and the value 5, or between the str type and the string 'hello'. Built-in Python types like str, int, and list are classes, and every value you use is a real object of one of those classes. A class can define fields (variables that belong to objects of that class) and methods (functions that objects can call). Multiple objects created from the same class share the same structure and methods, but each object has its own independent state—its own field values. Understanding this distinction is key to writing organized, reusable, and clear code.