This subject knowledge enhancement day brought the PGCE computing trainees together for a full day focused on two advanced programming paradigms - object-oriented programming (OOP) and an introduction to functional programming (FP) - with an afternoon session from Mark Campbell of Ada College covering Level 3 computing pathways beyond A-level. The day opened with a brief discussion of Ofsted’s interest in how the programme supports trainees’ subject knowledge development, which set the tone for the session.

Object-Oriented Programming

The morning centred on OOP, beginning with a frank conversation about trainees’ confidence. Most had studied computer science to degree level, but several acknowledged that OOP had not featured prominently in their own education or, where it had, the examples used felt disconnected from genuine computational problems. The typical classroom staples - cat as a subclass of animal, car as a subclass of vehicle - were discussed as a shared frustration: while they illustrate inheritance syntactically, they offer little sense of why OOP matters in practice.

The session opened the conceptual discussion with Scratch, which several trainees are already using in their placements. Miles pointed out that Scratch sprites are, in a meaningful sense, objects: clicking on a sprite in the Scratch interface reveals its properties (x position, y position, direction, size, visibility), and the blocks that act on it are its methods. This gave trainees an accessible bridge between something familiar and the more formal vocabulary of OOP, though it also surfaced the challenge of moving pupils from Scratch’s event-driven, concurrent style back to the sequential procedural model of early Python.

The first live-coded worked example was a Fractions class in Python, built from scratch to demonstrate the core OOP concepts before introducing any animation. A class was defined with a constructor that took a numerator and denominator, storing them as instance variables using dot notation (self.num, self.denom). A __str__ method was added so that printing a fraction object produced a readable output, and a greatest common factor calculation was incorporated into the constructor to reduce fractions automatically - so passing in four-sixths would store and display two-thirds. The class was then extended with operator overloading: by defining dunder methods (__mul__, __add__), Python can be taught to multiply and add fraction objects using the standard * and + operators. This is polymorphism in action - the + operator already knows how to add integers, floats, and strings; defining __add__ on the Fraction class means it now knows how to add fractions too, with the same symbol behaving differently depending on the type of object it is called on. Trainees debated what should properly count as polymorphism, noting a gap between the broader conceptual definition and the specific examples OCR rewards in examinations.

def gcf(a,b):
    if b == 0:
        return a
    else:
        return gcf(b, a % b)

class Fraction:
    def __init__(self,a,b=1):
        self.num = a // gcf(a,b)
        self.den = b // gcf(a,b)
    def __repr__(self):
        return "Fraction("+str(self.num)+", "+str(self.den)+")"
    def __str__(self):
        if self.den==1:
            return str(self.num)
        else: 
            return str(self.num)+"/"+str(self.den)
    def __add__(self,other):
        newNum=self.num*other.den+other.num*self.den
        newDen=self.den*other.den
        return Fraction(newNum,newDen)
    def __sub__(self,other):
        return self+Fraction(-other.num,other.den)
    def __mul__(self,other):
        newNum=self.num*other.num
        newDen=self.den*other.den
        return(Fraction(newNum,newDen))
    def __truediv__(self,other):
        return self*Fraction(other.den,other.num)
    def __float__(self):
        return self.num / self.den
    def __lt__(self,other):
        return (self.num*other.den<other.num*self.den)
    def __eq__(self,other):
        return (self.num*other.den==other.num*self.den)
    def __gt__(self,other):
        return (self.num*other.den>other.num*self.den)
    def __le__(self,other):
        return (self.num*other.den<=other.num*self.den)
    def __ge__(self,other):
        return (self.num*other.den>=other.num*self.den)

With the core ideas established through fractions, the session moved to a pandemic simulation as a richer worked example using the P5.js library (via its Raspberry Pi Python port). A Ball class was constructed with properties for position (x, y) and velocity (vx, vy), a draw method to render the ball on screen, and a move method containing boundary-checking logic to make it bounce off screen edges. This gave a further illustration of encapsulation: the internal state of each ball object is managed entirely within the class, and the rest of the programme simply calls its methods without needing to know how they are implemented.

Fifteen ball instances were then created by appending new Ball objects to a list inside a loop, each initialised with random position and velocity using random.uniform. This generated the live-coded debugging that trainees found instructive - a sign error in the bounce condition caused the ball to stick to a wall rather than reflect, and working through this in public modelled the kind of ‘deliberate’ mistake-finding that trainees can use in their own lessons. Miles noted that live coding with an ‘intentional’ bug inserted is a useful classroom technique: it gives pupils the experience of reading and diagnosing code rather than just writing it.

Inheritance was then introduced by extending the Ball class to create a Person class, carrying forward the movement behaviour while adding a new property representing infection status. This gave a genuinely computational motivation for inheritance: the Person class reuses all the physics of a bouncing ball without duplicating code, and adds only what is specific to modelling disease spread. The broader argument - made with reference to Michael Kölling’s work at King’s - was that OOP is harder to learn if pupils have already internalised a purely imperative model, and that there is a case for introducing it earlier than many schools currently do.

class Ball:
    def __init__(self, x, y, vx, vy):
        self.x = x
        self.y = y
        self.vx = vx
        self.vy = vy
    def show(self):
        circle(self.x, self.y, radius)
    def move(self):
        self.x = self.x + self.vx
        self.y = self.y + self.vy
        if self.x < 0 or self.x > width:
            self.vx = - self.vx
        if self.y < 0 or self.y > height:
            self.vy = - self.vy
    def getDist2(self, other):
        return (self.x-other.x)**2 + (self.y-other.y)**2

class Person(Ball):
    def __init__(self, x, y, vx, vy, status):
        super().__init__(x, y, vx, vy)
        self.status = status
    def show(self):
        fill(status_colour[self.status])
        super().show()
    def setStatus(self, status):
        self.status = status
    def getStatus(self):
        return self.status

One recurring pedagogical theme across the OOP discussion was the difficulty of anticipating student misconceptions in topics that feel second nature to experienced programmers. A trainee raised this directly, and the discussion drew a distinction between difficulty (students finding something hard) and misconception (students approaching a problem with a fundamentally incorrect mental model). Trainees were encouraged to use generative AI as a starting point for identifying common programming misconceptions, and a relevant research paper on the topic was flagged for follow-up. The National Centre for Computing Education’s A-level materials were recommended as the most reliable classroom resource for OOP, written specifically with sixth-form teaching in mind.

Functional Programming

The afternoon included an introduction to functional programming. Given the time available, this was treated as an orientation rather than a full treatment. The session introduced the idea of functions as first-class values, with map, filter, and reduce as the core higher-order functions. Pure functions and immutability were framed as the key conceptual differences from the imperative and OOP styles trainees had been working with all morning. Haskell was used briefly to illustrate the syntax, and a preview was given of Liberator - a browser-based visual programming environment built around the idea of wiring functional blocks together, designed to make Haskell accessible to school-age learners.

Level 3 Qualifications - Guest Session with Mark Campbell, Ada College

Mark Campbell, Vice Principal at Ada, the National College for Digital Skills, joined the session to give trainees a picture of Level 3 computing provision outside A-level. Ada is a specialist sixth-form college focusing on computing and digital skills, with strong industry partnerships including Accenture, Bank of America, and others. Mark described how Ada’s curriculum is structured around the BTEC Level 3 Diploma in Computing - equivalent to two A-levels - which all students take alongside a third A-level chosen from a deliberately narrow set of options: psychology, business studies, or graphics. This structure creates distinct learner pathways (innovators, combining computing with business or psychology; creators, combining computing with graphics), each oriented towards different destinations in the technology sector.

Mark described Ada’s approach to employability as integral to the curriculum rather than bolt-on. Industry partners set authentic project briefs three times a year, with students working in cross-disciplinary teams to deliver against them - a recent example involved 130 students visiting Bank of America to work on a data analytics task using Python, Pandas, and Matplotlib. Industry coaches also meet with individual students monthly. Mark emphasised that the technology sector is broad, and that Ada’s graduates move into roles ranging from software development to UX, cybersecurity, and consultancy. The session prompted discussion about the relationship between vocational and academic computing qualifications, and about how trainees working in schools might encounter students who would be better served by a BTEC or T-level pathway than by A-level Computer Science.

Based on the 17th Roehampton Computing Education lecture, A Level Topics, 18 March 2026