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.

• 12th Grade
• Computer Science
• 4 activities
• 15 min–60 min

Learning Objectives

1. Analyze the impact of module coupling on system maintainability by comparing tightly coupled and loosely coupled code examples.
2. Design a simple API for a data storage module, specifying function signatures, parameter types, and return values.
3. Evaluate the reusability of a software component based on its API design and adherence to the single responsibility principle.
4. Create a small program that utilizes a pre-defined API for a third-party library, demonstrating effective integration.
5. Explain how encapsulation supports modular design by hiding implementation details and exposing only a stable interface.

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.

Prepare & details

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.

Setup: Standard classroom seating; students turn to a neighbor

Materials: Discussion prompt (projected or printed), Optional: recording sheet for pairs

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

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.

Prepare & details

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.

Setup: Groups at tables with problem materials

Materials: Problem packet, Role cards (facilitator, recorder, timekeeper, reporter), Problem-solving protocol sheet, Solution evaluation rubric

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

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.

Prepare & details

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.

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

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.

Prepare & details

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.

Setup: Open space or rearranged desks for scenario staging

Materials: Character cards with backstory and goals, Scenario briefing sheet

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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.

What to Teach Instead

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().

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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

Assessment Ideas

Peer Assessment

After Think-Pair-Share: What Belongs in the API?, collect the API proposals and have students swap roles to evaluate each other’s designs using a rubric that scores clarity, completeness, and adherence to single responsibility.

Quick Check

During Lab: Parallel Module Development, collect the API contracts from each team and randomly select one to display anonymously. Ask students to identify which contract is most likely to cause integration problems and explain their reasoning in 2-3 sentences.

Exit Ticket

After Role Play: Client and Implementer, have students write a 2-3 sentence reflection on one thing they would do differently in their own API design based on feedback from their partner.

Extensions & Scaffolding

• Challenge: Ask students to add a feature to their calculator API that requires modifying only one module, then document how the change affects other parts of the system.
• Scaffolding: Provide a partially written module with a clear but incorrect API, and ask students to redesign the interface before implementing the required functionality.
• Deeper exploration: Have students research how real-world APIs (e.g., Google Maps, Stripe) handle versioning and backward compatibility, then propose a versioning scheme for their own module.

Key Vocabulary

Module	A self-contained unit of software with a specific function and a defined interface, designed to be reusable and replaceable.
API (Application Programming Interface)	A set of rules, protocols, and tools that defines how software components interact, specifying inputs, outputs, and expected behaviors.
Encapsulation	The bundling of data and methods that operate on the data within a single unit, hiding internal details and exposing only necessary functionality through an interface.
Coupling	The degree of interdependence between software modules; low coupling is desirable for maintainability and reusability.
Cohesion	The degree to which the elements within a single module belong together; high cohesion is desirable, meaning a module focuses on a single, well-defined task.