Teacher guide, AP Computer Science A

Start with teamwork. Reveal the Java underneath.

This is designed for the first day of second semester. Students have completed Units 1 through 3, so classes, objects, attributes, constructors, methods, conditionals, and Boolean expressions are review. Arrays, ArrayList, and formal sorting algorithms are intentionally presented only as a preview of what comes next.

Launch classroom presentation Open student activity

Semester 2 placement and prior knowledge

Why this works well on the first day of second semester

This lesson is intentionally positioned as a review-and-bridge activity. Students are not beginning AP Computer Science A from scratch. They have already completed Units 1, 2, and 3, so the activity should reactivate ideas they have used before while giving them a concrete experience that will support later units.

Students should already recognize: classes as blueprints, objects as instances, attributes / instance variables as object state, constructors, methods, parameters, return values, conditionals, and Boolean expressions. During the discussion, ask students to use that familiar vocabulary to describe the deck. For example, a physical playing card can be modeled as one Card object, while suit and rank can be represented as attributes.

Arrays and ArrayList are new. Students have not reached Unit 4, so do not expect them to know collection syntax, indexes, traversal, or how to implement a sorting algorithm in Java. The physical deck is used to create a need for those ideas: once students can describe one Card object, ask, "How could Java keep track of 52 Card objects together?" That question previews collections naturally without turning the first day into a Unit 4 lecture.

Sorting algorithms are also a preview. Students may naturally use selection-sort-like, insertion-sort-like, or divide-and-combine strategies. Name those patterns only after students describe what they actually did. The goal is recognition and curiosity, not mastery or implementation.

This structure lets the lesson serve three purposes at once: it rebuilds classroom collaboration after the semester break, reviews core object-oriented vocabulary from first semester, and creates a concrete reference point you can return to when arrays, ArrayList, and sorting are formally taught later.

Learning goals

Collaboration and problem solving

Plan and revise a team strategy.
Compare correctness and efficiency.
Explain how roles and data organization affect performance.

CSA conceptual bridge

Model a card as an object with attributes.
Review a Card as an object with attributes and methods.
Preview why a deck needs a collection such as an array or ArrayList<Card>.
Recognize that team procedures are algorithms and preview formal sorting strategies.

Suggested 50 to 55 minute lesson

Welcome and frame the challenge, 5 minutes

Tell students that computer science is about designing solutions, not simply typing code. Put students in groups of about four. Keep introductions brief because the task itself is the relationship-building activity.

Explain the target and rules, 3 minutes

Cards must be grouped by suit and ascending rank. The final deck is face down. Every teammate raises both hands. Post A through K for students unfamiliar with playing cards.

Round 1, 5 minutes

Have students shuffle, then begin immediately. Record completion times. Watch for collisions, idle students, duplicate work, self-assigned roles, and emerging sorting strategies.

Verify and debrief, 6 minutes

Check the fastest groups for correctness. Ask what worked, where the bottlenecks were, and what they would change. Emphasize that a fast but incorrect result is not a successful algorithm.

Plan Round 2, 2 minutes

Give one minute of no-touch planning. Encourage teams to decide roles, data layout, how sub-results will be merged, and how correctness will be checked.

Round 2, 5 minutes

Shuffle again and repeat. Record the new times. Most groups improve, but a slower round is also useful evidence if the new plan introduced overhead or confusion.

CSA concept reveal, 15 minutes

Begin with familiar material: model one physical card as a Card object and review attributes, constructors, and accessor methods. Then ask how Java could hold 52 objects at once. Use that question to preview arrays and ArrayList without expecting students to know the syntax yet. Finally, connect the teams' procedures to the idea of sorting algorithms.

Reflection, 8 to 10 minutes

Students write their Round 2 algorithm and identify which physical parts of the task map to objects, attributes, collections, methods, and sorting strategies.

What to watch for during the activity

Natural decomposition

One student takes each suit. Students separate red and black first. Teams create multiple sorting zones.

Shared-state problems

Several hands reach for one pile, cards are moved twice, or a teammate cannot tell whether another person already handled a card.

Algorithm choice

Some groups scan for the next needed card. Others make ordered piles as cards arrive. Others divide, sort, and merge.

Where this fits in the course

Already learned, Units 1 through 3: classes, objects, attributes / instance variables, constructors, methods, parameters, return values, conditionals, and Boolean expressions. Use the card activity to reactivate this vocabulary rather than reteach it from the beginning.

Not yet learned: Unit 4 arrays, ArrayList, indexed collections, traversal, and formal Java implementations of sorting algorithms. Treat these only as a preview. Students should leave understanding why a collection would be useful, not how to code one yet.

Later payoff: when arrays, ArrayList, selection sort, insertion sort, or object collections are introduced, refer back to the physical deck and the strategies students created on this day.

CSA concept map

Objects and attributes

Physical experience: every card is a distinct thing with a suit and rank.

Java connection: each card can be an instance of Card. Its state can be represented with instance variables such as suit and rank.

Arrays and ArrayList

Physical experience: the deck is an ordered collection whose contents can move.

Java connection: preview that many Card objects can be stored in Card[] or ArrayList<Card>. This is new material, so focus on the need for a collection, not syntax or traversal.

Methods

Physical experience: students repeatedly inspect, compare, move, exchange, and verify cards.

Java connection: behaviors can be represented through constructors, accessor methods, helper methods, compareTo, and deck-level methods such as shuffle or sort.

Sorting algorithms

Physical experience: groups solve the same ordering problem with different strategies.

Java connection: compare their strategies to selection sort, insertion sort, and divide-and-combine approaches. Focus first on the idea and tradeoffs, not memorizing implementation details.

Java bridge code

Keep the first example firmly in review territory. Show the collection syntax only after students understand the need for it, and label it as a preview rather than something they should already know.

public class Card { private String suit; private int rank; public Card(String suit, int rank) { this.suit = suit; this.rank = rank; } public String getSuit() { return suit; } public int getRank() { return rank; } }

// NEW PREVIEW, not prior knowledge Card[] deck = new Card[52]; // Later students will also learn ArrayList: ArrayList<Card> cards = new ArrayList<Card>();

Sorting questions for discussion

Selection sort connection

Did anyone repeatedly scan the remaining cards for the smallest or next-needed card, then place it into position? That is selection-sort-like thinking.

Insertion sort connection

Did anyone maintain an already sorted row or pile and insert each new card where it belonged? That resembles insertion sort.

Divide and combine

Did the team split the deck by suit, let different people sort smaller sets, then combine the results? That introduces the intuition behind divide-and-conquer strategies.

Efficiency

Ask what operations cost time: comparisons, searching, moving cards, waiting for a teammate, rechecking work, and combining piles.

Facilitation moves

If a student is watching, say: "Your group has another processor available. How could you use it?"
Do not immediately fix inefficient strategies. Let the consequences create evidence for the debrief.
If students are unfamiliar with cards, post the rank sequence or remove face cards for the first round.
If under-shuffling is a concern, have groups shuffle and pass decks to neighboring groups.
Celebrate improvement, correctness, teamwork, and clear strategy, not only the fastest time.
Use mistakes to distinguish algorithm correctness from speed.

Exit ticket

Describe your team's Round 2 algorithm as a sequence of steps.
If a playing card were represented by a Java object, what attributes would it need?
Why would Java need a collection to represent a full deck of cards?
Name two useful methods a Card or Deck class might have.
Which sorting strategy best resembles what your group did, and why?

Optional next-day extension

Write instructions for the computer

Groups write a precise algorithm for sorting eight face-down cards under constrained rules. Another student or the teacher follows the instructions exactly. Ambiguity becomes visible immediately and sets up the transition from informal strategies to executable algorithms.

You can revisit the same physical deck later when students formally learn arrays, ArrayList, traversal, selection sort, insertion sort, or object comparison.