Each year for out team, we have people who are interested in programming, teaching them the fundamentals has gone smoothly; they understand data types, methods, loops, etc… But it was always a struggle for beginners to understand Object-Oriented-Programming.
New programmers understand why we use OOP, but they feel OOP is overwhelming, and difficult to understand. So, how do I make the process of learning OOP easier?
Thanks for any help :>
Can they understand classes? I would just try to take it step by step with them and teach one part at a time, and make sure they really understand something before moving on. What kind of things do you use to teach?
I think that the best approach would be to teach them regularly, then give them a project. Its always going to be overwhelming. By giving them a project they learn by making mistakes, this year we let our new ones to work on our 2022 robot and operate the intake, loader and shooter(relatively simple) and left out the turret, hood, swerve and vision. they struggled a lot but eventually they all succeeded.
Don’t reinvent the wheel. Lots of excellent videos, lectures etc. out on the Internet. Do some looking for the highest rated stuff at the level you are looking at and it is all but guaranteed to be a good explanation.
As a non-programmer, who took and got an A in C++ in college, I am baffled by OOP descriptions. I understand there are classes with methods, and you can call on methods from various classes to get done what needs to get done. After the first time through learning about OOP, I don’t think the term “object” was ever used again. Even at robotics meetings, I hear the programmers refer to “calling a method” or “referencing a class” (or something like that), not “creating an object”.
I’m a proponent of using terms and language to teach the larger concepts that you will be using continuously and frequently during the year. If you use the terms in the classic OOP training materials all the time, teach it that way.
Otherwise, ditch it.
Don’t focus too much on OOP. Focus on more-general concepts like encapsulation, (de)composition, and state management. The rest will follow. OOP offers one way to structure code according to these principles, but it is only one way among many.
OOP-centered instruction is a relic; any real programming on a living project is multi-paradigmatic.
Modern WPILib offers ways to avoid object-oriented patterns almost entirely, and it is often appropriate to do so. Inline command declarations are almost always clearer and easier to read than command classes.
If you want to teach OOP, I have found that FRC provides a fantastic paradigm in which to teach it. For one thing, a robot is very literally an object, so the mental model works out pretty nicely. Further, that robot consists of a collection of other objects - things like arms, intakes, etc. And those objects, in turn consists of a collection of other objects - things like motors, sensors, etc. All of those objects have data that describes them, methods that make them do things, and methods that allow you to read information from them. To me, all of that really gets at the heart of object oriented programming.
Inheritance is a little bit less of a clear map onto FRC concepts, but if you want to, you can delve into things like a “SpeedController” interface and concrete implementations for different types of controllers.
@Zook : To your point about the term “object” not being commonly used: It’s a pet peeve of mine, but a lot of programmers use the terms “class” and “object” interchangeably. They are related concepts, but definitely different. A class describes something, where as the object is the thing. In other words, an object is an instance of a class. For example, if you are trying to model a robot arm in OOP, you would make a class that says “an arm has a length, a weight, a motor that you can set the speed for, a cylinder that opens/closes a claw, and two limit switches that you can read their state.” The object itself assigns a particular arm’s length, weight, etc. If your robot has two similar arms, you would use a single class to express the concept of an “arm”, but two objects - one for each arm.
If you don’t mind doing some reading, the “Think Java” series is my favorite introduction to programming.
Importantly, it focuses less on the tools themselves (which is a common pitfall for beginners) and rather on where the tools fit in with the problem & solution space.
Indeed, learning OOP is hard without having first seen what problems it solves. Which, it’s unlikely a beginner programmer will have run into those problems.
Certainly, FRC offers a good context to learn the basics of OOP. Just be careful you don’t try to frame every problem in terms of OOP and only OOP.
Java is a bit of an insidious influence here, since it lacks first class representation for much outside of a very limited OOP model. But even in Java, a little flexibility in paradigm will make your code a lot better.
Thanks to everyone for all the help! I’ll be taking all of your considerations and insight into how we teach beginner programmers in our team.