Python OOP: constructors, encapsulation, and the five kinds of inheritance

A constructor is a special function that Python calls automatically when you create an object. In Python it always carries the same name, __init__, unlike C++ or Java where the constructor takes the class name.

class MobilePhone:
    model = None

    def __init__(self):
        print("Constructor called")

    def talk(self):
        print("Talking")

iphone = MobilePhone()   # Constructor called

The object is created on the last line, and __init__ fires on its own. Three details that get asked in interviews:

• It returns nothing, and it is not void either. Python has no return type on the constructor at all.
• There is no new keyword. MobilePhone() is the whole syntax.
• Its real job is initialising attributes. Anything the object needs a value for gets one here.

Python does not need semicolons at the end of a statement, so leave them out.

self is the first parameter of every method in the class, and it points at the object the method was called on. It is what this is in Java, JavaScript or TypeScript. Attributes are reached through it: self.model, never bare model.

A default constructor takes no parameters beyond self. A parameterized constructor takes the values the object should start with:

class Dog:
    def __init__(self, name_given, breed_given):
        self.name = name_given
        self.breed = breed_given

    def bark(self):
        print("Who is barking?", self.name)

chow = Dog("Chow", "Mastiff")
desi = Dog("Rancho", "Desi")

chow.bark()   # Who is barking? Chow
desi.bark()   # Who is barking? Rancho

Two objects, two independent sets of attributes. chow and desi point at different objects in memory, so the values never collide.

Leave the arguments out and Python raises an error, because there is no second, no-argument constructor to fall back on:

stray = Dog()   # TypeError: __init__() missing 2 required positional arguments

An object whose attributes were never initialised prints None, and None is not null. Same idea, different keyword, and Python spells it with a capital N.

Taking user input inside a class works fine:

class Student:
    def __init__(self):
        self.name = input("Enter your name: ")
        self.age = input("Enter your age: ")

Four scopes turned up in one file, and telling them apart is a standing interview question:

A = 10                      # global, visible everywhere in the module

class Demo:
    B = 11                  # class variable, visible throughout the class

    def print_info(self):
        L = 12              # local, dies when the method returns
        print(self.B)       # 11
        print(A)            # 10

The advantage of a local variable is exactly that limit: it cannot be read or damaged from outside.

Encapsulation means binding the data to the methods that operate on it, then hiding the data so it can only be reached through those methods.

The class started from the counter-example: a login class that stores a password as a plain attribute.

class LoginPage:
    def __init__(self, email, password):
        self.email = email
        self.password = password

page = LoginPage("qa@example.com", "secret123")
print(page.password)   # secret123, and that is the problem

The password is readable from anywhere in the program. That is encapsulation broken.

Credentials moved out to a .env file first, using the python-dotenv library:

pip install python-dotenv

import os
from dotenv import load_dotenv

load_dotenv()
username = os.getenv("USERNAME")
password = os.getenv("PASSWORD")

The .env file is never committed to GitHub and never shared. It plays the role a properties file plays in other stacks, with the difference that it stays out of version control.

Python has no access-modifier keywords. The level is signalled by how you name the attribute:

class BankAccount:
    def __init__(self, balance, account_number):
        self.balance = balance                  # public, fine to read
        self.__account_number = account_number  # private

    def get_account_number(self):               # the only door in
        return self.__account_number

acc = BankAccount(5000, "XXXX1234")
print(acc.balance)                # 5000
print(acc.get_account_number())   # XXXX1234
print(acc.__account_number)       # AttributeError

An automation example from the same idea: the driver is public, the configuration is protected, the API key is private, and a public method can still reach all three from inside the class.

Inheritance lets one class take the attributes and behaviour of another. The giver is the parent or base class, the receiver is the child or subclass. There is no extends keyword: the parent goes in brackets after the class name.

class BaseTest:
    driver = "chrome"

    def setup(self):
        print("Base setup done")

class LoginTest(BaseTest):
    def run(self):
        self.setup()                    # parent method, called as if it were ours
        print("Running on", self.driver)

LoginTest().run()
# Base setup done
# Running on chrome

All five types are supported:

Multiple inheritance is written with a comma:

class ApiBase:
    def api_auth(self):
        print("API auth")

class DbBase:
    def db_connect(self):
        print("DB connect")

class ApiTest(ApiBase, DbBase):
    pass

t = ApiTest()
t.api_auth()     # API auth
t.db_connect()   # DB connect

The hard case is two parents defining the same name. Python resolves it with the method resolution order, and the order you list the parents in decides the answer.

class Father1:
    def money(self):
        print("F1 money")

class Father2:
    def money(self):
        print("F2 money")

class Son(Father2, Father1):
    pass

Son().money()   # F2 money

Swap the brackets to class Son(Father1, Father2) and the output becomes F1 money. Same code, different resolution, decided entirely by the listed order.

Hybrid inheritance is where this earns its keep: a base class splits into two children, both of which are inherited by a single grandchild, and MRO is what keeps that unambiguous.

• Yesterday's task is still open for most of the batch. Finish it today.
• 15 August: holiday.
• 16 August: hackathon, running 11:00 to 23:00 IST. Submissions are compulsory. Instructions come from Deepak and Meethi on the day. Everyone who submits gets a Testing Academy certificate, and the top five share prizes of up to 5,000 rupees.
• Skills masterclass revision, including MCP creation: Wednesday 12 August, 8:00 PM IST. Moved off Thursday.
• Coming next: the last part of Python, then DeepEval, CrewAI and LangChain.
• Evening masterclasses continue on Tuesdays and Fridays through the end of the year.
• A doubt thread for the OOP topics is open. Today's code is pushed to the repository.