Object-Oriented Programming Basics: Classes and Objects

At its heart, Object-Oriented Programming (OOP) is a way of organising your code. Before OOP, programmers mostly wrote 'procedural' code, which is a long list of instructions that operate on separate collections of data. If you had many things to track, you used a list of lists or a dictionary. This worked, but as programs grew larger, it became very easy to get lost. A function that supposed to update a person's age might accidentally update their name because the data was just sitting there, unprotected.

OOP introduces two fundamental concepts: the class and the object. A class is a blueprint or a template. It defines a new type of thing. Think of it as a cookie cutter. The class itself does not contain the actual data (the cookie dough). It defines the shape and what data (attributes) every object of that class will have, and what actions (methods) those objects can perform.

An object is an instance of a class. It is the actual 'thing' created using that blueprint. Using the cookie cutter analogy, each cookie you stamp out is an object. All cookies from the same cutter have the same basic shape (the same structure defined by the class), but each cookie is a separate, distinct physical item. You can decorate each cookie differently (give it different attribute values) without affecting any other cookie.

Let us look at a concrete example in Python. Imagine you are working for a library. You want to keep track of books. Before OOP, you might use a dictionary for each book:

book1 = {'title': 'The Hobbit', 'author': 'J.R.R. Tolkien', 'pages': 310}
book2 = {'title': '1984', 'author': 'George Orwell', 'pages': 328}

This works, but it has problems. If you want to add a function that 'reads' a book (prints its details), you have to write a function that expects a dictionary with exactly those keys. If someone passes a different type of dictionary by mistake, the function breaks. There is no guarantee that book1 has a 'title' key.

Now, with a class, you define the structure once.

class Book:
    def __init__(self, title, author, pages):
        self.title = title
        self.author = author
        self.pages = pages

    def display_info(self):
        return f"{self.title} by {self.author}, {self.pages} pages"

Here, class Book: is your blueprint. Inside it, __init__ is a special method called the constructor. Python runs this code automatically every time you create a new book object. The self parameter is a reference to the specific object being created. It is how each object knows its own data. self.title = title means 'take the title you were given when creating this object and store it inside this specific object's Title attribute'.

The method display_info is an action that any Book object can perform. It uses self to access its own title, author, and pages.

Now, to create an actual book object, you call the class name as if it were a function:

my_book = Book('The Hobbit', 'J.R.R. Tolkien', 310)
another_book = Book('1984', 'George Orwell', 328)

Now, my_book and another_book are distinct objects. They are both instances of the Book class. Each has its own title, author, and pages attribute. If you change my_book.title, it does not affect another_book.title. To use the method, you call it on the object:

print(my_book.display_info())

This will output: 'The Hobbit by J.R.R. Tolkien, 310 pages'.

The benefits of this approach are huge:

Why does the exam care about this? Because the entire Python ecosystem is built on objects. Strings, lists, dictionaries – they are all objects. When you call my_list.append(5), you are calling a method on a list object. Understanding that append is defined inside the list class is fundamental to understanding Python. The exam tests whether you can create your own classes, instantiate objects from them, and use the attributes and methods you define.

An IT professional at a company like O'Reilly Media or Pearson might be building an online learning platform. One core requirement is managing user accounts. Instead of having a messy pile of dictionaries where keys can be misspelled, a senior developer would define a User class.

This class would contain:

When a new person signs up, the system calls User('john_doe', 'john@example.com', 'hashed_password'). This creates a brand-new User object stored in the database. The __init__ method ensures that every user, without exception, has all the necessary attributes created correctly. If a developer later adds a new attribute (like two_factor_enabled), they update the __init__ method, and all future objects are created with that attribute. Old objects can be updated later.

The real value appears during maintenance. Imagine a bug where a user's last_login_date is not updating correctly. An engineer can open the User class, find the login() method, and inspect exactly the three lines of code that manipulate the date. They do not have to search through 10,000 lines of unrelated code. The method is encapsulated right next to the data it uses.

Another real-world scenario is a bank's transaction system. A class called BankAccount might have:

The method withdraw() would contain logic to check if the balance is sufficient before subtracting. If you tried to subtract directly (like in procedural code), you might accidentally let the balance go negative. But inside the withdraw method, the check is enforced automatically. Every time any part of the application needs to move money, it must go through that method. This centralised control is critical for preventing bugs and security issues.

In professional practice, an IT professional will: