Teaching object oriented programming in Grades 11-12 (Level 2) unit cover (OAS L2.AP.M.01)

Teaching Constructing Solutions: Procedures, Modules & Objects in Grades 11-12 (Level 2): Oklahoma Standard L2.AP.M.01

Teaching Constructing Solutions: Procedures, Modules & Objects in Grades 11-12 (Level 2): Oklahoma Standard L2.AP.M.01

Teaching object oriented programming in grades 11-12 (level 2) does not have to be complicated. Picture a software engineer designing a payment-processing module that other engineers can call without knowing its internal implementation. That kind of thinking is exactly what Oklahoma's grades 11-12 (level 2) computer science standard L2.AP.M.01 asks students to practice — and it is very teachable with the right materials. This post walks through what the standard means, the misconceptions students bring to it, and discussion starters you can use tomorrow, whether you teach in a classroom or at your kitchen table.

What Does Standard L2.AP.M.01 Actually Ask?

Construct solutions to problems using student-created components (e.g., procedures, modules, objects). — Oklahoma Academic Standards for Computer Science (February 2023)

In plain language: This standard asks students to actually build a working solution using their own reusable pieces, deciding what belongs together as one piece and what should be kept separate.

In student-friendly terms, the learning target is: "I can construct a solution to a problem by designing my own procedures, modules, and objects, and I can explain why I chose each type of component for each part of the problem."

What Students Should Be Able to Do

  • I can design a procedure with a clear single task, appropriate parameters, and a correct return value.
  • I can group related procedures and shared data into a sensible module.
  • I can design a class with attributes and methods that clearly belong together, and describe how instances of that class differ from one another.
  • I can explain what a component's interface is and why hiding its internal implementation is useful.

Along the way, students pick up the working vocabulary of the topic: procedure, module, object, parameter, attribute, method, instance, class, interface, encapsulation, abstraction, component, constructor, reuse.

Object Oriented Programming: Misconceptions to Watch For

These are the wrong turns students reliably take with this standard — knowing them ahead of time is half the lesson plan. Each correction strategy below comes straight from the unit's teacher guide (the paragraph and activity references point into the unit itself).

1. "A procedure and a method are completely different, unrelated things."

Return to paragraph 4's bankAccount example. Show that a method is simply a procedure that belongs to an object and has direct access to that object's own attributes — the underlying idea of a named, callable block of code is the same.

2. "A class is just another word for one specific object."

Use the two-instances example from paragraph 5. Draw a class on the board as a blueprint, then draw two separate instance boxes underneath with different attribute values, to show a class produces many possible instances, not one.

3. "Bigger problems always need objects; procedures and modules are only for 'simple' programs."

Return to paragraph 7's matching guidance. Have students identify a single, stateless calculation from a scenario and design it as a procedure instead of forcing it into an unnecessary class, to show the choice depends on the problem, not the program's overall size.

4. "Hiding a component's implementation behind an interface means other programmers can never use it correctly."

Connect to paragraph 6's calculator module example. Explain that the interface is exactly what a caller needs — what to send in and what comes back — and that hiding the internal steps is what makes the component easier, not harder, to use correctly.

Discussion Starters You Can Use Tomorrow

  • When would you choose to group several procedures into a module instead of leaving them as separate, standalone procedures?
  • Why might a software architect decide that a piece of a program should be an object instead of a simpler procedure, even though the object requires more upfront design work?
  • Describe a real-world 'blueprint and instance' relationship that is not a computer program — where is the blueprint, and what are the specific instances built from it?

Bringing It Home

This topic is a natural one for families. One ten-minute activity to try: Together, pick something around the house that is built from reusable, interchangeable parts (a furniture set with modular shelves, a recipe with swappable ingredients, a toolkit) and have your student describe it the way a computer scientist would: what's a single reusable action, what's a group of related actions, and what's a 'thing' with its own information and its own actions. There are no wrong answers — the goal is hearing their reasoning about what belongs together.

Where This Leads

Students who can construct a solution to a problem by designing my own procedures, modules, and objects, and explain why I chose each type of component for each part of the problem are building skills used every day in software engineering, game development, backend / API engineering, software architecture, and computer science education.

See the Unit in Action

Get the Complete L2.AP.M.01 Unit

I built a complete, no-prep unit for this standard — Constructing Solutions: Building Programs From Procedures, Modules, and Objects — covering 3-4 days of instruction across 44 pages:

  • Teacher guide — day-by-day pacing, misconceptions to watch for, discussion questions, differentiation for support / ELL / extension, and a 4-point rubric
  • Student learning target page — a kid-friendly "I can" statement with success criteria
  • Full content lesson with 3 embedded "Check Your Understanding" checkpoints
  • 12-question assessment (6 multiple choice, 4 true/false, 2 short answer) with a complete answer key, explanations, and exemplar responses
  • Group activity — "Blueprint It: Designing Procedures, Modules, and Objects" (25-30 minutes)
  • Individual activity — "My Component Design Portfolio" (20-25 minutes)
  • Crossword and word search built from all 14 vocabulary terms (with answer keys)
  • Family connection letter — a plain-language page for parents, with dinner-table questions and a 10-minute home activity
  • Certificate of achievement — ready to sign and send home
  • Component Design Card Set: Procedures, Modules, and Objects (separate printable, 2 pages)
  • Reference Notes: Constructing Solutions With Components (separate printable, 2 pages)
  • My Component Design Portfolio (separate printable, 2 pages)

Get Constructing Solutions: Procedures, Modules & Objects on Teachers Pay Teachers →

Also aligned to CSTA 3A-AP-17: Decompose problems into smaller components through systematic analysis, using constructs such as procedures, modules, and/or objects.

Every Sooner Standards resource is built directly from the official Oklahoma Academic Standards for Computer Science (February 2023) — standard text verified, never paraphrased from memory.

Similar Posts

Leave a Reply