Inheritance
Build parent–child class hierarchies that reuse common behaviour while adding specialized state or methods.
Reuse common behaviour without copying it
- explain parent/child class hierarchies;
- apply inheritance to reuse and extend functionality;
- construct Python subclasses using inherited members and
super(); - explain how public, protected, private and default access affect inherited members conceptually.
Rapid Recall Deck
Attempt each card first. If a term is new, flip and study it, then answer it again without looking. Mark only secure recall as “Know it”.
Parent behaviour becomes reusable child behaviour
class Employee:
def __init__(self, name, department):
self.name = name
self._department = department
def describe(self):
return self.name + " works in " + self._department
class Manager(Employee):
def __init__(self, name, department, team_size):
super().__init__(name, department)
self.team_size = team_size
def describe_team(self):
return self.name + " manages " + str(self.team_size) + " people"Trace inherited state
For m = Manager("Ari", "IT", 6), identify which attributes are initialized by the parent constructor and which are added by the child.
name and _department are initialized by Employee.__init__ through super(). team_size is added by the Manager constructor.
Explain the reuse
Why is inheritance preferable here to copying the Employee constructor and describe() code into Manager?
Shared behaviour is defined once in the parent, reducing duplication and making later changes easier to maintain consistently across child classes.
Construct a child class that extends a parent
Vehicle with brand and speed. Create a child class ElectricCar that also stores battery. The child must reuse the parent constructor.Construct the hierarchy
class Vehicle:
def __init__(self, brand, speed):
self.brand = brand
self.speed = speed
class ElectricCar(Vehicle):
def __init__(self, brand, speed, battery):
super().__init__(brand, speed)
self.battery = batteryInheritance does not erase visibility rules
Access concepts
- Public: broadly accessible; plain Python names usually signal public use.
- Protected: intended for class/subclass use; Python commonly signals this with a leading underscore.
- Private: intended to be restricted to the defining class; Python may use stronger private intent/name mangling with
__name. - Default/package: a language-dependent access level; Python has no direct package-private modifier.
Reason about inheritance
A parent stores public_name, _department and __secret_code. Which should a child class normally use directly?
The public member is intended for normal access. The leading-underscore member is intended for internal/subclass use, so a child may use it deliberately. The double-underscore member is intended to remain private to the defining class and is name-mangled; the child should rely on a parent-provided interface instead of direct access.
Use inheritance only for a genuine hierarchy
Is-a test
For each relationship, decide whether inheritance is appropriate and explain why: Teacher–Person, Car–Engine, PremiumAccount–Account.
- Teacher–Person: suitable inheritance; a teacher is a person.
- Car–Engine: not inheritance; a car has an engine rather than being an engine.
- PremiumAccount–Account: suitable inheritance if premium account is a specialized type of account.
Teacher-created Paper 2 practice
Paper 2 mini-set
1. Explain how inheritance promotes code reusability.
2. Assume the parent class below already exists. Construct a child class OnlineCourse that reuses the parent constructor and adds platform.
class Course:
def __init__(self, title):
self.title = title
3. Explain why a private parent attribute should normally be accessed through a parent-provided method rather than directly by a child.
- Common code is written once in the parent and reused/extended by child classes, reducing duplication and improving maintenance.
class OnlineCourse(Course): def __init__(self, title, platform): super().__init__(title) self.platform = platform- Private state is intended to be controlled by the defining class; using its interface preserves encapsulation and avoids dependence on hidden implementation details.
Can you justify the relationship?
Exit check
Complete the design statement: “Use inheritance when …; do not use inheritance when …”
Use inheritance when the child is a specialized type of the parent and should reuse/extend common behaviour; do not use it merely because one object contains or uses another object.
Finish the learning cycle
IA — main task
Continue Criterion D implementation/testing. If your solution contains a real parent–child hierarchy, document why inheritance reduces duplication; otherwise do not add it artificially.
Paper 2 — short practice
Rebuild the Vehicle/ElectricCar hierarchy and explain public/protected/private/default access concepts from memory.