Object-oriented programming (OOP) organises code around objects — self-contained units combining data (attributes) and behaviour (methods). A class is a blueprint defining what attributes and methods its objects will have, while an object (or instance) is a specific thing created from that blueprint. This approach helps organise larger programs by grouping related data and functionality together, rather than scattering it throughout the code.
Example
A "Car" class might define attributes like colour and speed, and methods like accelerate() and brake() — you could then create multiple objects (instances) from this one class, like myCar and friendsCar, each with its own colour and speed but sharing the same accelerate() and brake() behaviour.
Key terms
Class:
A blueprint defining the attributes and methods of an object.
Object (instance):
A specific thing created from a class, with its own data.
Method:
A function defined within a class, describing an object's behaviour.
Questions
1. A class is:
A blueprint defining attributes and methods
A single, specific object only
A type of variable with no structure
A programming error
2. An object (or instance) is:
A specific thing created from a class
The blueprint itself, with no specific data
A type of loop
A comment in the code
3. A method is:
A function defined within a class describing behaviour
A single piece of data only, with no behaviour
A type of class name
A comment with no function
4. Attributes of a class represent:
Data associated with the class
Only behaviour, with no data at all
Nothing meaningful
Only method names, with no values
5. Multiple objects can be created from:
The same class
Only a single, unique class each
No class at all
A method only, with no class involved
6. A "Car" class with a colour attribute would allow:
Different car objects to each have their own colour value
Every car object to always share the exact same colour
No colour to ever be stored
Colour to only exist as a method, never an attribute
7. OOP helps organise code by:
Grouping related data and functionality together
Scattering all data randomly throughout a program
Removing all structure from a program entirely
Preventing any functions from ever being used
8. If a Car class has a method accelerate(), calling this method on a specific car object would:
Apply that behaviour to that specific object
Change the blueprint (class) itself for every future object
Do nothing at all
Delete the object entirely
9. Why might two Car objects created from the same class have different colour attribute values?
Each object stores its own individual data, even though they share the same class structure
All objects created from one class are always forced to have identical data
Attributes can never differ between objects of the same class
Only one object can ever be created from a single class
10. Why might defining a "Car" class rather than writing separate, unconnected code for every individual car be more efficient?
A shared class avoids repeating the same structure and behaviour for every new car object
Defining a class always makes a program significantly slower to write
Classes and objects have no impact on how efficiently code can be organised
It is always more efficient to write completely separate code for every object
11. A method like brake() defined in a class represents:
An object's behaviour
A fixed, unchangeable value only
A completely unrelated class
A comment with no functional effect
12. Why is OOP considered helpful for managing larger, more complex programs compared to smaller scripts?
Organising related data and behaviour into classes makes large codebases easier to understand, maintain and extend
OOP makes every program, regardless of size, significantly harder to understand
Larger programs never benefit from any organisational structure
Complexity in a program has no relationship to how it is organised
13. Why might grouping an object's data (attributes) and behaviour (methods) together, rather than keeping them separate, reduce bugs in a program?
Related logic and data staying together makes it easier to track how and where a specific object's state changes
Keeping data and behaviour together always makes a program more error-prone
Bugs are entirely unrelated to how code is structured or organised
Separating data and behaviour completely always produces more reliable code
14. Inheritance in OOP allows a new class to:
Reuse and extend the attributes and methods of an existing class
Never share any attributes or methods with another class
Delete all attributes from the original class
Only exist without ever being instantiated as an object
15. Why might a "Vehicle" class with subclasses like "Car" and "Motorbike" (using inheritance) reduce duplicated code?
Shared attributes and methods can be defined once in Vehicle and reused by both subclasses, rather than repeated
Inheritance always requires rewriting every attribute and method separately for each subclass
Subclasses can never share any functionality with a parent class
Using subclasses always increases the total amount of code needed
16. Why might encapsulation (restricting direct access to an object's internal data) be considered good OOP practice?
It helps prevent external code from accidentally changing an object's data in unintended or inconsistent ways
Encapsulation always makes a program's data completely inaccessible and unusable
Restricting access to data has no benefit for program reliability
External code should always be allowed unrestricted access to every object's data
17. If a "Student" class has attributes name and grade, and two Student objects are created, changing one object's grade will:
Only affect that specific object, not the other
Always change the grade for every Student object at once
Delete the Student class entirely
Have no effect on either object
18. Polymorphism in OOP allows different classes to:
Respond to the same method call in their own specific way
Never share any method names in common
Only ever exist as a single, identical class
Be merged permanently into one single object
19. Why might a large team of programmers find OOP especially useful when collaborating on the same codebase?
Classes create clear, self-contained units that different team members can work on with less risk of interfering with each other
OOP always makes collaboration between multiple programmers significantly harder
Team-based programming never benefits from any particular code organisation style
Classes prevent any two programmers from ever working on the same project
20. Why might designing a class's attributes and methods carefully before writing an entire program help avoid problems later?
A well-planned class structure is easier to extend and reuse than one that has to be substantially reworked after code already depends on it
Planning a class structure in advance never has any effect on future problems
Attributes and methods can always be changed later with zero consequences
Careful class design has no bearing on how maintainable a program becomes
21. Why might a game engine use OOP, with classes like "Player", "Enemy" and "Item" each defining their own attributes and methods?
It lets each type of game object have a clear, organised structure of relevant data and behaviour, making the codebase easier to manage
Games never use any form of structured code organisation
A single unstructured block of code is always the most effective approach for a game
Classes and objects have no practical application in game development
Answer key (parent copy)
1. A blueprint defining attributes and methods
2. A specific thing created from a class
3. A function defined within a class describing behaviour
4. Data associated with the class
5. The same class
6. Different car objects to each have their own colour value
7. Grouping related data and functionality together
8. Apply that behaviour to that specific object
9. Each object stores its own individual data, even though they share the same class structure
10. A shared class avoids repeating the same structure and behaviour for every new car object
11. An object's behaviour
12. Organising related data and behaviour into classes makes large codebases easier to understand, maintain and extend
13. Related logic and data staying together makes it easier to track how and where a specific object's state changes
14. Reuse and extend the attributes and methods of an existing class
15. Shared attributes and methods can be defined once in Vehicle and reused by both subclasses, rather than repeated
16. It helps prevent external code from accidentally changing an object's data in unintended or inconsistent ways
17. Only affect that specific object, not the other
18. Respond to the same method call in their own specific way
19. Classes create clear, self-contained units that different team members can work on with less risk of interfering with each other
20. A well-planned class structure is easier to extend and reuse than one that has to be substantially reworked after code already depends on it
21. It lets each type of game object have a clear, organised structure of relevant data and behaviour, making the codebase easier to manage