Computer Science · Grade 12

Active learning ideas

Abstract Data Types (ADTs)

Abstract Data Types require students to shift from concrete code to abstract thinking about behaviors and contracts. Active learning works here because students must design, explain, and defend interfaces without relying on implementation details, which builds durable understanding of abstraction in software design.

• Ontario Curriculum Expectations
• CS.DSAA.13
• CS.P.13

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

Activity 01

• Socratic Seminar
• 35 min · Pairs

Pairs: ADT Design Challenge

Pairs brainstorm a real-world scenario, such as a task manager, and specify its ADT with 4-5 operations, inputs, outputs, and preconditions. They write a contract document and peer-review another pair's design for clarity. Refine based on feedback.

Differentiate between a data structure and an Abstract Data Type.

Facilitation Tip

During the ADT Design Challenge, circulate and listen for students naming operations without describing storage or pointers, redirecting any implementation talk back to the interface.

What to look for

Present students with a list of terms including 'Stack', 'Array', 'Queue', 'Linked List', 'ADT', and 'Data Structure'. Ask them to categorize each term as either an ADT or a Data Structure and provide a one-sentence justification for their choice.

• Analyze
• Evaluate
• Create
• Social Awareness
• Relationship Skills

Activity 02

• Socratic Seminar
• 45 min · Small Groups

Small Groups: Multi-Implementation Demo

Groups implement the same Stack ADT using two methods: array and linked list. They test both with client code and compare performance. Discuss trade-offs in a group debrief.

Explain why ADTs are crucial for software design and modularity.

Facilitation Tip

For the Multi-Implementation Demo, prepare a shared workspace where groups can visibly see how different structures serve the same ADT, making the separation concrete.

What to look for

Pose the question: 'Imagine you are building a system to manage a library's book catalog. What operations would be essential for a 'BookCollection' ADT? Discuss with a partner and list at least five operations, considering how the ADT's interface would be useful even if you don't know how the books will be stored yet.'

• Analyze
• Evaluate
• Create
• Social Awareness
• Relationship Skills

Activity 03

• Socratic Seminar
• 50 min · Whole Class

Whole Class: Client-Provider Role Play

Divide class into client teams needing an ADT and provider teams implementing it based only on the spec. Clients report issues from mismatches. Debrief on interface importance.

Design an ADT for a simple data collection, specifying its operations.

Facilitation Tip

In the Client-Provider Role Play, assign roles strictly so students experience the frustration of unclear specs, then debrief how ADTs solve this problem.

What to look for

In pairs, students design an ADT for a simple 'TodoList' application, specifying its operations. They then swap their specifications. Each student reviews their partner's ADT, checking for clarity, completeness of operations, and potential ambiguities in the interface. They provide one specific suggestion for improvement.

• Analyze
• Evaluate
• Create
• Social Awareness
• Relationship Skills

Activity 04

• Socratic Seminar
• 25 min · Individual

Individual: Custom ADT Prototype

Students design an ADT for a personal collection, like a music playlist, and pseudocode three operations. Share one via class poll for votes on best design.

Differentiate between a data structure and an Abstract Data Type.

Facilitation Tip

When students build their Custom ADT Prototype, require them to write a one-page justification explaining why each operation belongs in the interface and how it supports modularity.

What to look for

Present students with a list of terms including 'Stack', 'Array', 'Queue', 'Linked List', 'ADT', and 'Data Structure'. Ask them to categorize each term as either an ADT or a Data Structure and provide a one-sentence justification for their choice.

• Analyze
• Evaluate
• Create
• Social Awareness
• Relationship Skills

A few notes on teaching this unit

Start with concrete code examples to show the limitations of tight coupling between interface and implementation. Avoid teaching ADTs in isolation; instead, connect them to real-world systems like queueing at a bank or managing a playlist. Research shows that repeated practice articulating interfaces, not just using them, strengthens abstraction skills. Finally, emphasize that ADTs are tools for human communication, not just technical requirements.

By the end of these activities, students will confidently define an ADT’s interface, compare multiple implementations, and justify the value of abstraction in system design. Success looks like clear operation specifications, peer feedback that strengthens interfaces, and explanations that separate ‘what’ from ‘how’.

---

Watch Out for These Misconceptions

• During the ADT Design Challenge, watch for students including implementation details like 'use an array of size 100' in their Queue interface.

  Redirect them by asking, 'What happens if the queue grows beyond 100 items? How would you describe the enqueue operation without mentioning storage?' Use peer feedback to highlight when interfaces lack clarity.

• During the Multi-Implementation Demo, watch for groups arguing that one data structure is 'better' for a specific ADT, confusing implementation with the ADT itself.

  Ask each group to present how their structure fulfills the same interface. Use a Venn diagram on the board to show overlap in operations and differences in storage, reinforcing that the ADT remains unchanged.

• During the Client-Provider Role Play, watch for students skipping operation specifications and jumping straight to code.

  Pause the role play after the first vague request and ask the client to restate their needs using only operations. Provide a template for operation definitions to guide the provider back to the interface.

---

Methods used in this brief

• Socratic Seminar