Introduction to Programming Paradigms

This topic asks students to think like builders who must anticipate problems before they happen, not just coders who make things work. Active learning works because students need to experience firsthand how fragile systems can be, rather than just hear about defensive techniques in theory.

• Year 11
• Computing
• 3 activities
• 15 min–30 min

Learning Objectives

1. Compare the core principles of imperative, object-oriented, and event-driven programming paradigms.
2. Explain the advantages of object-oriented programming over imperative programming for managing complex software projects.
3. Analyze a given problem scenario and justify the selection of the most appropriate programming paradigm for its solution.
4. Demonstrate how event-driven programming responds to user interactions or system signals, contrasting it with sequential execution.

Simulation Game

⏱ 30 min·Pairs

Simulation Game: The Code Breaker

In pairs, one student acts as the 'developer' and the other as the 'malicious user'. The user tries to crash the developer's program using extreme values, wrong data types, or empty inputs, while the developer tries to patch the holes in real-time.

Prepare & details

Compare the benefits of object-oriented programming over imperative programming for large projects.

Facilitation Tip: During The Code Breaker simulation, assign clear roles such as 'attacker', 'defender', and 'observer' to ensure every student contributes to the problem-solving process.

Setup: Flexible space for group stations

Materials: Role cards with goals/resources, Game currency or tokens, Round tracker

• Apply
• Analyze
• Evaluate
• Create
• Social Awareness
• Decision-Making

Gallery Walk

⏱ 20 min·Small Groups

Gallery Walk: Validation Critique

Post different snippets of validation code around the room (e.g., range checks, length checks, presence checks). Students move in groups to identify which specific errors each snippet prevents and which it might still let through.

Prepare & details

Explain how event-driven programming differs from traditional sequential execution.

Facilitation Tip: In the Validation Critique Gallery Walk, provide a simple scoring rubric so students focus on defensible evidence rather than subjective opinions.

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

Think-Pair-Share

⏱ 15 min·Pairs

Think-Pair-Share: UX vs Security

Students discuss the trade-offs between making a program easy to use and making it secure. For example, should a password require 20 characters and a biometric scan? They then share their 'balanced' security policy with the class.

Prepare & details

Analyze a simple problem and determine which programming paradigm would be most suitable for its solution.

Facilitation Tip: Use the Think-Pair-Share UX vs Security discussion to structure turn-taking so quieter students have space to contribute before the whole class shares.

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

Teaching This Topic

Experienced teachers approach this topic by framing programming as a service to users, not just a technical task. Avoid letting students treat validation as a checkbox exercise; instead, connect each technique to real-world consequences. Research shows that when students role-play attackers, they better understand why defensive design matters. Keep the focus on concrete, fixable problems rather than abstract theory.

What to Expect

Successful learning looks like students confidently identifying when and why to use input validation, sanitization, and authentication in different contexts. They should be able to explain trade-offs between user experience and security, and justify their design choices with evidence from activities.

Watch Out for These Misconceptions

Common Misconception

During The Code Breaker simulation, watch for students who assume validation is only about syntax or format. Redirect them by asking, 'Could a malicious user still cause harm if the input looks correct on the surface?'

What to Teach Instead

During The Code Breaker simulation, have students test their defenses by crafting inputs that bypass basic checks, then revise their validation rules based on what they learn from the failed attempts.

Common Misconception

During the Validation Critique Gallery Walk, watch for students who believe UI constraints eliminate the need for server-side validation. Redirect them by asking, 'What happens if someone sends data directly to the server without using the UI?'

What to Teach Instead

During the Validation Critique Gallery Walk, provide actual 'inspect element' tools and sample HTML forms so students can see how easily front-end restrictions can be bypassed.

Assessment Ideas

Quick Check

After The Code Breaker simulation, present students with three short code snippets, each representing a different programming paradigm. Ask them to identify which paradigm each snippet exemplifies and briefly state one characteristic that led to their choice.

Discussion Prompt

During the Think-Pair-Share UX vs Security discussion, use the prompt: 'Imagine you are building a simple calculator application versus a complex social media platform. Which programming paradigm would you choose for each, and why? Consider the benefits for code organization, reusability, and handling user interactions.' Listen for evidence of trade-offs between usability and security.

Exit Ticket

After the Validation Critique Gallery Walk, ask students to write down one key difference between input validation and sanitization. Then, have them describe a scenario where poor sanitization could lead to a security vulnerability.

Extensions & Scaffolding

• Challenge early finishers to design a multi-layered authentication system for a mock banking app, including at least three distinct validation checks.
• Scaffolding for struggling students: provide partially completed code snippets with missing validation checks, asking them to identify and add the missing parts.
• Deeper exploration: ask students to research and present one historical cybersecurity breach, explaining how defensive design could have prevented it.

Key Vocabulary

Imperative Programming	A programming paradigm that describes computation in terms of statements that change a program's state. It focuses on how to achieve a result through a sequence of commands.
Object-Oriented Programming (OOP)	A programming paradigm based on the concept of 'objects', which can contain data in the form of fields (often known as attributes or properties) and code in the form of procedures (often known as methods).
Event-Driven Programming	A programming paradigm in which the flow of the program is determined by events, such as user actions (mouse clicks, key presses) or sensor outputs.
Sequential Execution	The standard flow of control in many programs where instructions are executed one after another in the order they appear.