Object-oriented problem solving

CIE A-Level Computer Science· Unit 13: Computational thinking & problem solving, Topic 4· 20 min read

1. Core OO Principles for Problem Decomposition★★☆☆☆⏱ 5 min

Object-oriented problem solving structures solutions around entities rather than standalone functions. This makes large, complex problems easier to maintain and extend, because changes to one part of the system have minimal impact on other parts.

📘 Definition

Object-oriented problem solving

A problem-solving methodology that structures a solution around reusable entities (objects) that combine data (state) and behaviour (methods), rather than around standalone functions or procedures.

📐 Worked Example

Decompose a simple school attendance system using OO principles. Name at least three core classes.

1
First, list all key tangible or conceptual entities the system needs to track.
2
Four core entities for an attendance system are: Student, Teacher, Session, and AttendanceRecord.
3
For each entity, identify stored data (attributes) and actions (methods):
4
- Student: attributes = studentID, name, yearGroup; methods = registerAttendance(), getDetails()
- Session: attributes = sessionID, date, room; methods = startSession(), endSession()
- AttendanceRecord: attributes = recordID, isPresent; methods = updateStatus()
5
Each entity maps to a class, and specific entries (e.g. student ID 12345) become objects of the corresponding class.

2. Identifying Classes, Attributes and Methods★★☆☆☆⏱ 6 min

The first practical step in OO problem solving is extracting components from a natural language problem description. A simple rule of thumb is that nouns usually correspond to classes or attributes, while verbs usually correspond to methods.

📐 Worked Example

Extract classes, attributes and methods from this description: 'A coffee shop needs a system to track orders. Each order has a date, a list of items, and a total price. Orders can calculate tax and print a receipt.'

1
Highlight all nouns: coffee shop, system, order, date, list of items, total price, tax, receipt.
2
Filter to core classes: only Order is a top-level core entity here; the other nouns are not standalone classes.
3
Assign remaining nouns as attributes of the Order class: date, itemList, totalPrice.
4
Highlight all verbs: track, has, calculate, print. Filter to methods: calculateTax() and printReceipt() are methods of Order.

✓ Quick check

Test your understanding:

Which of the following is a method for a BankAccount class?
- accountNumber
- customerName
- withdrawFunds
- balance
Reveal answer
2 —
Correct: withdrawFunds is an action (verb) performed by a BankAccount. All other options are stored data (attributes).

3. Modelling Relationships Between Classes★★★☆☆⏱ 7 min

After identifying individual classes, you need to model how classes interact and relate to each other. The most common relationships used in OO problem solving are inheritance (is-a), aggregation (has-a whole-part) and association.

📘 Definition

Inheritance

An 'is-a' relationship where a subclass inherits attributes and methods from a superclass, enabling code reuse and hierarchical classification.

Example:

A SavingsAccount is a type of BankAccount, so SavingsAccount inherits from BankAccount.

📐 Worked Example

Model the inheritance hierarchy for a vehicle rental system, where the system rents cars, motorbikes and vans. All vehicles have a registration number, make and model, and can be hired or returned.

1
Identify the common superclass: all entities are vehicles, so create a top-level Vehicle class.
2
Move all common attributes and methods to the superclass: Vehicle has attributes registrationNumber, make, model, and methods hire(), returnVehicle().
3
Create subclasses for each specific vehicle type, adding any unique attributes or methods:
4
- Car: adds numberOfSeats attribute and calculateInsuranceCost() method
- Motorbike: adds engineCapacity attribute
- Van: adds cargoCapacity attribute
5
This hierarchy avoids repeating code across classes, following core OO design principles.

4. Encapsulation in OO Problem Design★★★☆☆⏱ 6 min

Encapsulation is a core OO principle that supports robust problem design. It hides the internal implementation details of a class, only exposing a controlled public interface for interacting with objects.

📐 Worked Example

Apply encapsulation to the BankAccount class, which stores a balance that should only be modified by approved deposits and withdrawals.

1
Make the balance attribute private, so it cannot be accessed or changed directly from outside the BankAccount class.
2
Create public methods to interact with the balance: deposit(amount), withdraw(amount), and getBalance() to view the current balance.
3
Add validation logic inside the public methods: withdraw(amount) can reject transactions where the amount exceeds the current balance, preventing negative balances.
4
External code can only change the balance via approved methods, so the class always maintains internal consistency.

5. Common Pitfalls

Wrong move:

Turning every noun in the problem description into a separate class.

Why:

This leads to unnecessary classes and an overly complex, hard-to-implement design.

Correct move:

Filter nouns to only core entities with both attributes and behaviours; combine trivial nouns into attributes of larger classes.

Wrong move:

Using inheritance for 'has-a' whole-part relationships.

Why:

For example, making Wheel a subclass of Car is incorrect, because a wheel is not a type of car.

Correct move:

Use inheritance for 'is-a' relationships only, use aggregation for 'has-a' whole-part relationships.

Wrong move:

Making all attributes public, breaking encapsulation.

Why:

This allows uncontrolled modification of internal object state, leading to hard-to-trace bugs.

Correct move:

Make all attributes private by default, only expose public methods for controlled interaction with objects.

Wrong move:

Putting all functionality into one large master class.

Why:

This violates the single responsibility principle, making the design hard to test, extend and maintain.

Correct move:

Split functionality across multiple classes, each responsible for one specific part of the problem.

Wrong move:

Skipping OO design and jumping straight to writing code.

Why:

This leads to messy, ad-hoc designs that are hard to debug and do not meet exam marking criteria.

Correct move:

Always complete OO decomposition and class design before writing any code for your solution.

6. Quick Reference Cheatsheet

Component	How to Identify	Example
Class	Core noun/entity in problem domain	Order
Attribute	Noun, property of a class	orderDate
Method	Verb, action performed by a class	calculateTax()
Inheritance	'is-a' hierarchical relationship	SavingsAccount IS A BankAccount
Aggregation	'has-a' whole-part relationship	Order HAS Item objects
Encapsulation	Hide internal data, expose methods	Private balance + public withdraw()

When this came up on past exams

AI-estimated based on syllabus patterns — cross-check with official past papers for accuracy. Use only as revision-focus signals.

2022 · 12
Identify OO components for library system
2023 · 11
Decompose zoo system using OO principles
2024 · 13
Model OO structure for online shop

Going deeper

syllabusOfficial CIE 9618 SyllabusFull syllabus for reference

What's Next

Mastering object-oriented problem solving is the foundation for designing all large-scale software systems, and is a regularly assessed topic for CIE 9618 Paper 1. The principles you learn here will be applied when you create standard UML class diagrams, write object-oriented code for practical tasks, and design software for your course practical assessment. This approach to problem solving also translates directly to industry software development, making it a valuable skill beyond your A-Level exam. Next, you will build on this core knowledge by exploring how to model OO system relationships and implement OO concepts in working code for assessment.