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.

• 11th Grade
• Computer Science
• 3 activities
• 25 min–40 min

Learning Objectives

1. Explain how inheritance allows a child class to acquire properties and behaviors from a parent class.
2. Analyze the benefits of code reuse and reduced redundancy when designing class hierarchies.
3. Design a class hierarchy for a given problem domain, identifying appropriate parent and child classes.
4. Critique proposed class hierarchies for accuracy in modeling relationships and potential design flaws.

Project-Based Learning

⏱ 40 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.

Prepare & details

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

Facilitation Tip: During 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?'

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

Gallery Walk

⏱ 30 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.

Prepare & details

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

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

Setup: Wall space or tables arranged around room perimeter

Materials: Large paper/poster boards, Markers, Sticky notes for feedback

• Understand
• Apply
• Analyze
• Create
• Relationship Skills
• Social Awareness

Project-Based Learning

⏱ 25 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.

Prepare & details

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

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

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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'.

What to Teach Instead

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.

Common Misconception

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.

What to Teach Instead

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.

Common Misconception

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.

What to Teach Instead

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.

Assessment Ideas

Quick Check

After the Design Challenge: Build a Zoo Class Hierarchy, ask students to identify one potential parent class and two child classes for a new scenario, such as musical instruments. Have them list one inherited property and one unique behavior for each child, then discuss their answers as a class.

Peer Assessment

During the Design Challenge: Build a Zoo Class Hierarchy, have students swap their class diagrams 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?' Collect these reflections to assess understanding.

Discussion Prompt

After the Gallery Walk: Inheritance or Composition?, facilitate a class discussion where students share examples of when inheritance was the right tool and when composition would have been better. Ask them to justify their reasoning using the 'is-a' versus 'has-a' distinction and the misconceptions they observed during the Gallery Walk.

Extensions & Scaffolding

• Challenge: Ask students to refactor a deep hierarchy (4+ levels) into a shallow one using composition, documenting their reasoning in comments.
• Scaffolding: Provide starter code with clear 'is-a' relationships for students who are struggling to identify parents and children.
• Deeper: Have students research the 'Liskov Substitution Principle' and revise their zoo hierarchy to comply with it, explaining their changes.

Key Vocabulary

Inheritance	A mechanism where a new class (child or subclass) derives properties and behaviors from an existing class (parent or superclass).
Class Hierarchy	An arrangement of classes where parent classes are at a higher level and child classes are at a lower level, forming a tree-like structure.
Code Reuse	The practice of using existing code in new programs, often facilitated by inheritance, to avoid rewriting common functionality.
Is-a Relationship	A type of relationship where a child class is a specialized version of its parent class, e.g., a 'Car' is a 'Vehicle'.
Has-a Relationship	A relationship where one class contains an instance of another class, e.g., a 'Car' has an 'Engine'. This is typically modeled with composition, not inheritance.