Skip to content
Computer Science · 11th Grade

Active learning ideas

Inheritance: Building Class Hierarchies

Inheritance is tricky because it feels intuitive until real code breaks. Students need to experience the tension between code reuse and tight coupling firsthand. Active learning forces them to confront misconceptions like 'more inheritance is always better' by building and then debugging their own class hierarchies.

Common Core State StandardsCSTA: 3B-AP-14CSTA: 3B-AP-15
25–40 minPairs → Whole Class3 activities

Activity 01

Project-Based Learning40 min · Small Groups

Design Challenge: Build a Zoo Class Hierarchy

Groups design a class hierarchy for a zoo management system. They identify parent classes, child classes, inherited attributes and methods, and any behaviors that need to be overridden. Groups draw their hierarchy on paper or a whiteboard, then present it to the class and field questions about their design decisions.

Explain how inheritance allows new classes to acquire properties and behaviors from existing ones.

Facilitation TipDuring the Design Challenge, circulate and ask each group, 'Does this change in the parent class break anything in the child? How could you prevent that?'

What to look forPresent students with a scenario, for example, designing classes for different types of musical instruments. Ask them to identify one potential parent class and two child classes, listing one inherited property and one unique behavior for each child.

ApplyAnalyzeEvaluateCreateSelf-ManagementRelationship SkillsDecision-Making
Generate Complete Lesson

Activity 02

Gallery Walk30 min · Small Groups

Gallery Walk: Inheritance or Composition?

Post six design scenarios around the room (e.g., Vehicle/Car/Truck, Employee/Manager, Shape/Circle, Library item/Book/DVD). Students rotate with sticky notes, marking each scenario 'Inheritance' or 'Composition' and writing a one-sentence reason. Debrief on contested cases to explore where reasonable designers disagree.

Analyze the benefits of code reuse and reduced redundancy through inheritance.

Facilitation TipFor the Gallery Walk, assign each pair a specific misconception to watch for in their peers' work, then discuss as a class.

What to look forStudents individually design a simple class hierarchy for a given domain (e.g., shapes, vehicles). They then swap designs with a partner and answer: 'Does the 'is-a' relationship make sense for all parent-child connections? Are there any obvious redundancies that could be moved to a parent class?'

UnderstandApplyAnalyzeCreateRelationship SkillsSocial Awareness
Generate Complete Lesson

Activity 03

Project-Based Learning25 min · Individual

Code Tracing: What Does This Class Inherit?

Provide a three-level inheritance hierarchy in code with five method calls. Students trace through each call individually, determining whether the method comes from the parent or child class and what the output will be before running the code. Compare predictions with actual output, then discuss surprising cases.

Design a class hierarchy for a given problem domain, identifying parent and child classes.

Facilitation TipIn the Code Tracing activity, require students to annotate each inherited member with its visibility modifier and accessibility in the child class.

What to look forPose the question: 'When is inheritance the right tool for code organization, and when might composition be a better choice?' Facilitate a class discussion where students share examples and justify their reasoning, referencing the 'is-a' versus 'has-a' distinction.

ApplyAnalyzeEvaluateCreateSelf-ManagementRelationship SkillsDecision-Making
Generate Complete Lesson

A few notes on teaching this unit

Teach inheritance by starting with the concrete: ask students to model real-world hierarchies they know, like vehicles or animals. Emphasize that inheritance is a tool for modeling 'is-a' relationships, not just a way to avoid writing code twice. Avoid abstract lectures about polymorphism; let students discover its value through debugging their own hierarchies. Research shows that students grasp inheritance better when they first see it break, so design activities that force them to confront tight coupling and fragile base class problems.

Students will design class hierarchies that balance code reuse with flexibility, avoiding deep inheritance chains and understanding visibility modifiers. They will justify their design choices using 'is-a' relationships and identify when to use composition instead.


Watch Out for These Misconceptions

  • During the Design Challenge: Build a Zoo Class Hierarchy, watch for students who create a single top-level class like 'Animal' with dozens of child classes like 'Lion', 'Penguin', 'Kangaroo'.

    During the Design Challenge, point students to the 'Deep inheritance hierarchies are a warning sign' misconception and ask them to split the hierarchy into 'Mammal', 'Bird', and 'Marsupial' layers. Have them justify each layer by identifying shared behaviors and properties that belong there.

  • During the Code Tracing: What Does This Class Inherit? activity, watch for students who assume they can access all parent class members from the child class.

    During the Code Tracing activity, provide a class hierarchy with private, protected, and public members in the parent class. Ask students to trace which members are accessible in the child class and explain why, using the visibility modifiers as evidence.

  • During the Gallery Walk: Inheritance or Composition?, watch for students who default to inheritance for every relationship, even when a 'has-a' relationship would make more sense.

    During the Gallery Walk, assign each pair a different misconception to look for, including the 'is-a' versus 'has-a' distinction. Have them circle any classes where composition might be a better fit and explain their reasoning to the class.


Methods used in this brief