A-Level Computer Science: Object-Oriented Programming Explained

Object-Oriented Programming represents a fundamental shift from procedural programming. Instead of thinking about a program as a sequence of instructions operating on data, OOP organises code around objects—self-contained units combining data and behaviour. Mastering OOP means understanding not just the syntax but the underlying principles and when to apply them.

Classes and Objects: The Foundation

A class is a template or blueprint defining the properties and behaviours of a type of object. An object is a specific instance of a class. If “Car” is a class, then “my red Toyota Corolla” is an object—a specific car with particular attribute values.

Classes define two things: attributes (data the object stores, also called instance variables or fields) and methods (functions the object can perform). When you create an object from a class, you’re instantiating it—making a concrete instance with its own attribute values.

In Python syntax, a class definition looks like this: class Car: followed by indented method definitions. The special __init__ method is the constructor—it runs when you create a new object, initialising its attributes. The self parameter in every method refers to the specific object calling the method.

Understanding the difference between class attributes and instance attributes matters for exam questions. Class attributes are shared by all instances of the class; instance attributes are unique to each object. If you change a class attribute, it affects all objects (unless they’ve overridden it); changing an instance attribute affects only that object.

Encapsulation: Hiding Internal Details

Encapsulation means bundling data and methods operating on that data within a single unit (the class) and controlling access to that data. This is about protecting an object’s internal state from inappropriate external interference.

Attributes can be public (accessible from anywhere), private (accessible only within the class), or protected (accessible within the class and subclasses). Python uses naming conventions: attributes starting with underscore (_attribute) are protected; those starting with double underscore (__attribute) are private.

The principle here is information hiding: only expose what external code needs; keep internal implementation details private. This allows you to change internal implementation without breaking external code that uses the class.

Getter and setter methods (also called accessor and mutator methods) provide controlled access to private attributes. Instead of directly accessing an attribute, external code calls a method. This allows validation—a setter can check whether a new value is valid before accepting it, preventing invalid states.

For exam questions, be able to explain why encapsulation is beneficial: it prevents direct modification of internal data, allows validation of inputs, enables changing implementation without affecting external code, and makes debugging easier by limiting where attributes can be modified.

Inheritance: Creating Hierarchies

Inheritance allows you to define a new class based on an existing class. The new class (child, derived, or subclass) inherits attributes and methods from the existing class (parent, base, or superclass), and can add new attributes/methods or override existing ones.

The relationship is “is-a”: a Dog is an Animal, a SavingsAccount is an Account. This differs from composition (“has-a” relationships, like a Car has an Engine).

In Python, you define a child class like: class Dog(Animal):. The child class inherits everything from Animal and can add dog-specific features. If Dog defines a method that Animal already has, Dog’s version overrides the parent version.

The super() function lets you call the parent class’s methods from the child class. This is commonly used in constructors: the child’s __init__ calls super().__init__() to initialise inherited attributes, then initialises its own additional attributes.

Inheritance promotes code reuse—common functionality lives in the parent class, shared by all children. It also enables polymorphism, which we’ll cover next.

Abstract classes contain abstract methods—methods declared but not implemented. Subclasses must implement these methods. This enforces a contract: all children must provide certain behaviours, but each implements them differently. Python uses the abc module for abstract classes, though you should understand the concept more than syntax details.

Polymorphism: One Interface, Multiple Implementations

Polymorphism means “many forms”. In OOP, it means objects of different classes can respond to the same method call, but each responds in its own way.

Imagine you have an Animal class with a make_sound() method. Dog, Cat, and Cow all inherit from Animal, each providing their own make_sound() implementation (bark, meow, moo). Now you can write code that calls make_sound() on any Animal object without knowing whether it’s a Dog or Cat—each responds appropriately. This is polymorphism.

This enables flexible, extensible code. You can write functions that work with parent class types, and they’ll automatically work with any child class. When you add a new child class, existing code handles it without modification.

Polymorphism requires inheritance (so all objects share a common parent type) and method overriding (so each child class provides its own implementation). Together, these enable code to operate on objects generically through their common parent type, while each object maintains its specific behaviour.

Operator overloading is another form of polymorphism. The + operator works with integers, floats, strings, and lists—it has multiple forms depending on context. In Python, you can define how operators work with your custom classes by implementing special methods like __add__, __str__, or __eq__.

Composition: Building Complex Objects

Composition means one class contains instances of other classes. A Car contains an Engine, Wheels, and Seats. These are “has-a” relationships.

Unlike inheritance, composition represents a whole-part relationship. The Car isn’t a type of Engine; it has an Engine as a component. Composition provides flexibility—you can easily change components (swap one Engine type for another) without affecting the Car interface.

When deciding between inheritance and composition, ask: is it an “is-a” relationship (inheritance) or “has-a” relationship (composition)? A SportsCar is a Car (inheritance). A Car has an Engine (composition).

Composition often proves more flexible than deep inheritance hierarchies. Favour composition over inheritance when components can vary independently or when you need to combine behaviours from multiple sources.

Access Modifiers and Information Hiding

Understanding access modifiers is crucial for encapsulation questions. Public members are accessible from anywhere. Private members are accessible only within the class. Protected members are accessible within the class and its subclasses.

Different languages implement these differently. Python uses naming conventions (underscore prefixes) rather than enforced access control. Other languages like Java use keywords (public, private, protected). Know the concept more than language-specific syntax.

Information hiding limits external access to internal details. It’s about deliberate interface design: decide what external code should access and hide everything else. This reduces coupling between classes—changes to internal implementation don’t ripple through dependent code.

Class Diagrams: UML Representation

Class diagrams visually represent classes and their relationships. Each class appears as a box divided into sections: class name at top, attributes in middle, methods at bottom.

Attributes show visibility (+ for public, - for private, # for protected), name, and type. Methods show visibility, name, parameters, and return type. For example: + getBalance() : float.

Relationships between classes include: association (general relationship), aggregation (weak “has-a” relationship—parts can exist independently), composition (strong “has-a” relationship—parts cannot exist without the whole), and inheritance (shown with a hollow arrow pointing to parent).

Being able to draw and interpret class diagrams matters for exam questions. Practise converting code into diagrams and vice versa. Understand what each arrow type means and when to use each relationship type.

Design Principles and Patterns

Several principles guide good OOP design. Single Responsibility Principle: each class should have one clear purpose. Open/Closed Principle: classes should be open for extension (via inheritance) but closed for modification (don’t change existing code). Liskov Substitution Principle: child classes should be substitutable for their parent without breaking functionality.

Design patterns are proven solutions to common problems. You don’t need to memorise many patterns for A-Level, but understanding the concept helps. For example, the Factory pattern creates objects without specifying their exact classes—useful when you don’t know at design time which specific class you’ll need to instantiate.

Object-Oriented vs Procedural Programming

Exam questions often ask you to compare OOP with procedural programming. Procedural programming organises code as a sequence of procedures (functions) operating on data structures. OOP bundles data and operations together as objects.

OOP advantages include: better code organisation (objects group related functionality), easier maintenance (changes localise to specific classes), code reuse through inheritance, and modelling real-world entities naturally. Disadvantages include: steeper learning curve, potential for overengineering simple problems, and more complex program structure.

Procedural advantages include: simplicity for small programs, straightforward execution flow, and efficiency for computation-heavy tasks. Disadvantages include: less code reuse, harder maintenance as programs grow, and global data access creating dependencies.

Neither approach is universally better—it depends on the problem. OOP excels for large programs with complex data and behaviour. Procedural programming works well for simpler, algorithmic problems.

Exam Technique for OOP

When writing code in exams, focus on demonstrating understanding over perfect syntax. Use clear structure, appropriate comments, and meaningful names. Examiners want to see you understand concepts, not memorise Python quirks.

For “describe” or “explain” questions, use precise terminology. Don’t say “inheritance is when one class gets stuff from another class”. Say “inheritance is when a subclass derives from a parent class, inheriting its attributes and methods”.

When asked to design a class, plan before writing. Identify: what attributes does the object need (its state)? What methods does it need (its behaviour)? What should be public vs private? Draw a simple class diagram first if it helps.

For questions asking you to identify appropriate uses of OOP features, look for: repeated code (inheritance opportunity), similar classes (potential parent class), objects with complex internal state (encapsulation), or situations where objects need to behave differently based on their type (polymorphism).

When evaluating whether OOP is appropriate for a given problem, consider: problem complexity (simple problems may not benefit), whether real-world entities need modelling (OOP’s strength), whether the problem involves multiple related types (inheritance/polymorphism), and whether code reuse matters.

UpGrades provides extensive OOP practice with code completion, class design challenges, and concept explanation questions, building your ability to think in objects and apply OOP principles effectively.