Data Structures (Years 10–11) — Computer Science

Beyond simple arrays: records, 2D arrays, lists, stacks (LIFO) and queues (FIFO), and how to choose the right one.

A plain array is a single row of same-typed boxes — brilliant for a list of scores, useless for describing one pupil who has a name, an age and a house. Real data has shape. This chapter is a tour of the structures programmers reach for when a flat array is not enough: records, 2D arrays, lists, stacks and queues. Each solves a different problem, and knowing which to pick is half of good design.

Why this matters: Choosing the right data structure decides how easy your program is to write and how fast it runs. A message app needs a queue; an "undo" button needs a stack; a register needs a record per pupil. Exams reward you for naming the structure and justifying why it fits.

A record groups named fields, each with its own type.

Records: mixed fields under one name

An array forces every box to be the same type. A record lifts that rule: it bundles several fields, each with its own name and type, into one object. Think of a passport — one document holding a name, a date and a photo — not three loose documents. You reach a field by name, not by number:

pupil.name    = "Aisha"
pupil.age     = 11
pupil.member  = true
OUTPUT pupil.age      // 11

Because fields have names, the code reads like plain English, and a whole record can be passed around as a single value.

2D arrays: a grid of rows and columns

A 2D array is a table; a cell is found by [row][column].

A 2D array is an array of arrays — a grid, like a spreadsheet or a chessboard. You address a cell with two indices: first the row, then the column. Both still start at 0.

grid[1][2] = 9      // row 1, column 2
OUTPUT grid[0][0]   // top-left cell

Lists: arrays that can grow and shrink

A classic array is a fixed size — a car park with set bays. A list is more like a guest list on paper: you can append a name or remove one, and it grows or shrinks to fit. That flexibility is why lists suit collections whose length you cannot predict.

Structure	Shape	Reach an item by	Good for
Record	Named fields, mixed types	Field name	One "thing" with several attributes
2D array	Grid of rows & columns	[row][column]	Tables, boards, images
List	Growable row	Index (can change size)	Unknown-length collections
Stack	Pile (LIFO)	Top only	Undo, back button, reversing
Queue	Line (FIFO)	Front & back	Print jobs, messages, fairness

Stacks: Last-In, First-Out

A stack is a pile of plates: push on top, pop off the top.

A stack works like a pile of plates. You add (push) to the top and take (pop) from the top — so the last item in is the first out. This LIFO order is what an "undo" feature needs: the most recent action reverses first.

Queues: First-In, First-Out

A queue is a shop line: enqueue at the back, dequeue at the front.

Worked example — stack vs queue on the same data. We add A, then B, then C.
Stack (LIFO): push A, push B, push C. First pop returns C, then B, then A — reversed order.
Queue (FIFO): enqueue A, B, C. First dequeue returns A, then B, then C — original order.
Same three items in; the structure decides who comes out first.

Common mistake: mixing up LIFO and FIFO. A stack takes from the top (last in first out); a queue takes from the front (first in first out). If the newest thing should be handled first, use a stack; if it should be fair and in order, use a queue.

To choose a structure, ask what the data is. One thing with attributes → record. A grid → 2D array. Unknown length → list. "Undo the last move" → stack. "Serve people in order" → queue.