Object-Oriented Java: Classes, Objects, and Inheritance

Real robot systems are things with both data and behavior: a drivetrain has motors (data) and can drive (behavior). Object-oriented programming bundles related data and the methods that act on it into one unit. WPILib is built this way top to bottom, so this is the lesson that makes the rest of the library make sense.

Classes vs. Objects

A class is a blueprint; an object is a real thing built from it. One class can produce many objects.

class Elevator {
    double heightMeters = 0.0;     // field (data)
    boolean atTop = false;         // field

    void raise(double amount) {    // method (behavior)
        heightMeters += amount;
    }
}

• Fields are the object’s data (its state).
• Methods are what it can do.

You build one with new , then use the dot operator to reach its fields and methods:

Elevator elevator = new Elevator();
elevator.raise(0.2);

A special method called a constructor runs at new and sets up the object’s starting state.

Encapsulation: Keep Internals Private

Good classes hide their data behind a clean set of methods. Marking a field private stops outside code from poking at it directly; public methods control access. That’s why WPILib hands you motor.set(0.5) instead of exposing raw PWM signals — the internals can change without breaking your code.

Inheritance: Building on What Exists

Inheritance lets a new class reuse and extend an existing one with extends. The original is the superclass (parent); the new one is the subclass (child).

class Robot extends TimedRobot {
    @Override
    public void teleopPeriodic() {
        // your code, called automatically every cycle
    }
}

The rules worth remembering:

1. A subclass inherits the superclass’s fields and methods.
2. Java is single inheritance — one direct superclass.
3. Constructors aren’t inherited , but a subclass calls the parent’s with super(...).
4. A subclass can override an inherited method; @Override tells the compiler you meant to.

This is why nearly every FRC project opens with class Robot extends TimedRobot. TimedRobot already handles the hard parts — talking to the Driver Station, running the loop at 50 Hz, switching between autonomous and teleop. You inherit all of it and override robotInit, teleopPeriodic, and friends to fill in your robot.

Interfaces

An interface is a contract: a list of methods a class promises to provide. WPILib’s Subsystem is one. A class implements an interface, and unlike with extends it can implement many. For now, just read implements as “this class agrees to provide these methods.”

Why This Unlocks WPILib

When you see extends, new, a dot-call, or @Override in WPILib code, you now know what’s happening: you’re standing on classes the library authors wrote and customizing them through inheritance. That’s the jump from copying examples to writing your own robot code.

Key takeaways

• A class is a blueprint; an object is a concrete instance created with new.
• Fields hold an object’s data; methods define its behavior; the dot operator accesses both.
• Encapsulation (private fields, public methods) hides internals and is why WPILib exposes clean APIs.
• Inheritance via extends reuses a superclass; Java allows only single inheritance and everything descends from Object.
• FRC robots subclass TimedRobot and @Override its methods, inheriting the 50 Hz loop and driver-station handling for free.

This lesson was adapted from learnfrc.com.