Object-Oriented Programming

A class definition introduces a new type. The class body lists the attributes and methods every instance gets, and the dunder method **__init__** runs once per instantiation to set the initial state. The first parameter of every instance method is **self**, the reference to the instance being acted on. Python passes it automatically when you call `obj.method()`.

The pattern below is the one shown in 90% of CS50P submissions. Notice three things: the constructor takes the data needed to make a meaningful object, every attribute is assigned to `self`, and a regular method reads those attributes through `self.` again. No `self.` prefix means a local variable that disappears when the method returns.

Instantiation looks like a function call on the class name. `Student("Alice", 21)` builds a fresh object with its own `name` and `age`. Two students built this way share no state, which is the whole point.

Instance attributes belong to one object. Class attributes belong to the class itself and are shared across every instance. The distinction trips up students because Python lets you read a class attribute through any instance, which makes the two look identical until somebody writes to it.

Write to `self.x` and Python creates a new instance attribute that shadows the class attribute for that one object. Write to `Cls.x` and every instance sees the change. Use class attributes for constants tied to the type, like a tax rate or a default category. Use instance attributes for anything that varies per object.

Mutable class attributes are the trap. A list set at class level is shared, so appending through one instance mutates what every other instance sees. Course graders for CS106A flag this as a top-five bug in submitted code.

Three method types exist on a Python class, each marked by a decorator. Instance methods take `self` and operate on one object. Class methods, marked with **@classmethod**, take `cls` and operate on the class itself, which makes them the natural place for alternative constructors. Static methods, marked with **@staticmethod**, take neither and act as plain functions grouped under the class for namespace reasons.

The most common real use: a `@classmethod` factory like `from_string` or `from_dict` that parses input and returns a fresh instance via `cls(...)`. Calling `cls` instead of the literal class name keeps the factory working in subclasses without rewriting it. A `@staticmethod` belongs on the class when the logic is conceptually related but never touches instance or class state, like a validator that checks a date string.

Inheritance lets a subclass reuse a parent's attributes and methods, then add or override its own. Declare the parent in parentheses after the subclass name: `class Manager(Employee):`. The subclass automatically gains every method on the parent. The call **super().__init__(...)** delegates to the parent's constructor so you do not duplicate attribute assignment.

Override a method by redefining it in the subclass. Inside the override, `super().method()` runs the parent's version, which is the pattern for "do everything the parent does, then add this". Python uses MRO (method resolution order) to find the right method on multiple inheritance. The MRO is visible through `Cls.__mro__` and follows the C3 linearization, which keeps single-inheritance behavior intact and gives a deterministic answer for the diamond cases.

Python has no true private attributes. The language uses naming conventions and one piece of mild compiler help. A single underscore prefix (`_balance`) signals "internal, do not touch from outside". A double underscore prefix (`__balance`) triggers **name mangling**: the attribute is stored as `_ClassName__balance` to prevent accidental override in subclasses.

The right tool for controlled access is **@property**. A property wraps an attribute behind getter and setter methods while keeping the syntax `obj.x` and `obj.x = value` unchanged. The getter runs on read, the setter on write, which gives you validation and computed attributes without breaking calling code. Properties are the idiomatic answer in Python; getter/setter method pairs copied from Java are not.

Special methods, also called dunder methods, hook your class into Python's built-in syntax. Define **__str__** and `print(obj)` returns a readable description. Define **__repr__** and the interactive interpreter shows a precise, unambiguous one. Define **__eq__** and `obj1 == obj2` compares values instead of identity. Define **__len__** and `len(obj)` works.

Four dunders cover most coursework: `__init__`, `__str__`, `__repr__`, `__eq__`. Add `__lt__` and Python's `sorted()` can order instances. Add `__hash__` and the object becomes usable as a dict key. The pattern is consistent: implement the dunder, get the built-in syntax for free.

The **@dataclass** decorator from the standard library writes `__init__`, `__repr__`, and `__eq__` automatically from your type annotations. For pure data containers, dataclasses cut 15 lines of boilerplate to 3. Use a regular class when you need behavior, a dataclass when you mostly need fields.

Polymorphism in Python rests on duck typing, not on type declarations. If an object has the method a function expects, it works. The function never checks the class. This is why `for line in file_obj` and `for line in string_list` both iterate, even though the two types share no parent.

In practice, polymorphism appears when several classes implement the same method name. A function that calls `shape.area()` works on `Circle`, `Rectangle`, and `Triangle` instances without isinstance checks, as long as each class defines `area`. This pattern dominates Django models, scikit-learn estimators (`.fit`, `.predict`), and pytest fixtures.