Computational Thinking
Discover the four thinking strategies that underpin all problem solving in computer science: abstraction, decomposition, pattern recognition and algorithmic thinking.
Every piece of software you have ever used - from a search engine to a video game - was not written by someone who just started typing code. It was built by someone who first thought carefully about the problem: what information matters, how to break it apart, what patterns could be reused, and what precise steps would always produce the right answer. That process of structured thinking is called computational thinking.
Abstraction means identifying and removing detail that is not relevant to the problem you are trying to solve. It does not mean making something vague - it means making it appropriately simple so that you can focus on what actually matters.
Abstraction appears everywhere in computer science. A function hides its internal workings behind a name. A class exposes only the methods other code needs. A map of the London Underground shows connections without showing real distances, curves or tunnel depths - none of that detail helps a passenger decide which train to take.
Abstraction is not a single step - it is a spectrum. A high-level programming language abstracts away memory management. An operating system abstracts away hardware. A map app abstracts away everything about the physical road except its route. Each level hides complexity below it and exposes only what the level above needs.
A common exam question gives a scenario and asks which details would be kept and which removed. Always ask yourself: "What does the person or system using this actually need?" Anything beyond that is unnecessary detail and should be abstracted away. The Underground map is the classic example - memorise it and what it illustrates.
Decomposition breaks a complex problem into smaller sub-problems. Each sub-problem is easier to understand, easier to solve and easier to test in isolation. This is why large software projects can be built by teams of hundreds of developers without complete chaos - each person solves one sub-problem, and the pieces are assembled.
The key rule: keep decomposing until each piece is small enough to solve directly. If a sub-problem still feels overwhelming, decompose it further. You stop when each piece can be solved in a single, clear step.
Notice that Sub-problem 1 can itself be decomposed. "Register" breaks down into: collect username/email/password, validate format, check for duplicates, hash password, store record, send confirmation email. Each step is now small enough to implement directly.
Exam questions on decomposition typically give a scenario (booking system, game, school admin tool) and ask you to identify sub-problems. Write each sub-problem as a noun-verb pair: "validate login credentials", "calculate delivery cost". Show that each sub-problem is distinct and independently solvable. Overlap between sub-problems suggests you need to decompose further.
Pattern recognition is noticing similarities - either within one problem or between the current problem and problems you have solved before. Recognising patterns allows you to reuse solutions rather than starting from scratch every time.
At the programming level, pattern recognition is why we write loops (the same operation repeats across a list), functions (the same logic is needed in multiple places), and classes (multiple objects of the same type need the same behaviour). At the algorithmic level, recognising "this is a search problem" lets you reach for a known, tested search algorithm rather than inventing one.
In professional software development, recognised patterns have names: the "Observer" pattern for event handling, the "Singleton" for a single shared resource, "MVC" for separating data from display. These are documented solutions to recurring problems. Recognising the pattern means you do not have to rediscover the solution.
Algorithmic thinking is designing a precise, step-by-step solution that can be followed without ambiguity and that produces the correct result for every valid input. The word "algorithm" comes from the name of a 9th-century Persian mathematician, Al-Khwarizmi, whose book on systematic calculation gave us the word.
An algorithm must satisfy three properties:
An algorithm is a logical description of a solution - it is language-independent. The same binary search algorithm can be implemented in Python, Java, C++ or pseudocode. A program is an implementation of an algorithm in a specific language. Understanding algorithms separately from code means you can think about correctness and efficiency before worrying about syntax.
You may be asked to evaluate whether a given algorithm is correct. Check: does every loop terminate? Is the output correct for normal inputs, edge inputs (e.g. an empty list) and boundary inputs (e.g. a list with one element)? These three categories of test data appear frequently in exam questions.
Test yourself
1. A transport app shows bus routes and stops but does not show the physical width of the road, speed limits or road surface type. Which pillar does this best represent?
2. A developer building a game breaks the project into: display graphics, handle player input, manage enemy AI, track score, play audio. Which pillar does this represent?
3. Which of the following is NOT a required property of an algorithm?
4. A programmer notices that sorting a playlist by song length uses the same comparison logic as sorting by album name. They reuse their existing sort function. Which pillar is this?
5. A student writes an algorithm to find the largest number in a list. They test it with [3, 7, 1, 9, 2] and it returns 9. However they have not tested it with an empty list. What property of a good algorithm have they failed to verify?
A student argues that abstraction and decomposition are the same thing because both involve "simplifying" a problem. Explain why they are distinct pillars using a specific example to illustrate the difference.
Example: Designing a weather app. Abstraction would involve deciding to ignore the physics of atmospheric pressure and just work with temperature, wind speed and rainfall data. Decomposition would involve splitting the app into sub-problems: fetch weather data, parse the data, display a forecast, handle location permissions. Abstraction removes columns from your view; decomposition splits the problem into rows.
Practice what you have learned
Three levelled worksheets for this lesson. Download, print and complete offline.