Heh, it's funny you should mention this because I did the exact same thing last year, my senior year on my high school team. Except I was using C++. After reading an awesome C++ book and having an "aha!" moment about polymorphism and object-oriented design, I was disappointed with WPI's failure to fully utilize these features and determined to basically rewrite the library, completely ignoring high-level WPI classes such as Gyro and PID and writing wrappers around the low-level hardware classes. Unfortunately, I never got my library working due to memory management bugs, but it was quite an experience! In one build season I went from a very limited knowledge of embedded C to an expert in object-oriented program design and implementation. In fact, I think C++ gave me a little too much to chew: I stumbled upon the template system and was no later trying to utilize template meta-programming in the robot code. For example, if you tried to instantiate an analog input on a channel that did not exist, you would get an error - at compile time.
This year, I'm a mentor for 619, we've got Java (which is
awesome btw; it is so nice not having to worry about memory management!), and I'm teaching object-oriented programming to my team by having us finish the project that I started last year. It's actually working this time and is really awesome. Oddly enough, it's almost done now and has around 5,000 lines; I guess that's the number of lines necessary to make an FRC robot work.
We have three basic packages: input, controller, and output. Inputs implement one of two interfaces - AnalogIn, which has a get() method returning a double, and DigitalIn, which has an isOn() method returning a boolean. Outputs implement the similar AnalogOut and DigitalOut interfaces with set() methods. We make extensive use of Java's inner classes to break everything down into chunks of this simplicity. My rule is that if your sensor is too complex for these interfaces, you haven't sub-classed it enough.
The controller package contains controllers, which control outputs with inputs using some algorithm in a periodic thread. We also have an asynchronous package for the handling of asynchronous events.
The code isn't quite finished yet, but we plan to release it later this year.
Lord_Jeremy: be sure to keep working on your project to completion. What you're doing is probably the fastest way to develop object-oriented programming skills I can think of. An FRC robot provides a great sandbox where you can experiment with design patterns, make mistakes, and refactor the code every week if it isn't working out. You can't do that in an industrial setting. Take advantage of the opportunity you have now to learn and explore freely. Even if your code never works well enough to be used on the field, you'll gain more from the experience of writing it than you will in any classroom. I speak from experience here. It sounds like your code does work well enough to be used on the field, so that's even more awesome!
