Skip to topic
    ← Back to course topics

    Composition — AQA A-Level Computer Science

    Composition is an object-oriented design principle representing a strict 'has-a' relationship where one object is composed of one or more component objects. Crucially, the lifetime of the contained object is bound to the container; if the parent composite object is destroyed, the child component objects are also destroyed.

    Composition explained

    Composition is the process of combining simpler procedures to build a more powerful procedure.

    Read the full explanation

    In functional programming, the composition of two functions f and g produces a new function h such that h(x) = f(g(x)): the output of g becomes the input of f. A compound procedure is therefore defined in terms of other procedures rather than being written out from scratch. This lets a programmer build complex behaviour from small, tested, reusable parts. For example, a procedure to find the average of a list might be composed from a procedure that sums a list and a procedure that counts its elements, then divides one result by the other. Understanding composition means recognising when one procedure's output can be passed directly into another, and using that structure to keep each procedure focused on a single task.

    Your focus

    1. Know how to build a composition abstraction by combining procedures to form compound procedures.

    Which command word is this?

    State the precise technical term (e.g., 'Composition') without unnecessary narration or lengthy explanation.

    Composition exam tips

    Topic Overview

    Composition is a foundational structural concept in Object-Oriented Programming (OOP) that defines a strong association between an enclosing composite class and its internal component classes. It embodies a strict 'has-a' relationship wherein the composite class instantiates and controls the lifecycle of its component parts.

    Understanding composition is critical for modern software architecture, where modularity and flexibility are paramount. In the AQA A-Level specification, composition is contrasted against aggregation and inheritance, equipping students to evaluate software design patterns and design decoupled, robust systems.

    Key Concepts
    • →Lifecycle Dependency: The component object cannot exist without the composite parent; creating the parent creates the child, and destroying the parent destroys the child.
    • →'Has-a' Relationship: Unlike inheritance ('is-a'), composition bundles functionalities by including instances of other classes as internal attributes.
    • →UML Notation: Represented in UML class diagrams by a line ending with a solid (filled) diamond positioned against the composite owning class.
    • →Encapsulation and Delegation: The composite class hides component implementation details, delegating specific subtasks to component methods rather than extending class hierarchies.
    Marking Points
    • Defines a compound procedure in terms of other procedures rather than repeating their logic.
    • Passes the output of one procedure as the input to the next in the composed chain.
    • Keeps each component procedure focused on one clearly defined task.
    • Recognises that the composed procedure can be reused wherever the combined behaviour is needed.
    Examiner Tips
    • 💡When an MCQ asks what composition produces, look for an option describing a new procedure built from existing ones, not a single procedure with a loop.
    • 💡Check the direction of data flow in each option: the inner procedure's output should be the outer procedure's input.
    • 💡Eliminate options that describe copying code, as these describe duplication rather than composition.
    • 💡In diagram questions, always ensure your diamond is completely shaded when indicating composition; an open/unfilled diamond represents aggregation and will lose the mark.
    • 💡When explaining code implementation, note that in composition, the component object is typically instantiated inside the constructor of the composite class.
    Common Mistakes
    • Treats composition as simply calling two procedures one after another without using one's result as the other's input; the output must feed the next procedure.
    • Copies the code of the component procedures into a new procedure instead of referring to them; this is duplication, not composition.
    • Confuses composition with recursion, where a procedure calls itself rather than combining distinct procedures.
    • Assuming composition and aggregation are synonyms: Aggregation represents weak ownership where parts survive the destruction of the container, while composition represents absolute lifecycle dependency.
    • Believing inheritance is always the default OOP way to achieve code reuse: Overusing inheritance leads to fragile hierarchies, whereas composition provides equivalent or superior reuse with lower coupling.
    Revision Plan
    1. 1Day 1-2: Review core OOP association types and write precise definitions for Association, Aggregation, and Composition.
    2. 2Day 3-4: Practice drawing and interpreting UML diagrams, paying special attention to relationship arrows, solid diamonds, and multiplicities.
    3. 3Day 5-6: Write code in your chosen language (e.g., Python, C#, or Java) demonstrating composition by initializing component objects within a master class constructor.
    4. 4Day 7: Work through past paper 6-mark comparative essays evaluating composition versus inheritance.
    Exam Question Types
    • 📋UML Diagram Interpretation: Identifying relationships between classes from diagrams and adding appropriate composition/aggregation symbols.
    • 📋Scenario Classification: Reading a real-world scenario (e.g., Building and Rooms vs. Library and Books) and identifying the correct association type with justification.
    • 📋Long-form Evaluation: Comparing composition and inheritance regarding coupling, encapsulation, and maintenance.
    Command Word Expectations (AQA)
    Identify

    State the precise technical term (e.g., 'Composition') without unnecessary narration or lengthy explanation.

    Explain

    Set out the causes, characteristics, or mechanisms of composition, linking lifecycle dependency directly to system behavior.

    Compare

    Provide a balanced analysis of both concepts (such as composition vs aggregation), pointing out specific differences in lifecycle, coupling, and notation.

    How Students Lose Marks (Examiner Pitfalls)
    Pitfall: Confusing composition with aggregation regarding lifecycle dependency and UML notation.
    ❌ Weak Answer (Loses Marks):Composition is when a class has another class inside it, like a car having an engine, and it uses a diamond symbol.
    Example improved answer:Composition is a strong form of association representing a 'has-a' relationship where the contained object cannot exist independently of the container. If the composite object is destroyed, its component parts are also destroyed. In UML class diagrams, composition is denoted by a solid, filled diamond on the side of the composite (owner) class.
    Examiner Tip: Always explicitly state the lifecycle dependency ('death dependency') when defining composition, and specify that the UML marker is a solid/filled diamond, not an unfilled one.
    Pitfall: Failing to explain why composition is preferred over inheritance in software engineering design questions.
    ❌ Weak Answer (Loses Marks):Composition is better because inheritance makes code messy and hard to read.
    Example improved answer:Composition provides greater flexibility than inheritance by enabling behavior to be altered dynamically at runtime through object swapping. It avoids rigid class hierarchies and prevents the subclass from inheriting unnecessary or fragile internal attributes from a superclass, thereby promoting lower coupling.
    Examiner Tip: Use professional software engineering terms such as 'loose coupling', 'runtime flexibility', and 'encapsulation' when contrasting composition with class inheritance.
    Step-by-Step Worked Solutions

    Question: A software engineer is designing an application for a university. The system models a 'University' that contains multiple 'Departments', and 'Departments' that contain 'Lecturers'. (a) Identify the relationship between University and Department, and between Department and Lecturer, choosing between composition and aggregation. (b) Justify your choice for both relationships.

    1. 1.Step 1: Analyze the lifecycle dependency between University and Department. If the University closes down, the University Departments cease to exist as legal/operational entities within that university. This represents strong lifecycle dependency.
    2. 2.Step 2: Classify University-Department as composition.
    3. 3.Step 3: Analyze the lifecycle dependency between Department and Lecturer. If a Department is closed or restructured, the Lecturer exists independently as an individual professional and can move to another department or institution.
    4. 4.Step 4: Classify Department-Lecturer as aggregation.
    5. 5.Step 5: Summarize the justification linking the definitions of composition (destruction cascades to components) and aggregation (independent lifecycle).
    Final Answer: University and Department is composition because a Department cannot exist without the University; its lifecycle is tied to the parent. Department and Lecturer is aggregation because Lecturers exist independently of any single Department and retain their existence if the Department ceases to exist.

    Question: Explain the phrase 'favor composition over inheritance' with reference to code reuse, class coupling, and software maintainability. [6 marks]

    1. 1.Step 1: Define inheritance ('is-a') and its drawback: tight coupling where subclasses depend heavily on superclass implementation details (the fragile base class problem).
    2. 2.Step 2: Define composition ('has-a') and how code reuse is achieved: containing instances of other classes and delegating tasks to them.
    3. 3.Step 3: Compare coupling: Composition enforces loose coupling because components interact purely through well-defined public interfaces without exposing internal state.
    4. 4.Step 4: Compare flexibility: Inheritance is static and fixed at compile time, whereas composition allows dynamic alteration of behavior at runtime by substituting components.
    5. 5.Step 5: Synthesize impact on maintainability: Changes to component classes do not break the container class as long as the interface remains stable, reducing ripple effects in large codebases.
    Final Answer: Inheritance creates a rigid 'is-a' hierarchy with tight coupling, meaning changes to a parent class risk breaking subclasses. Composition creates a 'has-a' relationship with loose coupling, reusing code by assembling independent objects that interact via public interfaces. This allows dynamic runtime modifications, protects encapsulation, and significantly simplifies long-term software maintenance.
    Active Recall Memory Test
    What happens to the component object in composition when the container object is deleted?
    Key Fact: The component object is also destroyed because its lifecycle is completely dependent on the container.
    Which UML symbol denotes a composition relationship?
    Key Fact: A solid, filled black diamond placed at the end of the line attached to the owning (composite) class.
    What relationship phrase describes composition as opposed to inheritance?
    Key Fact: Composition represents a 'has-a' relationship, whereas inheritance represents an 'is-a' relationship.
    Why does composition lead to looser coupling than inheritance?
    Key Fact: The composite class depends only on the public interface of the component class, without being vulnerable to changes in its internal implementation details.
    Frequently Asked Questions
    What is the difference between composition and aggregation?
    Both represent 'has-a' associations, but they differ fundamentally in lifecycle dependency. In composition, the contained object cannot exist without the container; if the parent is destroyed, the child is destroyed. In aggregation, the contained object has an independent lifecycle and can continue to exist even if the container is destroyed.
    Why do software engineers say 'favor composition over inheritance'?
    Inheritance tightly couples child classes to parent classes, making deep hierarchies rigid and vulnerable to changes (the fragile base class problem). Composition achieves code reuse by assembling self-contained components that can be easily swapped, tested, or modified at runtime without breaking the outer class.
    How do you represent composition in Python code?
    In Python, composition is typically implemented by instantiating the component class directly inside the `__init__` constructor of the composite class. This ensures the component is created when the composite is created and ceases to have accessible references once the composite is deleted.
    Can a component object belong to more than one composite object in composition?
    No. In strict composition, a component part can belong to only one composite owner at any given time because its lifecycle and ownership are strictly bound to that single container.
    How do I remember whether the UML diamond is filled or hollow?
    A simple mnemonic is that composition is 'heavy' and 'solid' because the components are locked inside the container, so it gets the solid, filled diamond. Aggregation is 'lighter' and independent, so it gets the empty, hollow diamond.