OOP Foundations

Theory

To master Object-Oriented Programming (OOP), you must understand memory allocation. Classes are blueprints, but they also act as their own objects in memory. An Attribute is a variable that belongs to this architecture.

•Class Attributes: These are stored in the blueprint's memory space. They are shared by all instances created from that blueprint. If you change it in the blueprint, it changes for everyone (e.g., a "Company Name").

•Instance Attributes: These are stored in the specific object's memory space. They are unique to each specific object and are defined inside the constructor (e.g., an "Employee ID").

Analogy: If a class is a House Blueprint, a Class Attribute is the "Neighborhood Name" (it is the exact same for every house built on that street). An Instance Attribute is the "Paint Color" (it is unique to each individual house).

Code Snippets

Python

class Car:

    wheels = 4  # Class Attribute (Shared in the blueprint's memory)

    def __init__(self, brand):

        self.brand = brand  # Instance Attribute (Unique to the object)

car1 = Car("Tesla")

car2 = Car("Ford")

print(car1.wheels) # Output: 4

# Changing the blueprint changes EVERY car!

Car.wheels = 6  

print(car2.wheels) # Output: 6

Think about it: If you have a class Robot and a class attribute population = 0, and you increment it inside __init__, what happens?
Answer: The population count increases for the entire "species." This is how you track the total number of objects created from a single class.

Common Mistake: 

• The Mutable Class Attribute Trap:

Theory:

Beginners often define lists or dictionaries at the Class level (outside __init__) thinking they are setting a default. However, because class attributes are shared, if you use a mutable object (like a list), every single object created will share the exact same memory address for that list. Modifying it for one instance modifies it for all.

Code Snippet: 

Python

class Student:

    #MISTAKE: Shared across all students!

    grades = [] 

    def __init__(self, name):

        self.name = name 

alice = Student("Alice") 

bob = Student("Bob") 

alice.grades.append(90) 

# Bob suddenly has a grade even though we never gave him one! 

print(f"Bob's grades: {bob.grades}") # Output: [90] 

#FIX: Initialize mutable attributes inside the __init__ constructor using self. 

class FixedStudent:

    def __init__(self, name):

        self.name = name

        self.grades = [] # Each instance gets its own independent list 

Think About It: Why do strings or integers as class attributes not suffer from this "trap" as badly as lists do?
Answer: Strings and integers are immutable. If you try to change an integer class attribute via an instance (e.g., alice.age = 20), Python doesn't modify the shared class integer; it creates a brand new instance attribute for Alice, leaving the shared class attribute untouched. Lists are mutable, so .append() modifies the shared memory directly.

Edge Case Scenario:

• Shadowing Class Attributes:

Theory: Python looks for attributes in a specific Method Resolution Order: first the Instance, then the Class. If you create an instance attribute with the exact same name as a class attribute, you "shadow" (hide) the class-level variable for that specific object. This leads to confusing bugs where you think you're updating a global setting, but you're only updating one object.

Code Snippet: 

Python

class System:

    version = "1.0" # Class Attribute 

sys1 = System() 

sys2 = System() 

#MISTAKE: This creates an instance variable 'version' for sys1 ONLY 

sys1.version = "2.0" 

print(sys1.version) # Output: "2.0" 

print(sys2.version) # Output: "1.0" (The class attribute didn't actually change!) 

#FIX: To change a class attribute for everyone, reference the Class Name directly. 

System.version = "2.0" 

print(sys2.version) # Now everyone sees "2.0" 

Think About It: If sys1 has shadowed the version attribute, can you ever access the shared class attribute through sys1 again?
Answer: Yes. If you delete the instance attribute using del sys1.version, the shadow is removed. The next time you ask for sys1.version, Python will fail to find it in the instance dictionary, fall back to the class dictionary, and successfully return the shared class version.

Theory

self is the bridge between the Blueprint and the Real Object.

When you write my_dog.bark(), Python secretly translates this behind the scenes to Dog.bark(my_dog). The self parameter is the first argument in every instance method because it tells Python: "Use the data belonging to THIS specific object in memory, not the class in general". Unlike other languages (like Java or C++) that hide this binding, Python forces you to declare it explicitly.

Code Snippets

Python

class Dog:

    def __init__(self, name):

        self.name = name 

    def bark(self):

        # self tells Python WHICH dog is barking 

        print(f"{self.name} says: Woof!") 

my_dog = Dog("Rex")

my_dog.bark()

Think About It: Does self have to be named "self"?
Answer: Technically, no. But in the Python community, using anything else is a major red flag. It’s a universal convention that makes your code readable to others.

Common Mistake: 

• The "Self-Inflicted" TypeError:

Theory: 

A method inside a class is fundamentally just a function. When you call object.method(), Python automatically passes the object itself as the first argument. If you forget to include self in your method definition, Python tries to "hand over" the object, but the function has no parameter variable to catch it, causing a crash.

Python
class Robot:

    def __init__(self, model):

        self.model = model 

    #MISTAKE: Missing 'self' parameter 

    def identify(): 

        print("I am a Robot") 

r1 = Robot("RX-78") 

# r1.identify()

#CRASH: TypeError: identify() takes 0 positional arguments but 1 was given 

#FIX: Every instance method must accept self as its first parameter. 

class FixedRobot:

    def identify(self): # self catches the object reference 

        print(f"I am a Robot")

Think About It: Why does the error message say "1 was given" when you left the parentheses empty r1.identify()?
Answer: Because Python automatically and invisibly injected r1 into the parentheses during execution. To Python, you actually typed Robot.identify(r1), hence "1 was given."

Edge Case Scenario:

• Calling Methods Directly from the Class:

Theory: While we almost always call methods from the instance (r1.identify()), you can bypass the instance and call the method directly from the class blueprint. If you do this, Python does not automatically pass the object for you. You must manually provide the object to fulfill the self requirement.

Code Snippet: 

Python

class Player:

    def __init__(self, name):

        self.name = name

    def jump(self):

        print(f"{self.name} jumped!")

p1 = Player("Mario")

# Standard way: Python passes p1 to self automatically

p1.jump() 

# Edge Case way: Calling from the Blueprint requires manual passing

Player.jump(p1)

Think About It: If you pass a completely different object into Player.jump(), will it work?
Answer: Yes, due to Python's "Duck Typing." If you pass an object of a different class into Player.jump(other_object), as long as that other_object has a .name attribute, the method will execute successfully. Python doesn't care about the object's true type, only that it has the attributes requested by self.

Theory

• __init__ is a Magic Method (or "Dunder" method). It is commonly called the Constructor because it "builds" the object's initial state.

• __init__ does not actually create the object. The object is created by an invisible method called __new__. By the time __init__ runs automatically, the object already exists in memory. __init__'s only job is to populate that empty object with its starting data.

Code Snippets

Python

class Profile:

    def __init__(self, username, theme="Dark"): 

        self.username = username 

        self.theme = theme 

        self.is_active = True  # Default state set without user input 

p1 = Profile("Binary_Coder") 

Think about it: Can you have two __init__ methods in one class to handle different types of input?
Answer: No. Python only allows one. If you define it twice, the second one completely replaces the first.

Common Mistake: 

• Returning a Value from the Constructor:

Theory: Because __init__ is an initializer and not the creator of the object, it is strictly forbidden from returning a value. The process of creating an object (e.g., p = Profile()) automatically returns the newly created memory address. If your __init__ tries to return something else, Python will panic and throw a TypeError.

Python
class Database:

    def __init__(self, connection_string):

        self.connection = connection_string

        #MISTAKE: Trying to return a success message

        return "Connected Successfully" 

#CRASH: TypeError: __init__() should return None, not 'str'

# db = Database("local_host") 

#FIX: Simply initialize variables. Do not use the return keyword.

class FixedDatabase:

    def __init__(self, connection_string):

        self.connection = connection_string

        print("Connected Successfully") # Printing is fine, returning is not.

Think About It: If you can't return a value, how do you handle a situation where the initialization fails (e.g., the connection_string is invalid)?
Answer: You handle failure in a constructor by raising an Exception (like a ValueError or ConnectionError). This immediately halts the creation of the object.

Edge Case Scenario:

• __slots__ for Memory Optimization

Theory: Normally, every Python object stores its instance attributes in a hidden dictionary called __dict__. This is highly flexible but consumes a massive amount of RAM. If you are creating millions of small objects (like coordinate points in a graphics engine), you can define __slots__. This tells Python to remove the dictionary and explicitly allocate a fixed amount of space, which can reduce memory usage by 40-50%.

Python
class Point:

    __slots__ = ('x', 'y') # Only allow 'x' and 'y' 

    def __init__(self, x, y): 

        self.x = x

        self.y = y

p = Point(1, 2)

# p.z = 10 #CRASH: AttributeError (z is not in slots) 

Think About It: If __slots__ makes programs faster and use less memory, why don't we use it on every single class?
Answer: Flexibility. __slots__ prevents you from adding new attributes "on the fly" during runtime, which is one of Python's most powerful features. Pros only use it when performance is a massive bottleneck. 

Theory

By default, printing an object outputs a highly unhelpful memory address (e.g., <__main__.Car object at 0x...>). To fix this, we implement specific magic methods.

__str__: The "Pretty" version intended for the End User (e.g., "Order #101"). It should be readable and clean.

__repr__: The "Technical" version intended for Developers. It stands for "Representation." The golden rule of __repr__ is that it should show exactly how to recreate the object via code (e.g., Order(id=101, status='paid')).

Code Snippets

Python

class Product:

    def __init__(self, name, price):

        self.name = name 

        self.price = price 

    def __str__(self): return f"{self.name} (${self.price})" 

    def __repr__(self): return f"Product(name='{self.name}', price={self.price})" 

item = Product("Latte", 5.0) 

print(str(item))  # Output: Latte ($5.0) 

print(repr(item)) # Output: Product(name='Latte', price=5.0) 

Think about it: If you only define __repr__, what happens when you call print(item) (which usually looks for __str__)?
Answer: Python falls back to __repr__. Because of this fallback behavior, it's a best practice in professional engineering to always define at least __repr__.

Common Mistake: 

• Printing Instead of Returning:

Theory: Magic methods like __str__ and __repr__ are fundamentally data-formatting functions. They are meant to supply a string to whoever called them (like the print() function). If you put a print() statement inside the magic method and forget to return a string, Python will crash.

Code Snippet: 

Python
class User:

    def __init__(self, alias):

        self.alias = alias

    def __str__(self):

        #MISTAKE: Printing inside the method, but not returning anything

        print(f"User is {self.alias}") 

u = User("Neo")

#CRASH: TypeError: __str__ returned non-string (type NoneType)

# print(u) 

#FIX: Always use the return keyword.

class FixedUser:

    def __str__(self):

        return f"User is {self.alias}"

Think About It: Why does it say it returned NoneType?
Answer: In Python, if a function finishes executing without hitting an explicit return statement, it automatically returns None. The global print() function requires __str__ to yield string data, so receiving None causes the TypeError.

Edge Case Scenario:

• Collections Fallback to __repr__:

Theory: If you have an object with a beautiful __str__ method, and you place that object inside a collection (like a List or a Dictionary), printing the list will completely ignore your __str__ method and output the __repr__ instead.

Code Snippet: 

Python
item1 = Product("Latte", 5.0)

item2 = Product("Mocha", 6.0)

cart = [item1, item2]

# Even though print() usually uses __str__, printing a list forces __repr__

print(cart) 

# Output: [Product(name='Latte', price=5.0), Product(name='Mocha', price=6.0)]

Think about it: Why does Python aggressively ignore __str__ when objects are inside lists?
Answer: To prevent ambiguity. If __str__ returns something like "Latte, $5.0", printing a list of them might look like [Latte, $5.0, Mocha, $6.0]. It becomes impossible to tell where one object ends and another begins. __repr__ ensures developer clarity when inspecting data structures.

Theory: 

In older languages like Java, developers write explicit methods like get_age() and set_age(value) to protect data. Python avoids this. We use the @property decorator to achieve Encapsulation without sacrificing clean syntax.

@property allows a method to disguise itself as a standard attribute. It looks like you are directly accessing a variable, but behind the scenes, you are triggering a hidden function that can run validation logic (like checking if a temperature defies physics) before updating the internal data.

Code Snippets:

Python

class Temperature:

    def __init__(self, celsius): 

        self._celsius = celsius # _ means "internal use" 

    @property

    def fahrenheit(self): 

        return (self._celsius * 9/5) + 32 

    @fahrenheit.setter

    def fahrenheit(self, value): 

        if value < -459.67: 

            raise ValueError("Too cold for physics!") 

        self._celsius = (value - 32) * 5/9

t = Temperature(25) 

t.fahrenheit = 32 # Calls the hidden setter logic! 

Think About It: Why not just let the user change the variable directly without all these properties?
Answer: Because users make mistakes. Setters act as "Guards" that prevent bad data (like negative ages or impossible temperatures) from breaking your object.

Common Mistake: 

• The Infinite Recursion Trap:

Theory: 

When creating a property, two strict rules apply:

1. The getter and setter methods must have the exact same name (e.g., def balance(self):).

2. The setter must assign the new value to a differently named internal variable (usually prefixed with _). If your setter tries to assign the value to the public property name itself (self.balance = amount), it will trigger the setter again, creating an infinite loop that crashes the program.

Code Snippet: 

Python

class Account:

    def __init__(self, balance):

        self._balance = balance 

    @property

    def balance(self):

        return self._balance

    #MISTAKE 1: Mismatched Name. The setter must be named 'balance'

    # @balance.setter

    # def balance_fixed(self, amount): 

    #     self._balance = amount

    #MISTAKE 2: Infinite Recursion. Assigning to self.balance calls the setter again!

    # @balance.setter

    # def balance(self, amount):

    #     self.balance = amount 

    #CORRECT FIX: Exact same method name, but assigns to the internal variable.

    @balance.setter

    def balance(self, amount):

        self._balance = amount

Think About It: Why does assigning self.balance = amount cause an infinite loop inside the setter, but not inside a normal method?
Answer: Because the @balance.setter decorator tells Python: "Anytime someone writes self.balance = [value], intercept it and run this method instead." So, if the method itself says self.balance = [value], it intercepts its own code over and over again until the program crashes with a RecursionError.

Edge Case Scenario:

• The "Stale Data" Trap:

Theory: Beginners often calculate and store "computed" data inside the __init__ constructor. The problem is that code in __init__ only runs once. If the underlying data changes later, the calculated value becomes static and "stale". Using @property ensures the calculation happens live every single time the attribute is accessed.

Code Snippet: 

Python

class Rectangle:

    def __init__(self, width, height): 

        self.width = width 

        self.height = height 

        #STALE: If width changes later, area won't update! 

        # self.area = width * height 

    @property

    def area(self): # PRO: Always calculates current, live values 

        return self.width * self.height 

rect = Rectangle(10, 5)

rect.width = 20

print(rect.area) # Output: 100 (Correctly dynamically calculated)

Think About It: Are there performance downsides to using @property for calculations instead of __init__?
Answer: Yes. If the calculation is mathematically massive (e.g., processing a 1GB image file), recalculating it live every time someone accesses .area will freeze your program. In those scenarios, professional developers use caching to store the result until the underlying data changes.

Theory:

Regular instance methods automatically pass the object (self). Class methods change this behavior to manipulate the Blueprint itself.

@classmethod: Automatically receives the Class Blueprint (cls) as its first argument instead of the object. This is predominantly used for building "Alternative Constructors" (e.g., creating an object from a JSON string instead of raw arguments).

@staticmethod: Receives nothing automatically. It is fundamentally just a regular function that has been shoved inside the class visually because it relates to the topic logically, but it does not need access to self or cls.

Code Snippets

Python

class Pizza:

    def __init__(self, toppings): 

        self.toppings = toppings 

    @classmethod

    def cheese_pizza(cls): # Factory Method using 'cls' 

        return cls(["mozzarella"]) 

    @staticmethod

    def is_edible(item): 

        return item != "stone" 

Think About It: When is a @staticmethod just a regular function?
Answer: Always. If a method never touches self or cls, it could easily exist totally outside the class. We keep it inside only for logical organization and namespace cleanliness.

Common Mistake: 

• Hardcoding the Class Name:

Theory: Inside a @classmethod, developers sometimes accidentally write return ClassName() instead of return cls(). While this works for the base class, it catastrophically breaks Inheritance. If a child class calls that inherited factory method, it expects to get a child object back, but the hardcoded parent name will force it to return a parent object.

Code Snippet: 

Python
class Document:

    def __init__(self, content):

        self.content = content

    @classmethod

    def create_empty_bad(cls):

        #MISTAKE: Hardcoding 'Document' breaks inheritance

        return Document("") 

    @classmethod

    def create_empty_good(cls):

        #FIX: Using 'cls' dynamically builds whatever class called it

        return cls("") 

class PDF(Document):

    pass

# The child class calls the bad factory...

doc = PDF.create_empty_bad()

print(type(doc)) # Output: <class '__main__.Document'> (Bug! We wanted a PDF!)

Think About It: How does cls() solve this?
Answer: cls acts as a dynamic variable representing whoever invoked the method. When PDF.create_empty_good() is called, Python injects the PDF class blueprint into the cls parameter, ensuring cls("") effectively runs PDF("").

Edge Case Scenario:

• Class Methods as "Alternative Constructors":

Theory: Python strictly forbids multiple __init__ methods. But in the real world, you might need to build an object using standard arguments, from a JSON file, or from a CSV row. We use @classmethod to create "Factory Methods" that process the raw data and then hand it off to the original __init__ constructor.

Code Snippet: 

Python
import json 

class User:

    def __init__(self, name, email): 

        self.name = name 

        self.email = email 

    @classmethod

    def from_json(cls, json_data): 

        data = json.loads(json_data)

        # Returns a new instance of the class by calling the main __init__ 

        return cls(name=data['name'], email=data['email']) 

# Usage: Create user directly from a string format! 

user_json = '{"name": "Alice", "email": "alice@example.com"}' 

new_user = User.from_json(user_json)

Think About It: Why not just put all the JSON loading logic inside the standard __init__ with a giant if/else statement?
Answer: That violates the "Single Responsibility Principle." It makes __init__ heavily bloated and incredibly hard to maintain. Alternative constructors keep the data parsing separated from the actual object initialization.

Theory: 

Encapsulation is the philosophy of hiding the internal gears of a machine. You expose the steering wheel to the driver, but you encapsulate the engine so they don't accidentally break it.

Python's approach to Encapsulation is based on the philosophy: "We are all consenting adults here." It relies on developer trust and naming conventions rather than strict, unbreakable security blockades like in Java or C++.

• _variable (Protected): A gentleman's agreement. "Please don't touch this from the outside; it is meant for internal use."

• __variable (Private): A stronger warning. "I am actively hiding this from you."

The Mind-Bending Truth: Python does not have true privacy. When you use a double underscore (__), Python applies a mechanism called Name Mangling. It secretly changes the variable's internal name by attaching the class name to the front (_ClassName__variableName). This is designed to prevent accidental variable overwrites, not to secure data.

Code Snippets:

Python

class Bank:

    def __init__(self, pin):

        self.__pin = pin # Private attribute

b = Bank(1234)

# This will crash! Python hides the original name.

# print(b.__pin) 

# PROOF: The data is not secure! We can access it using the mangled name.

print(b._Bank__pin) # Output: 1234

Think about it: Is __ truly private?
Answer: No! As shown above, Python simply renames it to _Bank__pin. It’s a "keep out" sign to prevent accidents, not an impenetrable locked vault. Anyone who knows the class name can bypass the privacy entirely.

Common Mistake: 

• Treating Python Encapsulation as True Security:

Theory: 

Because developers see the word "Private," they often assume __ variables are cryptographically secure and use them to store sensitive data like API keys or passwords, thinking malicious users cannot access them.

Code Snippet: 

Python

class APIConnection:

    def __init__(self):

        #MISTAKE: Assuming this is protected from hackers

        self.__secret_token = "ABC-123-XYZ" 

conn = APIConnection()

# A malicious script can easily access it using the mangled name:

stolen_token = conn._APIConnection__secret_token 

print(f"Hacked: {stolen_token}") # Output: Hacked: ABC-123-XYZ

Think About It: If Python doesn't enforce strict memory privacy like Java or C++, what is the actual point of encapsulation?
Answer: Encapsulation in Python is about preventing accidents, not preventing espionage. It ensures that another developer on your team doesn't accidentally overwrite your core engine logic, and it clearly signals which variables are safe to use versus which ones might change in future updates.

Edge Case Scenario:

• Name Mangling & Naming Collisions:

Theory: If the double underscore (__) isn't for security, what is its true technical purpose? The answer is Name Mangling. Python renames the attribute internally to _ClassName__attributeName specifically to prevent Naming Collisions in complex inheritance hierarchies. If a Child class creates an attribute with the exact same name as the Parent class, Name Mangling ensures they don't overwrite each other because they are renamed differently.

Code Snippet: 

Python

class Parent:

    def __init__(self): 

        self.__key = "Parent_Key"

class Child(Parent):

    def __init__(self):

        super().__init__()

        self.__key = "Child_Key" # Creates a brand new mangled variable!  

obj = Child() 

# Both variables exist simultaneously and peacefully in the object's dictionary! 

print(obj.__dict__)

# Output: {'_Parent__key': 'Parent_Key', '_Child__key': 'Child_Key'} 

Think About It: If you strictly needed a variable to be completely immutable and inaccessible from the outside, could you do it natively in standard Python classes?
Answer: Not easily. You would have to override the __setattr__ magic method to block all assignment attempts, or use advanced data structures like NamedTuples or external C-extensions. Python is inherently designed to be open.

The Scenario: You are the lead backend engineer for a new underground street racing game. The garage system needs a robust RaceCar blueprint to handle vehicle inventory. The system must track how many cars exist globally, protect vehicle speed data from being corrupted by bad inputs, process raw telemetry strings into usable objects, and calculate quick race statistics.

The Question:

Write a Python class named RaceCar that strictly implements the following features:

1. Class Attribute: Create a variable called total_cars that starts at 0 and increments every time a new vehicle is created.

2. Constructor (__init__) & Encapsulation: Accept make, model, and top_speed. Store make and model normally. Store top_speed as a protected attribute. Create a strictly private attribute called __nitrous_active set to False.

3. @property (Getters & Setters): Create a property for top_speed. The setter must raise a ValueError if the provided speed is negative or exceeds 350 mph.

4. __str__ & __repr__: Make __str__ return a player-friendly string (e.g., "Ford Mustang (Top Speed: 150 mph)"). Make __repr__ return the exact code needed to recreate it (e.g., "RaceCar(make='Ford', model='Mustang', top_speed=150)").

5. @classmethod: Create an alternative constructor called from_telemetry(cls, data_string) that takes a hyphen-separated string like "Mazda-RX7-180" and returns a fully built RaceCar object.

6. @staticmethod: Create a method called calculate_lap_time(distance, speed) that returns the time it takes to complete a lap (distance / speed).

The Answer:

Python

class RaceCar:

    # Class Attribute

    total_cars = 0 

    def __init__(self, make, model, top_speed):

        self.make = make

        self.model = model

        # Passing this through the setter immediately for validation!

        self.top_speed = top_speed  

        # Private attribute (Name Mangling applied)

        self.__nitrous_active = False 

        # Increment shared blueprint memory

        RaceCar.total_cars += 1 

    # @property (Getters and Setters)

    @property

    def top_speed(self):

        return self._top_speed

    @top_speed.setter

    def top_speed(self, value):

        if value < 0:

            raise ValueError("Speed cannot be negative!")

        if value > 350:

            raise ValueError("Speed exceeds physical engine limits!")

        self._top_speed = value 

    # String Representations

    def __str__(self):

        return f"{self.make} {self.model} (Top Speed: {self.top_speed} mph)"

    def __repr__(self):

        return f"RaceCar(make='{self.make}', model='{self.model}', top_speed={self.top_speed})"

    # @classmethod (Alternative Constructor)

    @classmethod

    def from_telemetry(cls, data_string):

        make, model, speed_str = data_string.split('-')

        return cls(make, model, int(speed_str))

    # @staticmethod (Utility Function)

    @staticmethod

    def calculate_lap_time(distance, speed):

        if speed <= 0:

            return float('inf')

        return distance / speed

# --- Testing the Code ---

car1 = RaceCar("Nissan", "Skyline", 170)

car2 = RaceCar.from_telemetry("Toyota-Supra-190")

print(car1)                     # Output: Nissan Skyline (Top Speed: 170 mph)

print(repr(car2))               # Output: RaceCar(make='Toyota', model='Supra', top_speed=190)

print(RaceCar.total_cars)       # Output: 2

print(RaceCar.calculate_lap_time(10, 200)) # Output: 0.05

The Explanation:

• Class vs. Instance Attributes: total_cars is declared outside of any method. It lives in the blueprint's memory, which is why we call RaceCar.total_cars += 1 to track global inventory. The other attributes inside __init__ belong to individual objects.

• Encapsulation: By naming the nitrous variable __nitrous_active, we trigger Python's name mangling. If a junior developer tries to type car1.__nitrous_active = True, the code will crash, protecting our game's internal logic.

• Properties & Data Validation: Inside __init__, we assign self.top_speed = top_speed instead of bypassing it with self._top_speed. This is a deliberate architectural choice. It forces the very first speed value through our @top_speed.setter validation logic, guaranteeing that no one can create an invalid car right out of the gate.

• __str__ vs __repr__: __str__ is designed for the UI (what the player sees in the garage menu), while __repr__ is strictly for developer logs to debug the exact state of the object.

• @classmethod vs @staticmethod: from_telemetry is a class method because it physically needs to build and return a new instance of the class (return cls(...)). calculate_lap_time is a static method because the math formula (distance / speed) doesn't care about what car is calling it; it just runs a universal calculation.