Recitation 6: Gravity Lab

Sometime when you’re in the middle of being incredibly bored with this lab, take some time to look at the coolest website about the Solar System I’ve ever seen, and marvel at how freaking huge it really is!

Okay, back to work! :)

Explanation

In this section, we went over the lab web page, which does an exceptionally good job of describing the assignment; that’s all you need. We answered any questions you may have had about it. For the sake of brevity, I am not duplicating the lab page content here.

Class Design

Let’s talk class design. For this lab, we told you the two classes you need: a Body class and a System class. But how and why did we arrive on these two?

Imagine for a moment that all you have to do is do the first half of the assignment, which is animating a system involving the Earth and the Moon. That’s it for now. How would you go about doing it?

Do you even need a class?

Certainly not. It’s just two bodies, right? So what does each body need to remember?

That’s about it. Okay, so without any classes, we have 10 global variables. Oh, we also need to calculate acceleration, which we can do on the fly. Sounds fine, let’s do this assignment.

You can already see where this is going. This is not an extensible or scalable way to program! If I wanted to have three planets, I couldn’t just hard code zillions of constants. So we need a class. This is where the Body class comes in. Those five things are the instance variables of the Body class. So instead of all these constants, we instantiate two objects.

That sounds much better. We think we’re done, right? We have a scalable solution that’s generalizable…

Is it? So when we get to our solar system project, we have many more bodies now. And remember, every body exerts gravitation pull on every other body. Which means we’ll be iterating over a list of bodies many times. Ah-ha! We need a list.

So why we did make this a class by itself? Why not just have a list and update each of the Body objects’ velocities and positions manually with a function and a loop?

This goes back to a different design principle: abstraction. Any situation that has multiple bodies will have to do this style of update where we loop over all the bodies and calculate the new velocities and positions. So the thought process was, well if that’s going to happen every time we use the Body class, why not just put this method and the list that accompanies this into a new class?

And that’s exactly what happened. We created the System class for this exact purpose, so that code wouldn’t have to be repeated. The System class takes responsibility for updating all the positions within its objects. This also allows further scalability because you can put together multiple systems, and have each one take care of itself!

Common Sticking Points

1. Pixels vs Distance

Often times you’ll find that things aren’t showing up in your screen, and you’ll blame your methods. Many, many times, students don’t have their units right. So although you meant 1 billion kilometers, you’ll be inputting 1 billion pixels, which explains why it’s not being drawn on your screen. It’s being drawn wayyyyy off somewhere to the side.

Use the debugger or print statements to print the locations of the center of your planets to make sure they are what they should be.

2. Incorrect Starting Values

Another large issue is improper starting constants. This lab has a lot of constants because you need the mass, distances, etc for all the planets. Make sure you get a trusted source on this and that you are abiding by the units of that source.

When in doubt, check these two things first.