Programming Paradigms

A programming paradigm is a style or approach to programming — a particular way of structuring and writing a program to solve a problem. It is not a language: one language (such as Python) can support several paradigms.

The 9618 A-Level syllabus covers four paradigms:

Paradigm	Core idea	What you describe
Low-level	assembly / machine code, close to the hardware	exact instructions + addressing modes
Imperative / procedural	a sequence of commands that change state	HOW — step by step
Object-oriented (OOP)	model the problem as interacting objects	the objects, their data and behaviour
Declarative	state facts and rules, query a goal	WHAT is true — the system infers

A useful contrast runs through the whole topic: imperative and low-level code says HOW to do something (the exact steps), whereas declarative code says WHAT is true and lets the system work out the how.

Low-level programming is written close to the hardware in assembly language (mnemonics like LDD, ADD) or in machine code. Instructions map almost one-to-one onto the processor's operations and registers, so low-level code is fast and gives precise hardware control — but it is hard to write and not portable between processor types.

Each instruction must find the data it works on (the operand). The rule for locating that operand is the addressing mode (also met in Topic 4):

Addressing mode	How the operand is found
Immediate	the actual value is given in the instruction itself
Direct	the instruction gives the address that holds the operand
Indirect	the instruction's address holds another address that holds the operand
Indexed	the instruction's address is added to an index register (to step through arrays/tables)
Relative	the address is given relative to the program counter (current position)

The most-tested distinction is direct vs indirect: direct needs one memory access, indirect needs two (the first address points to a second).

In the imperative (procedural) paradigm a program is a sequence of commands that are executed in order and that change the program's state by altering the values held in variables. You specify HOW the task is carried out, step by step.

Its building blocks (covered in Topic 11) are:

• Variables that hold and change values (state).
• The three basic constructs: sequence, selection (IF / CASE) and iteration (loops).
• Procedures and functions — named, reusable blocks of code, so the program is modular and avoids repetition.

A short procedural example:

Total ← 0
FOR Index ← 1 TO 5
   Total ← Total + Index
NEXT Index
OUTPUT Total

Here Total is a variable whose value (the state) changes on each pass of the loop — exactly the imperative idea of commands updating state.

Object-oriented programming (OOP) models a problem as a set of objects that interact. The full 9618 vocabulary:

• Class — a template/blueprint defining the attributes and methods objects of that type will have.
• Object — an instance of a class (a specific item created from the template, with its own data). Creating an object is instantiation.
• Attribute (property) — a data item stored in an object (its state).
• Method — a procedure or function inside a class that acts on the object's data.
• Encapsulation — bundling data + methods in one class; attributes kept PRIVATE, accessed only via getters and setters, so the class controls and protects its own data.
• Getter — a public method that returns a private attribute's value. Setter — a public method that changes a private attribute's value (often validating first).
• Inheritance — a subclass is derived from a superclass and gains its attributes and methods.
• Polymorphism — the same method name behaves differently per class (via overriding).
• Aggregation / containment — one object contains other objects (a 'has-a' relationship, e.g. a Car has Wheels).

A class is often drawn as a box with three parts — name, attributes, methods — and inheritance as an arrow from a subclass up to its superclass:

Designing classes to solve a problem. Read the scenario, list the nouns (candidate classes/attributes) and the actions (candidate methods), decide which data is shared (put it in a superclass), and which is specific (put it in subclasses). In Cambridge pseudocode:

CLASS Animal
   PRIVATE Name : STRING
   PUBLIC PROCEDURE NEW(GivenName : STRING)
      Name ← GivenName
   ENDPROCEDURE
   PUBLIC FUNCTION GetName() RETURNS STRING
      RETURN Name
   ENDFUNCTION
   PUBLIC PROCEDURE SetName(NewName : STRING)
      Name ← NewName
   ENDPROCEDURE
ENDCLASS

CLASS Dog INHERITS Animal
   PRIVATE Breed : STRING
ENDCLASS

Pet ← NEW Dog("Rex")
OUTPUT Pet.GetName()

Note the conventions: CLASS...ENDCLASS, visibility PRIVATE/PUBLIC, the constructor PROCEDURE NEW, the assignment operator ←, getters as FUNCTION...RETURNS...RETURN, INHERITS for a subclass, NEW to create an object, and object.Method() to call a method.

The power of OOP comes from how classes relate to one another.

Inheritance ('is-a'). A subclass is derived from a superclass with CLASS Dog INHERITS Animal. The subclass automatically gains the superclass's attributes and methods, then adds its own or overrides inherited ones. A Dog is an Animal. Benefit: common code is written once and reused, reducing duplication and easing maintenance.

Polymorphism. The same method name behaves differently depending on the object's class. If Animal has MakeSound() and both Dog and Cat override it, then MyPet.MakeSound() barks if MyPet is a Dog and meows if it is a Cat — even though the call looks identical. This lets one piece of code work with many object types.

Aggregation / containment ('has-a'). One object contains other objects. A Car object might contain four Wheel objects and one Engine object. This is different from inheritance: a Car has wheels, it is not a kind of wheel.

Relationship	Phrase	Example
Inheritance	"is-a"	a Dog is an Animal
Aggregation/containment	"has-a"	a Car has Wheels

Distinguishing 'is-a' from 'has-a' is a common discriminator in design questions.

In the declarative (logic) paradigm you do not write step-by-step instructions. Instead you state WHAT is true, and the system works out the answer by inference. There are three parts:

• Facts — things known to be true, e.g. parent(tom, ann). and parent(ann, sam).
• Rules — relationships defined in terms of other facts/rules, e.g. X is a grandparent of Z if X is a parent of Y and Y is a parent of Z: grandparent(X, Z) IF parent(X, Y) AND parent(Y, Z)
• Goal — a query you ask the system to satisfy, e.g. grandparent(tom, sam).

How a goal is satisfied. To answer grandparent(tom, sam), the system matches the rule with X = tom, Z = sam and searches for a Y where both parent(tom, Y) and parent(Y, sam) are true. With Y = ann both hold (parent(tom, ann) and parent(ann, sam)), so the goal is proved TRUE. You never wrote a loop or told it the order — the system inferred it.

Imperative	Declarative
says HOW (the steps)	says WHAT is true (facts + rules)
programmer controls flow	system infers the answer to a goal
changes state in variables	queries logical relationships

(In an exam you write facts and rules in this style and trace how a goal is satisfied — you are not expected to memorise a specific language's exact syntax.)