Abstraction and Program Design

⚠ Optional chapter. This chapter sits conceptually between Java I and Java II — it's the general, from-scratch program-design thinking that applies to any object-oriented code, not just FRC robot code. It's informational, not a required gateway, since real FRC teams build on top of WPILib's already-imposed architecture (command-based, Ch.25) regardless.

Designing Before Writing: Object-Oriented Design

Before writing a single class, it helps to first decide which classes a program actually needs, and what data/behavior each one owns. A reliable trick: read the problem description and look for the nouns — they're usually your classes. Given "the robot has a drivetrain, an intake that picks up game pieces, and a shooter that scores them," the nouns drivetrain, intake, and shooter are exactly the Subsystem subclasses (Ch.17/20) a real codebase would end up with.

UML Class Diagrams

A UML class diagram is a simple box-based sketch of a class — its attributes (instance variables) and methods, with - marking private members and + marking public ones. These diagrams don't need to be formal; a whiteboard sketch before writing code is often enough to catch a design problem before it's baked into actual Java.

Data Abstraction: Naming Data Without Its Details

Data abstraction separates a data type's abstract properties from the concrete details of how it's represented — you can use an Intake object without knowing exactly how its internal state is stored. Ch.7 already introduced the specific vocabulary this curriculum uses for this: instance variables (unique per object — each Intake's own hasGamePiece flag) and class/static variables (shared across every instance — a running count of how many Intake objects exist).

Procedural Abstraction: Naming a Process Without Its Details

Procedural abstraction gives a process a name, letting it be used by knowing what it does without needing to know how — calling intake.retract() doesn't require knowing exactly how the retraction is implemented underneath. This is exactly the value of a well-named method (Ch.4/7): three real benefits fall out of it:

Organization — breaking a large behavior into smaller, named methods keeps any one piece of code manageable.
Reuse — a method written once can be called from many places, instead of duplicating the same logic (Ch.26's DRY, in disguise).
Maintainability — smaller, well-named methods are far easier to read, debug, and reason about than one sprawling method doing everything.

Procedural abstraction also means a method's internal implementation can change freely — made faster, refactored, rewritten — without breaking any code that calls it, as long as the method's signature and its observable behavior stay the same. Adding parameters extends this even further, letting one method generalize across a whole range of inputs instead of needing a separate near-duplicate method for each specific case.

Applying This to an FRC Robot

Before writing Robot.java, sketching out "what are the nouns" for an actual robot — Drivetrain, Intake, Shooter, Climber — and roughly what data/behavior each needs, is exactly the kind of upfront design this lesson describes. It's the same thinking that led to the Subsystem abstraction in Ch.17 and Ch.20 in the first place — those weren't arbitrary class boundaries, they came from identifying the real, distinct "nouns" in a robot's actual hardware.

Common Pitfalls

Skipping design entirely and writing code directly. Even a rough five-minute sketch of "what classes do I need, what does each own" catches structural mistakes far more cheaply than discovering them after a class already has fifteen unrelated responsibilities.
Confusing data abstraction with encapsulation. They're related but distinct: data abstraction is about naming data without exposing its representation; encapsulation (Ch.7/23) is the specific mechanism (private fields, public accessors) that enforces it.
Assuming procedural abstraction only matters for long methods. Even a short method benefits — naming a two-line calculation calculateShooterRPM(distance) documents intent in a way the raw calculation alone never does.

Key Takeaways

Object-oriented design starts by identifying the nouns in a problem description — they're usually the classes a program needs.
A UML class diagram is a simple, informal way to sketch a class's attributes and methods before writing real code.
Data abstraction separates what data represents from how it's stored; procedural abstraction separates what a method does from how it's implemented.
Procedural abstraction's real payoff: organization, code reuse, and the freedom to change a method's internals without breaking its callers.

Derived from csawesome-2026: unit-3-class-creation/3.01-abstraction-and-program-design.md (CSA 3.1)