Lecture#

Class Methods and Static Methods#

Alternative method types that operate on the class rather than a specific instance.

Refer to L7_class_static_methods.py to follow along with the examples below.

The Three Method Types

Python classes support three kinds of methods. The right choice depends on whether the method needs access to instance state, class state, or neither.

Table 9 Comparison of Python method types#
Type	Decorator	First Param	Access
Instance method	(none)	`self`	Instance + class state
Class method	`@classmethod`	`cls`	Class state only
Static method	`@staticmethod`	(none)	No implicit access

The following example shows all three types in a single class:

class Robot:
    total_robots = 0

    def __init__(self, name: str, battery: int = 100):
        self._name = name
        self._battery = battery
        Robot.total_robots += 1

    def status(self):
        return f"{self._name}: {self._battery}%"

    @classmethod
    def get_fleet_size(cls):
        return f"Fleet size: {cls.total_robots}"

    @staticmethod
    def is_valid_battery(level: int) -> bool:
        return isinstance(level, int) and 0 <= level <= 100

scout = Robot("Scout")
print(scout.status())              # Scout: 100%
print(Robot.get_fleet_size())      # Fleet size: 1
print(Robot.is_valid_battery(50))  # True

status() is an instance method. It receives self and accesses per-instance state (_name, _battery).
get_fleet_size() is a class method. It receives cls and accesses class-level state (total_robots), which is shared across all instances.
is_valid_battery() is a static method. It receives neither self nor cls and performs a pure validation with no access to any state.

Object Relationships#

Modeling how objects interact and depend on one another.

Refer to L7_relationships.py to follow along with the examples below.

Types of Object Relationships

Before writing code, the design phase identifies how objects relate to each other. There are three fundamental relationships in OOP, each with different strength and lifetime implications.

Table 10 Object relationship comparison#
Relationship	Keyword	UML Symbol	Lifetime	Example
Association	“uses-a”	Arrow	Independent	Robot uses Task
Aggregation	“has-a”	Hollow diamond	Part outlives whole	Team has Robots
Composition	“has-a”	Filled diamond	Part destroyed with whole	Robot owns Sensors

The UML class diagram below shows all three relationships for the competition domain.

UML class diagram showing association, aggregation, and composition — Fig. 1 **UML class diagram**: association (Robot-Task), aggregation (Team-Robot), and composition (Robot-Sensor).#

Association (uses-a)

Association is a relationship between two objects that establishes a connection for a certain period. One object can cause another to perform an action on its behalf.

Unidirectional: Only one class knows about the other.

Bidirectional: Both classes are aware of each other.

Physical world examples

A Driver uses a Car – the driver exists independently of any particular car.
A Doctor treats a Patient – neither owns the other.
A Student enrolls in a Course – both exist before and after the enrollment.

Robotics Competition examples

A Robot is assigned a Task – the task exists before and after the robot executes it.
A Robot uses a Sensor – the sensor can be shared or reassigned across robots.
A Referee monitors a Team – neither object owns the other.

Class Diagram

Unidirectional association from Robot to Task — Fig. 3 **Unidirectional association** from `Robot` to `Task`.#

Reading the Diagram

This is a unidirectional association: Robot holds a reference to Task via _currentTask. Task has no reference back to Robot.
assignTask() sets _currentTask; performTask() uses it. Both methods take a Task parameter but the persistent reference is stored in _currentTask.
The cardinality 0..1 on the Robot side means a Task is assigned to at most one Robot, or to none at all.
The cardinality 0..* on the Task side means a Robot can have zero or more tasks over its lifetime.
Both ends use 0, making the relationship fully optional on both sides. A Task can exist without a Robot, and a Robot can exist with no task currently assigned.

Code Example

class Task:
    def __init__(self, name: str, priority: int):
        self._name = name
        self._priority = priority

class Robot:
    def __init__(self, name: str):
        self._name = name
        self._current_task: Task | None = None

    def assign_task(self, task: Task) -> None:
        self._current_task = task

pick  = Task("pick widget", priority=1)
scout = Robot("Scout")
scout.assign_task(pick)

What is Happening?

Robot holds a reference to a Task object created outside and passed in.
Task has no reference back to Robot. This is unidirectional.
_current_task: Task | None signals that the relationship is optional. A Robot can exist with no task assigned.
If pick is deleted, scout still exists. If scout is deleted, pick still exists.

Note

The associated object is passed in as a parameter, not created inside the class. In Python, calling del pick does not destroy the Task object as long as scout._current_task still references it. The garbage collector only destroys an object when its reference count reaches zero.

Aggregation (has-a, independent lifetime)

Aggregation is a “has-a” relationship where the part can exist independently of the whole. The part is created outside the container and passed in. Deleting the container does not destroy the part.

Whole: The containing object (e.g., Team).

Part: The contained object that can outlive the whole (e.g., Robot).

Physical world examples

A Library has Books – the books exist before and after the library closes.
A Playlist has Songs – deleting the playlist does not delete the songs.
A Department has Employees – employees exist independently of the department.

Robotics Competition examples

A Team has Robots – dissolving the team does not destroy the robots.
A Arena has Zones – zones can be reassigned to a different arena.
A TaskQueue has Tasks – tasks exist before being added to the queue.

Class Diagram

Aggregation from Team to Robot with hollow diamond — Fig. 5 **Aggregation** from `Team` to `Robot` (hollow diamond on `Team` side).#

Reading the Diagram

The hollow diamond is on the Team side, indicating Team is the whole and Robot is the part.
The cardinality 1..* on the Robot side means a team must have at least one robot.
The cardinality 0..1 on the Team side means a robot belongs to no team (e.g., out of commission) or exactly one team.
The relationship is bidirectional: Robot holds a _team reference back to its Team to enforce the 0..1 constraint.
Dissolving the Team has no effect on the Robot objects. They continue to exist.

Code Example

class Robot:
    def __init__(self, name: str, battery: int = 100):
        self._name = name
        self._battery = battery
        self._team: "Team | None" = None

    @property
    def name(self) -> str:
        return self._name

class Team:
    def __init__(self, team_name: str):
        self._team_name = team_name
        self._robots: list[Robot] = []

    def add_robot(self, robot: Robot) -> None:
        if robot._team is not None:
            raise ValueError(f"{robot.name} already in a team")
        self._robots.append(robot)
        robot._team = self

    def remove_robot(self, robot: Robot) -> None:
        self._robots.remove(robot)
        robot._team = None

scout = Robot("Scout")
alpha = Team("Alpha")
alpha.add_robot(scout)
del alpha
print(scout.name)   # Scout -- still exists

What is Happening?

Robot objects are created outside Team and passed in via add_robot().
Team holds a collection of robots but does not own them.
Robot holds a _team back-reference to enforce the 0..1 constraint. If a robot already belongs to a team, add_robot() raises a ValueError.
Deleting alpha does not delete scout. It continues to exist independently.

Note

Parts are created outside the container and passed in. Enforcing 0..1 membership requires a back-reference in Robot, making this a bidirectional aggregation. The hollow diamond in UML signals that the part can outlive the whole.

Composition (has-a, dependent lifetime)

Composition is a strong “has-a” relationship where the part cannot exist independently of the whole. The part is created inside the whole’s __init__ and is owned exclusively by it. Destroying the whole destroys the parts.

Whole: The containing object that owns its parts (e.g., Robot).

Part: The contained object whose lifetime is tied to the whole (e.g., Sensor).

Physical world examples

A House has Rooms – rooms cannot exist without the house they belong to.
A Car has an Engine – the engine is built as part of the car.
A Human has a Heart – the heart cannot exist independently.

Robotics Competition examples

A Robot owns its Sensors – sensors are created with the robot and destroyed with it.
A Robot owns its BatteryUnit – the battery is an integral part of the robot.
A Arena owns its Obstacles – obstacles are created as part of the arena layout.

Class Diagram

Composition from Robot to Sensor with filled diamond — Fig. 7 **Composition** from `Robot` to `Sensor` (filled diamond on `Robot` side).#

Reading the Diagram

The filled diamond is on the Robot side, indicating Robot is the whole and Sensor is the part.
The cardinality 1..* on the Sensor side means a Robot must have at least one sensor.
The cardinality 1 on the Robot side means each Sensor belongs to exactly one Robot – it cannot be shared or reassigned.
There is no back-reference from Sensor to Robot. This is unidirectional: the robot knows its sensors; the sensors do not know their robot.

Code Example

class Sensor:
    def __init__(self, sensor_type: str, range_m: float):
        self._sensor_type = sensor_type
        self._range_m = range_m

    def read(self) -> float:
        return self._range_m

    def __repr__(self) -> str:
        return f"Sensor('{self._sensor_type}', {self._range_m})"

class Robot:
    def __init__(self, name: str):
        self._name = name
        # Sensors are created here -- they belong to this robot only
        self._sensors: list[Sensor] = [
            Sensor("lidar", 50.0),
            Sensor("camera", 30.0),
        ]

scout = Robot("Scout")
for s in scout._sensors:
    print(s)
# Sensor('lidar', 50.0)
# Sensor('camera', 30.0)

del scout   # Sensors are destroyed with the robot

What is Happening?

Sensor objects are created inside Robot.__init__. They have no existence outside the robot that owns them.
Robot holds the only references to its sensors. When the robot is destroyed, the reference count for each sensor drops to zero and the garbage collector reclaims them.
There is no way to pass a sensor from one robot to another – the relationship is exclusive by design.
This is the strongest form of “has-a”: the part’s lifetime is entirely controlled by the whole.

Note

The key question that distinguishes composition from aggregation is: “Can the part exist without the whole?” If yes, use aggregation (hollow diamond). If no, use composition (filled diamond). The key signal in code: the part is created inside __init__, not passed in as a parameter.

Inheritance#

Defining new classes that extend existing ones.

Refer to L7_inheritance.py to follow along with the examples below.

Generalization vs. Specialization

There are two complementary ways to arrive at an inheritance hierarchy.

Generalization

Generalization is the process of identifying common attributes and behaviors across multiple classes and moving them into a shared base class. It is a bottom-up design activity.

Start with Cat, Dog, and Bird defined independently. Each carries its own _name, _age, _weight, and methods such as eat() and sleep().

Cat, Dog, and Bird classes with common attributes — Fig. 11 **Step 1**: `Cat`, `Dog`, and `Bird` as independent classes sharing common attributes.#

The shared attributes and methods are highlighted: _name, _age, _weight, eat(), sleep(), make_sound(), and move() appear in all three classes.

Common attributes highlighted across Cat, Dog, and Bird — Fig. 13 **Step 2**: Common attributes and methods highlighted across all three classes.#

Extract the shared members into a new Animal base class. Each subclass retains only what is unique to it.

Animal base class with Cat, Dog, and Bird as subclasses — Fig. 15 **Step 3**: Common attributes generalized into the `Animal` base class (bottom-up approach).#

UML Class Diagram

Reading the Diagram

The hollow-headed arrow points from the child to the parent and means “inherits from.”
The parent lists the attributes and methods shared by all subclasses.
The child lists only the attributes and methods it adds or overrides.
Everything in the parent is implicitly available in the child – it does not need to be repeated.
The relationship reads: “Dog is an Animal.”

Python Translation

class Animal:
    def __init__(self, name: str, age: int, weight: float) -> None:
        self._name = name
        self._age = age
        self._weight = weight

    def eat(self) -> None: ...
    def sleep(self) -> None: ...
    def make_sound(self) -> None: ...
    def move(self) -> None: ...

class Dog(Animal):
    def __init__(self, name: str, age: int, weight: float, breed: str) -> None:
        super().__init__(name, age, weight)
        self._breed = breed

    @property
    def breed(self) -> str:
        return self._breed

    def fetch(self) -> None: ...

What Is Happening?

class Dog(Animal) expresses the inheritance relationship: Dog is an Animal.
Animal defines the attributes and methods shared by all subclasses.
Dog declares only _breed and fetch(). Everything else is inherited.
super().__init__() delegates _name, _age, and _weight initialization to Animal.

Specialization

Specialization is the reverse: starting from a general base class and creating derived classes that extend or override its behavior for a specific context. It is a top-down design activity.

What Is Wrong With This Design?

Consider an Animal class that tries to accommodate every possible animal type in a single class:

Bloated Animal class with None-valued attributes — Fig. 19 **Design smell**: a bloated `Animal` class carrying `None` values for attributes that only apply to some subclasses.#

Does every animal have a wingspan?
Does every animal have a breed?
What do you set wingspan to for a Cat?
None values for inapplicable attributes are a design smell.
Adding a new animal type forces changes to a class that should not need to change.
The class becomes harder to maintain with every new animal type added.

Note

Specialization is the solution: keep shared attributes in Animal and push type-specific attributes down into dedicated subclasses. Each subclass extends the base with only what makes sense for that type.

After Specialization

Animal base class with Cat, Dog, and Bird specialized subclasses — Fig. 21 `Animal` specialized into `Cat`, `Dog`, and `Bird`, each extending the parent with only the attributes unique to that type (top-down approach).#

What Changed?

name, age, weight, eat(), sleep(), make_sound(), and move() live in Animal – every animal has them.
breed moves into Dog – only dogs have a breed.
wingspan and can_fly move into Bird – only birds have wings.
indoor_only moves into Cat – only cats have this attribute.
No subclass carries a None value for an attribute that does not apply to it.

Note

Each subclass extends Animal with only what makes it unique. Adding a Fish class tomorrow requires no changes to Dog, Cat, or Bird.

Types of Inheritance

Python supports four inheritance patterns:

Table 11 Types of inheritance in Python#
Type	Description	Example
Single	One child inherits from one parent	`Cat(Animal)`
Multi-level	A child inherits from a child	`Kitten(Cat(Animal))`
Multiple	One child inherits from several parents	`Liger(Lion, Tiger)`
Hierarchical	Several children share one parent	`Cat`, `Dog`, and `Bird` all inherit `Animal`

Single inheritance: one child extends one parent. Simple, predictable, and easy to follow. The recommended starting point.
Hierarchical inheritance: multiple children share one parent. Promotes code reuse and a consistent interface across subclasses.
Multi-level inheritance: a chain of inheritance across multiple levels. Useful for progressive specialization but deep chains are difficult to read and debug. Prefer shallow hierarchies.
Multiple inheritance: one child inherits from several parents. Powerful but introduces complexity around MRO and the diamond problem. Use with caution and prefer composition when possible.

Polymorphism#

The same interface, different behavior depending on the object.

Refer to L7_polymorphism.py to follow along with the examples below.

What Is Polymorphism?

Polymorphism (from Greek: poly = many, morphe = form) means that different objects respond to the same method call in their own way. The caller does not need to know the concrete type of the object – only that it supports the required interface.

Method overriding: a subclass provides its own implementation of an inherited method.

Duck typing: an object is compatible if it has the required methods, regardless of its class hierarchy.

Physical world examples

A remote control sends the same “play” signal to a TV, a DVD player, and a streaming device – each responds differently.
An on/off switch works on a lamp, a fan, and a heater – the same interface, different behavior.

Robotics Competition examples

perform_task("pick widget") on a MobileRobot triggers navigation; on a ManipulatorRobot it triggers arm extension – same call, different behavior.
make_sound() on a Cat prints “Meow”; on a Dog prints “Woof” – duck typing requires no shared base class.

Table 12 Duck typing vs. class-based polymorphism#
Duck Typing	Class-based Polymorphism
No shared base class required	Relies on a common base class or interface
Compatible if the method exists	Compatible if the class hierarchy matches
Checked at runtime	Can be checked statically
More flexible, less explicit	More explicit, better tooling support

Abstract Base Classes#

Defining interfaces that subclasses are required to implement.

Refer to L7_abstract_classes.py to follow along with the examples below.

Implementing an Abstract Class

A concrete class inherits from the abstract base and implements all abstract methods. If any abstract method is missing, Python raises TypeError at instantiation time – not at the point where the missing method is called.

UML Diagram

Abstract Animal with concrete Cat, Dog, and Bird subclasses — Fig. 29 Abstract `Animal` with concrete subclasses `Cat`, `Dog`, and `Bird`.#

Reading the Diagram

Animal carries a circled A and its name appears in italics, indicating it is abstract and cannot be instantiated.
make_sound() and move() appear in italics inside Animal, indicating they are abstract and must be overridden.
Cat, Dog, and Bird carry a circled C, indicating they are concrete and can be instantiated.
Each subclass provides its own implementation of make_sound() and move().
eat() and sleep() are concrete in Animal and inherited as-is by all subclasses.

Concrete and Abstract Methods Together

An abstract class can mix abstract and concrete methods. Concrete methods provide shared behavior inherited by all subclasses. Abstract methods enforce the interface each subclass must implement.

from abc import ABC, abstractmethod

class Animal(ABC):
    def __init__(self, name: str, age: int):
        self._name = name
        self._age = age

    @abstractmethod
    def make_sound(self) -> None: ...

    @abstractmethod
    def move(self) -> None: ...

    # concrete: shared by all
    def eat(self) -> None:
        print(f"{self._name} is eating")

    # concrete: shared by all
    def __repr__(self) -> str:
        return (f"{type(self).__name__}"
                f"(name={self._name!r}, age={self._age})")

class Cat(Animal):
    def make_sound(self) -> None:
        print(f"{self._name} says: Meow")

    def move(self) -> None:
        print(f"{self._name} walks gracefully")

if __name__ == '__main__':
    kitty = Cat("Kitty", age=3)
    kitty.eat()         # inherited from Animal
    kitty.make_sound()  # overridden in Cat
    kitty.move()        # overridden in Cat
    print(kitty)        # Cat(name='Kitty', age=3)

ABCs, Polymorphism, and Method Overriding

In the duck typing section, Cat and Dog defined make_sound() independently with no contract from Animal. Nothing prevented a developer from forgetting to implement it in a new subclass. ABCs solve this.

from abc import ABC, abstractmethod

class Animal(ABC):
    def __init__(self, name: str):
        self._name = name

    @abstractmethod
    def make_sound(self) -> None: ...  # contract: every subclass must override this

class Cat(Animal):
    def make_sound(self) -> None:      # overriding the abstract method
        print(f"{self._name} says: Meow")

class Dog(Animal):
    def make_sound(self) -> None:      # overriding the abstract method
        print(f"{self._name} says: Woof")

What Happens When You Forget

If a subclass does not implement all abstract methods, Python raises TypeError at instantiation time, not at the point where the missing method is called.

class Dog(Animal):
    def move(self) -> None:
        print(f"{self._name} runs")
    # make_sound() is NOT implemented -- forgot!

kitty = Cat("Kitty")   # OK
rex   = Dog("Rex")     # TypeError: Can't instantiate abstract class Dog
                       # without an implementation for abstract method 'make_sound'

Note

ABCs, method overriding, and polymorphism work together. The ABC defines what must exist. The subclass defines how it behaves. The polymorphic function uses the interface without knowing the concrete type.

Data Classes (FYI)#

Reducing boilerplate for data-centric classes.

Refer to L7_dataclasses.py to follow along with the examples below.

Frozen Data Classes

Setting frozen=True makes the data class immutable after creation. Python generates __hash__, making instances usable as dictionary keys or set members.

from dataclasses import dataclass

@dataclass(frozen=True)
class Animal:
    name: str
    age: int
    weight: float

kitty = Animal("Kitty", 3, 4.2)
print(kitty)
# Animal(name='Kitty', age=3, weight=4.2)

kitty.age = 4
# FrozenInstanceError: cannot assign to field 'age'

# Frozen instances are hashable
animal_set = {kitty, Animal("Rex", 5, 30.0)}
lookup = {kitty: "indoor cat"}
print(lookup[kitty])   # indoor cat

What does frozen=True do?

Prevents any field from being modified after creation.
Any attempt to assign to a field raises FrozenInstanceError.
Automatically generates __hash__, making the instance usable as a dictionary key or set member.

When to use frozen data classes:

Records that should never change after creation (sensor readings, event logs, configuration snapshots).
Objects used as dictionary keys or stored in sets.
Anywhere immutability is a design requirement.

Note

A regular @dataclass sets __hash__ to None by default (making it unhashable) because mutable objects should not be hashed. frozen=True restores hashability safely.

Table 13 Data class vs. regular class decision guide#
Situation	Use `@dataclass`	Use regular class
Primary purpose	Storing data fields	Complex behavior and logic
Attribute access	Direct field access	Validated via `@property`
Immutability	`frozen=True`	`@property` with no setter
Inheritance	Simple hierarchies	Deep or complex hierarchies
Encapsulation	Not a priority	Central design concern

Animal Domain Example

Use @dataclass for AnimalRecord (name, species, date of birth, weight at intake): pure data, no behavior.
Use a regular class for Animal with @property for weight (validated, cannot be negative) and methods like make_sound() and move().
A frozen data class suits an ObservationLog entry: timestamp, observer name, species, notes – write once, never modify.

`slots` (FYI)#

Restricting attributes and reducing memory overhead.

Refer to L7_slots.py to follow along with the examples below.

Protocols (FYI)#

Structural subtyping without inheritance.

Refer to L7_protocols.py to follow along with the examples below.

What Is a Protocol?

A typing.Protocol defines an interface through structural subtyping: a class satisfies the Protocol simply by having the required methods and attributes, without needing to inherit from it. This is sometimes called “static duck typing” – the flexibility of duck typing with the explicitness of type annotations.

Nominal typing (ABCs): compatibility declared explicitly via inheritance.

Structural typing (Protocols): compatibility determined by structure alone.

Physical world examples

A USB port accepts any device that fits the connector and speaks the protocol – no registration required.
A power outlet accepts any plug of the right shape – the appliance does not need to be certified by the outlet manufacturer.

Robotics Competition examples

An Executable Protocol requires execute(robot_name) -> bool. Both PickTask and DeliverTask satisfy it without inheriting from anything.
A Loggable Protocol requires log_status() -> str. Any class that has that method qualifies – no shared base class needed.

Table 14 ABCs (nominal typing) vs. Protocols (structural typing)#
Aspect	ABC (Nominal)	Protocol (Structural)
Declaration	Must inherit from the ABC	No inheritance required
Enforcement	At instantiation time	At type-check time (`mypy`)
Runtime check	`isinstance()` always works	Needs `@runtime_checkable`
Flexibility	Tight coupling	Loose coupling
Best for	Shared base behavior	Independent implementations

Note

typing.Protocol was introduced in Python 3.8 (PEP 544). It is the preferred way to express interfaces in modern Python when you do not want to require explicit inheritance.

ABCs vs. Protocols – Decision Guide

Choose an ABC when…	Choose a Protocol when…
Subclasses share concrete behavior (inherited methods with a body)	Unrelated classes satisfy the same interface
You want enforcement at instantiation time (`TypeError`)	You prefer loose coupling across module or library boundaries
You control all implementing classes	You do not control the implementing classes
Nominal typing fits your design	Structural typing (“duck typing with annotations”) fits better

Lecture#

Class Methods and Static Methods#

Object Relationships#

Inheritance#

Polymorphism#

Abstract Base Classes#

Data Classes (FYI)#

__slots__ (FYI)#

Protocols (FYI)#

This Page

`slots` (FYI)#