Computer Science · 12th Grade

Active learning ideas

Modular Design and API Thinking

Active learning works well for modular design because students must experience firsthand how unclear boundaries and tight coupling create real problems. When students physically swap code modules in the Parallel Module Development lab, they feel the pain of integration failures caused by poor APIs, making abstract principles tangible.

• Common Core State Standards
• CSTA: 3B-AP-14
• CSTA: 3B-AP-15

• 15–60 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Think-Pair-Share
• 15 min · Pairs

Think-Pair-Share: What Belongs in the API?

Present a simple library management system and ask pairs to decide which functions belong in the public API versus which are internal implementation details. Pairs then share their reasoning; the class discovers that different reasonable choices lead to different coupling outcomes. The discussion anchors the concept of information hiding in a concrete context.

How do well-defined interfaces make software easier to build and maintain?

Facilitation Tip

During Think-Pair-Share: What Belongs in the API?, circulate and listen for whether pairs are grouping functions by feature or by technical layer.

What to look for

Students work in pairs to design an API for a simple calculator module. One student proposes the API (function names, parameters, return types), and the other critiques it for clarity, completeness, and adherence to modular design principles. They then swap roles for a different module, like a date formatter.

• Understand
• Apply
• Analyze
• Self-Awareness
• Relationship Skills

Activity 02

• Collaborative Problem-Solving
• 60 min · Small Groups

Collaborative Problem-Solving: Parallel Module Development

Divide the class into two groups working on the same project, one builds a data-storage module, the other builds a display module. Each group writes only the API contract first (function signatures, parameters, return types, and a one-sentence description). Groups swap contracts, implement their module, then integrate. Breakages during integration reveal which contracts were ambiguous.

Analyze the benefits of breaking down a large program into smaller, independent modules.

Facilitation Tip

For the Lab: Parallel Module Development, provide a strict 15-minute design phase before coding to prevent students from skipping the API contract step.

What to look for

Present students with two code snippets: one demonstrating tightly coupled modules and another with loosely coupled modules using clear APIs. Ask students to identify which snippet is more maintainable and to explain their reasoning in 2-3 sentences, referencing concepts like coupling and API stability.

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

Activity 03

• Gallery Walk
• 22 min · Small Groups

Gallery Walk: API Critique

Post four printed API designs for a simple calculator module. Each design has a different flaw: one exposes internal state, one has inconsistent naming, one mixes concerns, one lacks error-handling specification. Groups rotate every four minutes and annotate each with the problem and a fix. Whole-class debrief generates a shared checklist for API quality.

Design a simple API for a software component, specifying its inputs, outputs, and behavior.

Facilitation Tip

During the Gallery Walk: API Critique, ask students to mark not just what they would change but why the change improves maintainability.

What to look for

On an index card, have students write down one software component they might want to create (e.g., a user authentication system, a file reader). Then, ask them to list three specific functions that would be part of its API, including the expected input and output for each.

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

Activity 04

• Role Play
• 35 min · Pairs

Role Play: Client and Implementer

Pairs take opposite roles, one is the client who writes code that calls the module, the other is the implementer who writes the module. They must agree on the API contract in writing before either writes code. After implementation, they test integration and reflect on which parts of the negotiation prevented bugs.

How do well-defined interfaces make software easier to build and maintain?

Facilitation Tip

In the Role Play: Client and Implementer, have students switch roles after 10 minutes to deepen empathy for both perspectives.

What to look for

Students work in pairs to design an API for a simple calculator module. One student proposes the API (function names, parameters, return types), and the other critiques it for clarity, completeness, and adherence to modular design principles. They then swap roles for a different module, like a date formatter.

• Apply
• Analyze
• Evaluate
• Social Awareness
• Self-Awareness

A few notes on teaching this unit

Teachers should model the frustration of changing one part of a tightly coupled system by demonstrating how a small change ripples through dependent code. Avoid jumping straight to 'this is why modular design matters'—let students discover it through controlled failure. Research shows that students grasp encapsulation better when they write code that breaks due to tight coupling and then fix it by introducing clear interfaces.

Students will articulate why single-responsibility modules matter, write clean API contracts, and critique designs for clarity and maintainability. Success looks like students arguing about parameter names and return types rather than debating stylistic choices, showing they have internalized API thinking.

---

Watch Out for These Misconceptions

• During Think-Pair-Share: What Belongs in the API?, watch for students grouping functions based solely on file location or technical type rather than logical responsibility.

  Have pairs compare their groupings to the Single Responsibility Principle checklist provided in the activity handout, then revise any modules that include functions like validateInput(), saveToDatabase(), and displayResults().

• During Lab: Parallel Module Development, watch for students treating the API as an afterthought and hardcoding values to make their modules compile.

  Pause the lab after 10 minutes and require teams to present their API contract to another team. If any function signatures include hardcoded values, ask how the implementer would know what values are allowed.

• During Gallery Walk: API Critique, watch for students critiquing API aesthetics (e.g., camelCase vs snake_case) instead of design quality.

  Provide critique cards with prompts like 'Which functions expose internal details?' and 'Where could a change in one module break another?' to refocus feedback.

---

Methods used in this brief

• Think-Pair-Share
• Collaborative Problem-Solving
• Gallery Walk
• Role Play