APCS vs FRC

Read this page only if you took AP Computer Science A.

In FRC Programming, you'll use several things you've learned from AP Computer Science, such as Object-Oriented Programming. But this page is titled "APCS vs FRC" for a reason- there are fundamental differences that make this page relevant. Here are a couple of points I'd like to mention:

Comments

Like in AP Computer Science, comments are very important. Unlike AP Computer Science A, you'll be working with other programmers. It is recommended that you make comments everywhere you can to help others understand your code, especially at major/confusing parts of the program. And if you're commenting under a method header, make sure to describe what each parameter is for.

APCS teaches you two types of comments— single-line and multiline comments.

// this is a single-line comment

/*  
    this is a
    multiline comment
*/

Generally, both types of comments work fine. However, if you're writing a comment at the header of a class/method, you should use multiline comments. This is because VSC has a special feature that shows a little tooltip every time you hover/select over a method/class with a multiline comment above it. (you also have to add an extra asterisk)

Encapsulation

In FRC programming, we tend not to care too much about Encapsulation. It is a good coding practice, but there isn't any data you'll need to hide in your code. Though it is still recommended that you use getters and setters for altering variables as it helps make the code more readable.

GetInstance()

This will make much more sense if you understand the basic coding structure of FRC Programming. Come back to this page after you've read Subsystems AND Commands.

In APCS, you are taught that when you want to create an object, you use a constructor. This works fine for everything, except for Subsystems.

Creating multiple Instances (objects) of a subsystem isn't a good idea as having multiple instances attempting to control a singular subsystem on the robot can cause serious issues and conflicts. To solve this, we instead use a single static instance of the subsystem in the class itself and a GetInstance() method to access it making all instances of the subsystem across the code the same.

You might be wondering how we'd use subsystems with OOP then. What if we use a single object instead of creating thousands of them? But how would we give this singular instance to the user? All you need to do is a GetInstance() method!

public static Subsystem instance;

public static Subsystem GetInstance(){
    if(instance == null){
        instance = new Subsystem();
    }
    return instance;
}