Well, from what I've read so far, it seems like you're doing a pretty good job of organizing the code. The only thing I'd really change, aside from documenting your methods with SI units, is to move all of the physicsy stuff to a physics class.
Some things are so intuitively obvious that you'd never consider extracting to a new function, such as speed = distance/time. Anything that involves more than, say, two operations, or that is otherwise not obvious to someone that isn't "skilled in the art" by its written implementation should get refactored. Try to make these functions as reusable as possible, except when you can see that there would be a performance benefit to overloading. You might have two methods to calculate collsions, where one takes objects, one that takes vectors, and one that takes floats. Ultimately, you should try to make the object method call the vector method, and the vector method call the flat method.
At my college, one of the majors offered is IMGD - interactive media and game design. It's just CS with a concentration in IM/GD. I didn't choose to go this course, but I've taken quite a few physics courses in my day, and I've found myself reviewing game code designed by people who haven't, and this is what I generally find:
People put too much emphasis on what seems right, and not enough on what the reality is. For example, to calculate how a collision occurs, you should use the physics equations, not what makes sense in your head. This may make your physics class a little bulkier, but in the long run will eliminate most hacky code. Furthermore, if you can inline these functions, that overhead will be obliterated by the compiler.
There are few things you should know about collisions (in descending order of importance as I see them):
* Collisions are about momentum, not speed. Convert your speed vectors to momentum vectors (or flat variables) before calculating anything. Total momentum in (per axix) = total momenum out. Write test cases to prove this! You're using floating-point logic, so verify to within 1/10000 of the expected value, or some other constantly defined threshold.
* Conservation of mass. This is obvious, but it is an assumption that needs to be stated. You shouldn't need to document or write code to prove this, since there's no reason mass wouldn't be conserved.
* Both objects in the collision have their own elasticity. If these values are equal, the equation is simpler than if they are not. Do not use the simplified equation.
* The floor always has a low elasticity. Try 0.1 for starters, and lower until you find a value you like. Other objects almost always have an elasticity of 0.25 or higher. Never choose an elasticity higher than 0.95, since that's unrealistic. Especially never try to set elasticity higher than 1.0, since it will make collisions with immovable objects looks stupid.
* Everything has elasticity, but sometimes there are cases when you ignore this. For example, look at any first-person game where you can fall. What happens if you fall very far? If you die, you should hit the ground and bounce a little. If you land on your feet AND survive, you shouldn't bounce, since your legs successfully absorbed the energy.
* Mass is linear inertia. Inertia is resistance to movement. To make an immovable object (floor, walls), use mass=+INF. Your equations should work properly.
You might also make provisions to, in the future, have collision meshes. A collision mesh looks exactly like an object's physical model, except that it has as few points as you can possibly use without making the object behave unrealistically. It's important to keep collision meshes simple because collision detection is an expensive process; the simpler the mesh, the faster it will happen. You may want to have special sub-classes for spheres, since a polygon collision mesh will prevent a ball from rolling along the ground.
