Computer Science · Grade 11

Active learning ideas

Composition vs. Inheritance

Active learning helps students grasp composition versus inheritance by doing rather than listening. Programming challenges make abstract relationships concrete, while discussions expose reasoning gaps in real time. This approach builds intuition for trade-offs in flexibility, coupling, and maintainability that lectures alone cannot convey.

• Ontario Curriculum Expectations
• CS.HS.D.1
• CS.HS.P.4

• 30–50 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Formal Debate
• 45 min · Pairs

Pair Programming: Vehicle Design Challenge

Pairs sketch 'is-a' and 'has-a' relationships for vehicles, engines, and wheels. They code both inheritance and composition versions, then run tests to swap engine types. Discuss which approach allows easier changes.

Differentiate between 'is-a' and 'has-a' relationships in object-oriented design.

Facilitation Tip

During the Pair Programming: Vehicle Design Challenge, ask pairs to swap partners after the first 20 minutes to expose them to different design approaches.

What to look for

Present students with two class diagrams: one using inheritance (e.g., 'Dog' inherits from 'Animal') and another using composition (e.g., 'Car' has an 'Engine'). Ask students to write one sentence for each diagram explaining the relationship modeled and identify which uses 'is-a' and which uses 'has-a'.

• Analyze
• Evaluate
• Create
• Self-Management
• Decision-Making

Activity 02

• Formal Debate
• 50 min · Small Groups

Small Groups: Refactoring Relay

Groups receive inheritance-based code for a library system. Each member refactors one class to composition, passes to the next, and notes changes in flexibility. Debrief as a class on outcomes.

Analyze the advantages of composition over inheritance in terms of flexibility and maintainability.

Facilitation Tip

In Small Groups: Refactoring Relay, provide starter code with deep inheritance and require groups to submit a flattened version before adding new features.

What to look for

Pose the scenario: 'Imagine you are designing a system for different types of electronic devices (e.g., smartphone, tablet, laptop). Discuss with a partner whether you would primarily use inheritance or composition to model the shared functionalities like 'power on/off' and 'display screen'. Justify your choice.'

• Analyze
• Evaluate
• Create
• Self-Management
• Decision-Making

Activity 03

• Formal Debate
• 40 min · Whole Class

Whole Class: Design Debate

Divide class into teams: one defends inheritance, the other composition for a game character system. Teams code minimal examples, present pros/cons with live demos, and vote on best fit.

Justify the choice between composition and inheritance for a given design problem.

Facilitation Tip

During Whole Class: Design Debate, assign roles like 'inheritance advocate' or 'composition advocate' to ensure balanced participation.

What to look for

Ask students to write down one situation where inheritance would be a suitable design choice and one situation where composition would be preferable. For each, briefly explain why their chosen principle fits the scenario.

• Analyze
• Evaluate
• Create
• Self-Management
• Decision-Making

Activity 04

• Formal Debate
• 30 min · Individual

Individual: Choice Justification

Students select a personal project, implement using one principle, then refactor to the other. Write a short report justifying the final choice based on maintainability and flexibility.

Differentiate between 'is-a' and 'has-a' relationships in object-oriented design.

Facilitation Tip

For Individual: Choice Justification, require students to submit both a code snippet and a 2-sentence rationale to reveal gaps between design and explanation.

What to look for

Present students with two class diagrams: one using inheritance (e.g., 'Dog' inherits from 'Animal') and another using composition (e.g., 'Car' has an 'Engine'). Ask students to write one sentence for each diagram explaining the relationship modeled and identify which uses 'is-a' and which uses 'has-a'.

• Analyze
• Evaluate
• Create
• Self-Management
• Decision-Making

A few notes on teaching this unit

Experienced teachers introduce this topic by modeling flawed designs first, letting students experience the pain of change. Research shows that students overuse inheritance until they feel its brittleness firsthand. Avoid teaching composition as 'inheritance but different'—instead focus on modeling relationships students recognize from everyday objects like cars or computers.

Successful learning looks like students confidently explaining why a design uses composition or inheritance and backing it with code examples. They should also critique designs without defaulting to inheritance and justify choices based on changeability. Peer reviews and refactoring outputs show clear evidence of this understanding.

---

Watch Out for These Misconceptions

• During Pair Programming: Vehicle Design Challenge, watch for students defaulting to inheritance for code reuse without considering delegation.

  Prompt pairs to ask, 'Can this part change independently of the whole?' and require them to sketch a composition alternative before coding.

• During Small Groups: Refactoring Relay, watch for students flattening hierarchies without testing substitutability.

  Require groups to write unit tests that verify subclass instances can replace superclass instances before submitting their refactored code.

• During Whole Class: Design Debate, watch for students conflating 'is-a' with 'has-a' when justifying choices.

  Ask groups to map their designs to UML and label each relationship as 'is-a' or 'has-a' before presenting, ensuring clarity in their arguments.

---

Methods used in this brief

• Formal Debate