OOP for multiple classes: inheritance, polymorphism, abstraction, composition, design patterns (HL) – IB Computer Science exam questions with mark scheme

1StandardHL only5 marks

Consider the program below.

class Vehicle:
    def __init__(self, reg, wheels=4):
        self.reg = reg
        self.wheels = wheels

    def describe(self):
        return self.reg + " has " + str(self.wheels) + " wheels"

class Motorbike(Vehicle):
    def __init__(self, reg):
        super().__init__(reg, 2)
        self.sidecar = False

    def describe(self):
        return super().describe() + " and no sidecar"

v = Vehicle("AB12")
m = Motorbike("XY99")
print(v.describe())
print(m.describe())
print(isinstance(m, Vehicle))

(a) State the output of the program. [3]

(b) Identify the method, other than the constructor __init__, that is overridden in Motorbike. [1]

(a) AB12 has 4 wheels(1)
XY99 has 2 wheels and no sidecar(1)
True(1)
(b) describe(1)
(c) Calls the superclass constructor so the inherited attributes (reg and wheels) are initialised, here with wheels set to 2(1)
Answer: (a) AB12 has 4 wheels / XY99 has 2 wheels and no sidecar / True (b) describe (c) runs Vehicle's constructor
Examiner tip: Boolean outputs are written as True with a capital T.

2StandardHL only4 marks

Consider the program below.

import math

class Shape:
    def area(self):
        return 0

class Circle(Shape):
    def __init__(self, r):
        self.r = r
    def area(self):
        return math.pi * self.r ** 2

class Rectangle(Shape):
    def __init__(self, w, h):
        self.w = w
        self.h = h
    def area(self):
        return self.w * self.h

for s in [Circle(3), Rectangle(4, 5)]:
    print(type(s).__name__ + ": " + format(s.area(), ".2f"))

(a) State the output. [2]

(b) Define the term polymorphism. [1]

(a) Circle: 28.27(1)
Rectangle: 20.00(1)
(b) The ability of different classes to provide their own version of the same method, so objects can be treated through a common interface/name (accept 'one interface, many forms' / 'the same method call behaves differently depending on the object's class'; reject 'many forms' alone)(1)
(c) The same call s.area() runs the Circle version for one object and the Rectangle version for the other, chosen at run time according to the object's class (accept: each subclass overrides area from Shape, so the one call in the loop gives different behaviour; do not award 'the classes override area' with no link to the call in the loop)(1)
Answer: (a) Circle: 28.27 / Rectangle: 20.00 (b) same method name, different behaviour per class (c) one call s.area() runs a different overridden version for each object
Examiner tip: In (c) say that one call produces different behaviour depending on the object type.

3HardHL only6 marks

A library system uses the class diagram shown. Item is implemented as:

class Item:
    def __init__(self, title, item_id):
        self.title = title
        self.item_id = item_id

    def late_fee(self, days_late):
        return 0.10 * days_late

Book and DVD are subclasses of Item. A DVD costs £0.50 per day late; an ordinary Item costs £0.10 per day late.

(a) State the superclass and identify one attribute that a DVD object inherits. [2]

(b) Write the class DVD, including its constructor and a version of late_fee that charges £0.50 per day. [4]

(a) Superclass is Item(1)
An inherited attribute: title or item_id(1)
(b) class DVD(Item): – inherits from Item(1)
Constructor with title, item_id and duration that calls super().__init__(title, item_id) (allow Item.__init__(self, title, item_id))(1)
Sets self.duration = duration(1)
late_fee(self, days_late) overrides the superclass method and returns 0.50 * days_late (accept 0.5)(1)

Answer: (a) Item; title or item_id. (b)

class DVD(Item):
    def __init__(self, title, item_id, duration):
        super().__init__(title, item_id)
        self.duration = duration

    def late_fee(self, days_late):
        return 0.50 * days_late

Examiner tip: Call super().__init__ for inherited attributes instead of re-assigning them; override with the same method name and parameters.

Stuck on OOP for multiple classes: inheritance, polymorphism, abstraction, composition, design patterns (HL)?

Get it sorted in a free 30-minute session

We work through your weakest questions on this topic on Zoom. I reply the same day.

Free 30-min session on this topic Send me 5 questions a day

4StandardHL only6 marks

A bank's software is written in Java. The class Account is in the package bank:

package bank;

public class Account {
    private double balance;
    protected String owner;
    int branchCode;

    public String getOwner() {
        return owner;
    }
}

A programmer writes a subclass LoanAccount in a different package, loans:

package loans;
import bank.Account;

public class LoanAccount extends Account {
    void test() {
        owner = "Ana";        // Statement A
        balance = 0;          // Statement B
        branchCode = 12;      // Statement C
        getOwner();           // Statement D
    }
}

(a) For each of Statements A, B, C and D, state whether it compiles, giving the access modifier that decides this. [4]

(b) The programmer needs LoanAccount to reduce the balance when a repayment is taken. Without changing balance from private, outline how Account could be changed so that this is possible, and state one benefit of this approach. [2]

(a) A compiles: owner is protected, so it is accessible in a subclass even in another package(1)
B does not compile: balance is private, so it is accessible only inside Account(1)
C does not compile: branchCode has default (package-private / no modifier) access, so it is visible only within package bank; being a subclass does not help(1)
D compiles: getOwner is public(1)
(b) Add a public (or protected) method to Account, e.g. withdraw(double amount) / setBalance, that changes balance; LoanAccount calls this method (accept a mutator/setter)(1)
Benefit: encapsulation is kept, so the method can validate the change (e.g. reject a negative amount or an overdrawn balance) / Account controls how its data is changed (accept data hiding / internal representation can change without affecting subclasses)(1)
Answer: A compiles (protected); B fails (private); C fails (default, different package); D compiles (public). (b) add a public/protected mutator such as withdraw() that validates and updates balance.
Examiner tip: Default access is package access, not subclass access: a subclass in another package cannot see a default member.

5CoreHL only5 marks

The UML class diagram shows part of a hotel booking system. Relationship P links Hotel and Room; relationship Q links Hotel and Guest.

(a) Identify the type of relationship shown by P and the type shown by Q. [2]

(b) With reference to rooms and guests, explain the difference between these two relationships when a Hotel object is deleted. [2]

(a) P: composition (filled diamond)(1)
Q: aggregation (hollow / unfilled diamond)(1)
(b) Rooms are owned by / part of the hotel and cannot exist independently, so the Room objects are destroyed / deleted with the Hotel(1)
Guests exist independently of the hotel (they can stay at other hotels), so the Guest objects continue to exist / are not deleted when the Hotel is deleted(1)
(c) A room is not a type of hotel / the relationship is "has-a" not "is-a"; inheritance models "is-a" (accept: Room would wrongly inherit Hotel's attributes/methods such as name)(1)
Answer: (a) P composition, Q aggregation. (b) Rooms are destroyed with the hotel; guests continue to exist. (c) A room is not a kind of hotel: has-a, not is-a.
Examiner tip: Learn the diamonds: filled = composition (parts die with the whole), hollow = aggregation (parts live on).

6StandardHL only7 marks

Consider the Java class below.

public class Printer {
    static String show(int x)        { return "int " + (x * 2); }
    static String show(double x)     { return "double " + (x / 2); }
    static String show(String s)     { return "String " + s.length(); }
    static String show(int x, int y) { return "two ints " + (x + y); }

    public static void main(String[] args) {
        System.out.println(show(7 / 2));
        System.out.println(show(7.0));
        System.out.println(show("seven"));
        System.out.println(show(3, 4));
    }
}

(a) State the output when main is run. [4]

(b) Explain why method overloading is described as static (compile-time) polymorphism. [2]

(c) A programmer adds the method static int show(int x) { return x; } to the class. State why the class will no longer compile. [1]

(a) int 6 (7 / 2 is integer division giving 3)(1)
double 3.5(1)
String 5(1)
two ints 7(1)
(b) The method to run is chosen by the compiler from the method signature / the number and types of the arguments(1)
before the program runs, so the decision is fixed at compile time (not by the object type at run time, as with overriding)(1)
(c) It has the same signature (name and parameter list) as the existing show(int x); a different return type alone is not enough to overload (accept: method already defined)(1)
Answer: (a) int 6 / double 3.5 / String 5 / two ints 7 (b) the compiler picks the version from the argument list before run time (c) same name and parameter types; return type alone does not distinguish overloads.
Examiner tip: 7 / 2 in Java is integer division: the int version runs and prints int 6, not double 1.75.

7HardHL only9 marks

A payroll program uses an abstract class.

from abc import ABC, abstractmethod

class Employee(ABC):
    def __init__(self, name):
        self.name = name

    @abstractmethod
    def monthly_pay(self):
        pass

    def payslip(self):
        return self.name + ": " + format(self.monthly_pay(), ".2f")

class Salaried(Employee):
    def __init__(self, name, salary):
        super().__init__(name)
        self.salary = salary

    def monthly_pay(self):
        return self.salary / 12

class Hourly(Employee):
    def __init__(self, name, hours, rate):
        super().__init__(name)
        self.hours = hours
        self.rate = rate

    def monthly_pay(self):
        return self.hours * self.rate

staff = [Salaried("Rao", 30000), Hourly("Kim", 82, 12.5)]
for e in staff:
    print(e.payslip())

(a) State the output of the program. [2]

(b) Explain why the statement Employee("Lee") would cause an error. [2]

(d) A Contractor is paid a fixed rate for each day worked in the month. Construct the class Contractor, with a constructor taking name, days and day_rate. [3]

(a) Rao: 2500.00(1)
Kim: 1025.00 (both lines with 2 d.p.; ignore spacing)(1)
(b) Employee is an abstract class / contains an abstract method (monthly_pay) with no implementation(1)
so it cannot be instantiated; only a concrete subclass that implements every abstract method can be (accept: TypeError is raised)(1)
(c) The abstract class guarantees / forces every subclass to implement monthly_pay (a common interface)(1)
so payslip can call self.monthly_pay() and the overriding version for the actual object type runs at run time (dynamic binding / polymorphism)(1)
(d) class Contractor(Employee): header inheriting from Employee(1)
Constructor calls super().__init__(name) (allow Employee.__init__(self, name)) and stores days and day_rate as attributes(1)
Implements monthly_pay(self) returning self.days * self.day_rate (do not award if named differently, as the abstract method would not be implemented)(1)
Answer: (a) Rao: 2500.00 / Kim: 1025.00 (b) abstract class with an unimplemented abstract method cannot be instantiated (c) every subclass must provide monthly_pay, so payslip calls it polymorphically (d) subclass of Employee calling super().__init__(name), storing days and day_rate, monthly_pay returns days*day_rate.
Examiner tip: In (d) the method must have exactly the abstract method's name, monthly_pay; any other name leaves the class abstract.

8StandardHL only7 marks

A program uses the singleton design pattern for a logger.

class Logger:
    _instance = None

    @staticmethod
    def get_instance():
        if Logger._instance is None:
            Logger._instance = Logger()
        return Logger._instance

    def __init__(self):
        self.lines = []

    def log(self, msg):
        self.lines.append(msg)
        return len(self.lines)

a = Logger.get_instance()
b = Logger.get_instance()
print(a.log("start"))
print(b.log("load"))
print(a is b)
print(len(a.lines))

(a) State the output of the program. [3]

(b) Explain the purpose of the singleton design pattern, with reference to this program. [2]

(c) Another programmer writes c = Logger(). Outline why this shows a weakness in this implementation of the pattern. [1]

(d) State one disadvantage of using the singleton pattern. [1]

(a) 1 then 2 (both needed)(1)
True(1)
2(1)
(b) Ensures that only one instance of the class can be created / exists(1)
and provides a single global point of access (get_instance), so every part of the program writes to the same log (a and b refer to the same object)(1)
(c) Calling the constructor directly creates a second, separate Logger object (with an empty list), bypassing get_instance; the constructor should be private (as in Java) but Python cannot enforce this(1)
(d) Any one: it introduces global state, so hidden dependencies between parts of the program; harder to unit test / mock; can be a bottleneck or need locking in multi-threaded code; breaks single-responsibility (manages own creation)(1)
Answer: (a) 1 / 2 / True / 2 (b) one instance only with a global access point, so a and b share one log (c) Logger() makes a second object; constructor not private (d) e.g. global state makes testing harder.
Examiner tip: Students often say b.log returns 1 because b is a 'new' logger; get_instance returns the existing object.

9HardHL only8 marks

A program uses the observer design pattern.

class WeatherStation:
    def __init__(self):
        self.observers = []

    def attach(self, obs):
        self.observers.append(obs)

    def detach(self, obs):
        self.observers.remove(obs)

    def set_temp(self, t):
        for obs in self.observers:
            obs.update(t)

class Display:
    def __init__(self, name):
        self.name = name

    def update(self, t):
        print(self.name + " shows " + str(t))

class Alarm:
    def __init__(self, limit):
        self.limit = limit

    def update(self, t):
        if t > self.limit:
            print("ALARM " + str(t))

s = WeatherStation()
hall = Display("Hall")
lab = Display("Lab")
alarm = Alarm(30)
s.attach(hall)
s.attach(alarm)
s.set_temp(28)
s.attach(lab)
s.set_temp(31)
s.detach(hall)
s.set_temp(30)

(a) State the output of the program. [4]

(b) Identify the subject in this program. [1]

(d) A Logger class must also be notified of every new temperature. Explain one advantage of the observer pattern when adding this feature. [2]

(a) Hall shows 28 (only line from first call; no alarm since 28 is not over 30)(1)
Hall shows 31 then ALARM 31 (in this order)(1)
Lab shows 31 (after ALARM 31, as lab was attached last)(1)
Lab shows 30 only for the final call: Hall has been detached and no alarm as 30 is not > 30(1)
(b) WeatherStation / the object s(1)
(c) Both classes provide an update(t) method; the station calls update on each observer and the version belonging to the object's own class runs (polymorphism / duck typing / common interface)(1)
(d) The WeatherStation class does not need to be changed: a Logger class with an update method is written and attached at run time(1)
because the subject is loosely coupled to its observers / only knows they have update, not their concrete classes, so the change is less likely to introduce errors (accept: observers can be added or removed dynamically)(1)
Answer: (a) Hall shows 28 / Hall shows 31 / ALARM 31 / Lab shows 31 / Lab shows 30 (b) WeatherStation (c) every observer has update(t), called polymorphically (d) no change to WeatherStation; Logger just implements update and is attached: loose coupling.
Examiner tip: Watch the order of the observer list and the strict > test: 30 is not greater than 30, so the last call prints no alarm.

10StretchHL only10 marks

A game contains the following classes.

class Enemy:
    def __init__(self, level):
        self.level = level
    def health(self):
        return 0

class Goblin(Enemy):
    def health(self):
        return 20 * self.level

class Troll(Enemy):
    def health(self):
        return 50 * self.level

class Dragon(Enemy):
    def health(self):
        return 200 + 40 * self.level

Enemies are created from text in a level file, such as "troll". The developers decide to use the factory design pattern.

(a) Construct a class EnemyFactory with a static method create(kind, level) that returns a Goblin, Troll or Dragon object of the given level for the strings "goblin", "troll" and "dragon", and raises a ValueError for any other string. [4]

(b) State the output of this code, which uses your factory. [1]

wave = ["goblin", "troll", "dragon", "goblin"]
total = 0
for k in wave:
    total = total + EnemyFactory.create(k, 3).health()
print(total)

(c) Explain one advantage of creating enemies through EnemyFactory rather than calling the constructors throughout the game code. [2]

(d) Some goblins, trolls and dragons must be able to fly. One developer proposes new subclasses FlyingGoblin, FlyingTroll and FlyingDragon. Another proposes that each Enemy holds a Movement object (for example Walk or Fly) and delegates movement to it. Evaluate the two proposals. [3]

(a) Class EnemyFactory with a static method create(kind, level) (accept @staticmethod or @classmethod; in Java public static Enemy create(String kind, int level))(1)
Selection on kind (if/elif or a dictionary lookup) for the three strings(1)
Returns a new object of the matching subclass, passing level (e.g. return Troll(level))(1)
Raises ValueError for any other string (accept else: raise ValueError(...); in Java accept throw new IllegalArgumentException)(1)
(b) 590 (60 + 150 + 320 + 60)(1)
(c) Object creation is in one place, so the rest of the game depends only on Enemy / the client is decoupled from the concrete subclasses(1)
so adding a new enemy type (e.g. Orc) or changing how one is built needs a change only in the factory, not in every place enemies are created (accept: data-driven creation from the level file strings in one place)(1)
(d) Subclass proposal: causes a class explosion: a subclass is needed for every combination (3 enemies × 2 movement types = 6 classes, growing multiplicatively), with duplicated flying code(1)
Composition proposal: one Fly class is reused by every enemy type, so new movement types or enemies add only one class each (models "has-a" movement); movement can also be swapped at run time (e.g. a dragon that lands)(1)
Judgement: composition is the better design here, though subclasses are simpler if very few combinations will ever be needed / composition adds an extra object and delegation (award for a reasoned conclusion that weighs both)(1)

Answer: (a) see model:

class EnemyFactory:
    @staticmethod
    def create(kind, level):
        if kind == "goblin":
            return Goblin(level)
        elif kind == "troll":
            return Troll(level)
        elif kind == "dragon":
            return Dragon(level)
        else:
            raise ValueError("Unknown enemy: " + kind)

(b) 590 (c) creation centralised; client coupled only to Enemy, new types change only the factory (d) subclasses multiply (3×2) and duplicate code; composition reuses Fly and allows run-time change: composition preferred.

Examiner tip: In (d) an evaluation needs a conclusion: say which design is better and why, not just describe both.

Stuck on this topic?

Book a free 30-minute session on WhatsApp and we'll find exactly which step is costing you the marks. Or build a timed paper on it.

Free 30-minute session