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
- 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
- 1Day 1-2: Review core OOP association types and write precise definitions for Association, Aggregation, and Composition.
- 2Day 3-4: Practice drawing and interpreting UML diagrams, paying special attention to relationship arrows, solid diamonds, and multiplicities.
- 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.
- 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)
State the precise technical term (e.g., 'Composition') without unnecessary narration or lengthy explanation.
Set out the causes, characteristics, or mechanisms of composition, linking lifecycle dependency directly to system behavior.
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)
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.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.Step 2: Classify University-Department as composition.
- 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.Step 4: Classify Department-Lecturer as aggregation.
- 5.Step 5: Summarize the justification linking the definitions of composition (destruction cascades to components) and aggregation (independent lifecycle).
Question: Explain the phrase 'favor composition over inheritance' with reference to code reuse, class coupling, and software maintainability. [6 marks]
- 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.Step 2: Define composition ('has-a') and how code reuse is achieved: containing instances of other classes and delegating tasks to them.
- 3.Step 3: Compare coupling: Composition enforces loose coupling because components interact purely through well-defined public interfaces without exposing internal state.
- 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.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.