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
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:
Uri(the main robot class)
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.):
Tiberius(main robot class)
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.