We just made all our supporting classes and placed them into a subsystems file, and kept only Robot.java and Main.java in the outer file.
We were wondering, what is the point of subsystems? Why can’t we just leave all of the classes in one folder?
Also, we read a documentation saying that all the drive commands should be in a subsystem, not Robot.java, is this true? Why?
Didn’t you already ask this here Subsystems vs Just having Classes?
You received a few different answers. If you follow the command based programming pattern/framework, you might find it easier to ask for and get help from other teams that use the same thing. If you don’t might be harder to get help from people when they look at your code. In the end do whatever you wish to get your robot working. There is no right/wrong way. There are many solutions possible. Good luck!
Subsystems help manage your robot’s functionality a great deal when using Iterative/Command-Based robot.
Try and digest all this, it’s a great intro: http://team2363.org/topics/programming/
That is a good command-based introduction put together by TripleHelix (2363).
The subsystems package (java’s fancy word for directory or folder) is purely for organization. Most robots will have many subsystems, and many commands, and so having separate packages for those classes helps to keep things organized.
You are by far not required to use the subsystems folder (or commands folder). You can create your subsystem classes in the same package (folder) as the Main, Robot, and OI classes and as long as your imports are all adjusted to match, you won’t have any issues.
EDIT: Yes, I should add, while you CAN ignore and not use the subsystems package, it is bad practice, and you probably shouldn’t. I initially stayed neutral on the original in order to simply answer the question, but yes, it is bad practice.
You can do this, but you shouldn’t. It’s better practice to organize your classes in a logical manner.
Java packages are not only for organization. FRC Java is different from real Java, so we should be clear on that…there are a lot of things we do in FRC Java that are generally bad ideas in Java applications in general (like making all the variables public static for example).
Packages in Java are multi-purpose, yes they organize code better but it’s not organization for the sake of organization, it’s organization for the sake of preventing collisions with names. That is why for example, if you are using WPI libraries, and have the full jdk installed, you see multiple overloads of the Encoder class name.
Apart from just name space conflicts, you also get some encapsulation benefits from it, such as variables defaulting to package private etc.
You should just stop doing this in FRC too. The RobotBuilder does this but there is no reason you need to personally.
Bad RobotBuilder, bad.
IIRC this is something they plan on correcting in the future but didn’t get around to it this year with all the new Gradle stuff.
I would like to clarify I didn’t say all packages were for only organization. I said the subsystems package. Which is only in the context of FRC, and of the question, which is if the package is required. Unless of course you want to name a subsystem class Main or Robot. Then it is required, and you’re absolutely correct on the matter!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.