Applying OOP to a problem (HL depth)

Computer Science · IB Diploma Programme (DP) - SL & HL · 4 min read · Updated: 7 Sept 2026

Welcome to HL Depth: Putting OOP into Practice

In our previous chapters, we looked at the building blocks of Object-Oriented Programming (OOP)—things like Classes, Objects, Inheritance, and Polymorphism. Now, we are going to learn how to take a messy, real-world problem and turn it into a clean, organized OOP solution. This "HL Depth" section focuses on the strategy of design and the reasoning behind our choices.

At the Higher Level (HL), the IB expects you not just to write code, but to justify why you structured your program a certain way. Let’s dive in!

The Goal: From Problem to Program

When you are faced with a complex problem (like designing a system for a hospital, a flight booking site, or a video game), you shouldn't start coding immediately. Instead, we use the computational thinking process to decompose the problem into manageable objects. The goal is to create a system that is modular, reusable, and easy to maintain.

Step 1: Identifying Classes and Objects (The Noun Technique)

Don't worry if a problem seems overwhelming at first. A great trick to get started is the Noun Extraction technique. Read the problem description and highlight all the nouns (people, places, things). These are your potential Classes.

Example Scenario: "A university needs a system where Students can enroll in Courses. Each course is taught by a Professor. The system should track Grades and generate Reports."

From this, our potential classes are:
1. Student
2. Course
3. Professor
4. Grade (or Transcript)
5. ReportGenerator

Quick Review:

A Class is the blueprint (e.g., "Student"), while an Object is the actual instance (e.g., "Alice, who is a student").

Step 2: Defining Attributes and Behaviors

Once you have your classes, you need to decide what they know (Attributes) and what they do (Behaviors).

Attributes (State): Usually variables. For a Student, this might be \( \text{studentID} \), \( \text{name} \), and \( \text{email} \).
Behaviors (Actions): Usually methods/functions. For a Student, this might be \( \text{enrollInCourse()} \) or \( \text{viewGrades()} \).

Pro-tip: Always remember Encapsulation here! Keep your attributes private and provide public "getter" and "setter" methods to access them. This protects the data from being accidentally messed up by other parts of the program.

Step 3: Determining Relationships (HL Focus)

This is where HL students need to be sharp. How do these classes talk to each other? We usually look for two main types of relationships:

1. The "Is-a" Relationship (Inheritance)

Use this when one class is a specific version of another.
Example: A PhysicsProfessor "is-a" Professor.
(For more on this, see the chapter on Inheritance and Polymorphism).

2. The "Has-a" Relationship (Composition/Aggregation)

Use this when one class is part of another or uses another.
Example: A Course "has-a" StudentList. A University "has-a" Department.
In HL problem solving, we often use Composition to build complex objects out of smaller, simpler ones. This makes the code much easier to test because you can test the small pieces individually.

Step 4: Choosing the Right Tools

In your Paper 2 exam, you have the choice between Java and Python. When applying OOP to a problem, your choice of language might affect how you implement your design, but the logic remains the same.

Java: Very strict with types and structure. Great for large, complex systems where you want the compiler to catch errors for you.
Python: More flexible and faster to write. Great for rapid prototyping and simpler syntax.

Common Mistakes to Avoid

1. The "God Class": Don't try to put everything into one giant class (e.g., a "System" class that does everything). This defeats the purpose of OOP. Break it down!
2. Forgetting Encapsulation: Don't make all your variables public. It might seem easier at first, but it makes the program "brittle" (easy to break).
3. Over-complicating Inheritance: Don't create 10 levels of inheritance if 2 will do. Keep your "family tree" of classes simple.

Real-World Analogy: The Restaurant

Think of a restaurant system.
- Classes: Chef, Waiter, Customer, Order, Menu.
- Inheritance: A HeadChef "is-a" Chef.
- Composition: An Order "has-a" list of FoodItems.
- Encapsulation: The Customer doesn't need to know how the Chef cooks the meal; they just call the \( \text{orderFood()} \) method and wait for the result!

Key Takeaways for HL Students

1. Analysis first: Use noun extraction to find your classes.
2. Modularity: Aim to create classes that can be reused in other projects.
3. Relationship Logic: Clearly distinguish between "Is-a" (Inheritance) and "Has-a" (Composition).
4. Evaluation: Be prepared to explain why your OOP design is better than a simple procedural (line-by-line) approach. Usually, the answer is: "It is easier to maintain, scale, and debug."

Quick Review:

In an exam, if asked to "Design an OOP solution," follow this path: Identify Classes \(\rightarrow\) Define Attributes/Methods \(\rightarrow\) Establish Relationships \(\rightarrow\) Sketch a UML Diagram (covered in the next chapter!).

Quick check

Can you answer these now?

Open each question to check the key ideas from this chapter.

What is the primary goal of applying OOP to a complex real-world problem?

The goal is to use the computational thinking process to decompose the problem into manageable objects, creating a system that is modular, reusable, and easy to maintain.

What is the 'Noun Extraction' technique in OOP design?

Noun Extraction is a strategy where you read a problem description and highlight all the nouns to identify potential classes for your program.

In the context of class design, what is the difference between attributes and behaviors?

Attributes (State) are the data variables a class knows, while Behaviors (Actions) are the methods or functions representing what the class can do.

Why is encapsulation important when defining class attributes?

Encapsulation protects data by making attributes private and providing public getter and setter methods, preventing accidental corruption from other parts of the program.

What does an 'Is-a' relationship represent in OOP?

An 'Is-a' relationship represents Inheritance, where one class is a specific version or subtype of another (e.g., a PhysicsProfessor 'is-a' Professor).

What does a 'Has-a' relationship represent in OOP?

A 'Has-a' relationship represents Composition or Aggregation, where one class is composed of or uses another class (e.g., a Course 'has-a' StudentList).

What is a 'God Class' and why should it be avoided?

A 'God Class' is a single giant class that tries to handle all the logic of a system, which defeats the purpose of modular OOP design.

How can OOP design be evaluated against procedural programming?

OOP is generally superior for complex systems because it is easier to maintain, scale, and debug compared to a simple line-by-line procedural approach.

Ready to test yourself?

Turn these notes into exam-style practice. Get unlimited AI questions on this topic with instant marking and explanations.

Practise This Topic

More Computer Science chapters

* The content provided by thinka is generated by AI and may not always be accurate or up-to-date. Please use it as a supplementary resource and verify with official materials.

Put These Notes into Practice

Reading the notes is a great start. Now practise with unlimited AI-generated questions and get instant feedback. 100,000+ students are already improving their grades.

Start Practising Now View Pricing

Done reading? Test yourself with AI practice questions

Practise This Topic Now