Computer Science · Grade 11

Active learning ideas

Class Hierarchies and Inheritance

Active learning works well for class hierarchies and inheritance because students need to struggle through concrete design decisions to truly grasp abstraction, reuse, and flexibility. By building systems together, they confront the trade-offs of deep inheritance trees and the power of shared logic in real time.

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

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

Activity 01

• Project-Based Learning
• 35 min · Pairs

Pair Programming: Shape Hierarchy Build

Pairs start with a Shape parent class including area and perimeter methods. They create Circle and Rectangle children that override these with specific formulas. Finally, they instantiate objects and test polymorphism by calling methods on a list of shapes.

How can we design a class hierarchy that is flexible enough for future requirements?

Facilitation Tip

During Pair Programming: Shape Hierarchy Build, circulate and ask each pair to explain why they chose a particular attribute or method for their child class over the parent.

What to look for

Present students with a scenario, e.g., modeling different types of musical instruments. Ask them to identify a potential superclass and two subclasses, listing one unique attribute or method for each subclass. This checks their ability to conceptualize hierarchies.

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

Activity 02

• Project-Based Learning
• 45 min · Small Groups

Small Group Refactor: Deep Tree Challenge

Provide code with a four-level inheritance tree modeling employees. Groups identify redundancy and fragility, then refactor to a two-level hierarchy using composition where suitable. Groups present changes and trade-offs to the class.

What are the dangers of deep inheritance trees in large software projects?

Facilitation Tip

For the Small Group Refactor: Deep Tree Challenge, provide a starter hierarchy that is already too deep and ask groups to measure lines of code before and after refactoring to composition.

What to look for

Pose the question: 'When might it be better to use composition (having an object contain another object) instead of inheritance?' Facilitate a discussion where students articulate the trade-offs, focusing on flexibility and avoiding deep, rigid hierarchies.

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

Activity 03

• Project-Based Learning
• 50 min · Whole Class

Whole Class Design: Animal Kingdom System

As a class, brainstorm a hierarchy for zoo animals with Mammal and Bird parents. Assign subgroups to code one branch, integrate via shared drive, and run simulations to demonstrate inheritance in action.

How does inheritance promote the principle of DRY (Don't Repeat Yourself)?

Facilitation Tip

In the Whole Class Design: Animal Kingdom System, interrupt once to ask each table to share one method they kept in the parent class and one they moved to a child, then make the class list visible to the whole room.

What to look for

Give students a small code snippet demonstrating inheritance. Ask them to write down what the output will be and explain, in one sentence, how inheritance made the code shorter than if they had written it without a parent class.

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

Activity 04

• Project-Based Learning
• 25 min · Individual

Individual Debug: Inheritance Errors Hunt

Students receive broken hierarchy code with issues like inaccessible members or wrong overrides. Individually, they fix errors, add tests, and explain changes in a short journal entry.

How can we design a class hierarchy that is flexible enough for future requirements?

Facilitation Tip

While running the Individual Debug: Inheritance Errors Hunt, require students to write the exact error message they get when trying to access a private field from a child class and explain why it happened.

What to look for

Present students with a scenario, e.g., modeling different types of musical instruments. Ask them to identify a potential superclass and two subclasses, listing one unique attribute or method for each subclass. This checks their ability to conceptualize hierarchies.

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

A few notes on teaching this unit

Start with shallow hierarchies to build confidence, then intentionally introduce deep ones to surface pain points. Use pair programming to model professional collaboration, and always debrief refactoring exercises by having students articulate the impact on future changes. Avoid rushing to composition; let students feel the maintenance burden first so they can choose the right tool.

Successful learning looks like students confidently designing parent-child relationships that reduce duplication without creating rigid dependencies. You will see them discuss access modifiers, justify overrides, and compare inheritance with composition in small-group settings.

---

Watch Out for These Misconceptions

• During Pair Programming: Shape Hierarchy Build, watch for students who create very deep hierarchies without discussing the trade-offs.

  Ask each pair to count the number of classes and methods in their hierarchy, then prompt them to discuss how adding one more child class would affect future changes. Guide them to consider alternatives during the next activity.

• During Individual Debug: Inheritance Errors Hunt, watch for students who assume all parent members are available in the child class.

  Have students try to access a private field from a child class and observe the compiler error. Use this moment to discuss access modifiers and encapsulation, then ask them to modify the parent class to make the field protected.

• During Small Group Refactor: Deep Tree Challenge, watch for students who override methods unnecessarily to share code.

  Ask groups to identify methods that do not need overrides and keep them in the parent class. Then have them compare the refactored code size to the original and discuss when overrides are truly useful.

---

Methods used in this brief

• Project-Based Learning