Lesson 6: Using Objects

So we need to learn one more house keeping thing before we move on to some more advanced topics. I don't want to go into a ton of detail in this lesson so it's probably going to be relatively short.

You should know how object orienteded programming works. Objects allow us to keep our code separated and organized. Objects allow us to think about things in code as if they were in the real world. In the context of FRC, we want to have every major function of the robot to be its own object in code. To do this, we use classes. For example, the drive train should be its own object. That manupulator arm you have? The one that goes up and down and has the squeezer motors on the end? All of that should be in its own object, maybe something called ManipulatorArm.

Just so you can get a sense of what level of separation you should have, take a look at all the classes we had in our code last year:

You may notice that there are not many different classes here, and that is due to the fact that we used the Code Red Robot library last year which does a lot of the heavy lifting (including drive objects) for you. We didn't use the library in 2014, so here are some of the classes in our 2014 code base (I have exluded all the library and static files such as KeyMap, etc.):

Here is a picture of that robot so you can see what I'm talking about:

(The shooter mechanism on that robot worked similarly to how a train moves. That's why we called it the Choo Choo.) The ChooChoo class took care of everything that was necessary to make the shoort work. None of the outside classes really knew how the shooter worked, it just knew that there was an object in place that could take care of it. This is something called encapsulation. What that means is that an inner working of an object should be private, and not be able to be modified externally. In short, keep you code separated. Something shouldn't be changing a lot in another object, if so you may need to overhaul your code structure. I know I have probably beat this to death, but I'll leave you with one more example: In our 2014 code, the Pickup object was resposible for the entire physical pickup. Even though the pickup consisted of the arm and the intake wheels, those two things fell under the same object in code.

Try to keep these best practices in mind when you are constructing your code. It may not seem important, but if you encounter any bugs down the road or ever need to completely change how something works, you are going to thank yourself for following these guidelines.

I'll try to refrain from spending too much time on these boring topics in future lessons. It's difficult to teach a reader best code practices, and since optimization, code structure, and readability don't officially matter (although they are important), the best I can do it hope you have learned something in the last two lessons and are willing to follow my suggestions.

With that, let's move on to analog and digital input.

<--- Previous Lesson Next Lesson--->