Objects within Objects?

I'm working on building a physics engine

Are you working on a collision engine, or a physics engine?

In either case, collision/physics engine objects wouldn't be related to anything specific in the game. Collision objects might be spheres, boxes, triangles, etc. - shapes convenient for collision detection, broad-phase culling and possibly ray-casting - with type specific data such as center point, radius, half-extents, vertices, etc. Physics objects might include a collision shape, but would also have position, velocity, angluar velocity, rotation, moments-of-inertia, etc.

Your game objects (ships, crew, etc.) might have a collision and/or physics object associated with them, but they wouldn't be collision/physics objects themselves. Game object parameters such as damage, rotation, position, etc., would be evaluated as a result of collisions or physics response.

would you usually have a ship class instantiate a private Point object and use it internally to calculate the distance between itself and another ship.

In general, the consensus is to favor composition over inheritance. But if you are trying to learn a new language and brush up on math then don't try and architect the perfect game engine. Just do whatever works, and don't add ANY code you don't need. By only adding what you need you keep the code simple enough to make changes later.

I could tell what I would do, but you don't know why. Do you know why composition is better? Have you tried doing it both ways? There is no "right" way. There are an infinite number of ways. That's why we're all crazy. Those guys you see in dirty clothes muttering to themselves as the walk down the street. Homeless? Nope. Developer.

As a general design/best practice, do you normally create more complex objects by adding simpler ones to them or is it better to have simpler standalone objects do work on a more complex Object's data outside that object?

Not sure what you mean by an object which would "do work.." However, not knowing whether you're talking about a physics engine or collision engine, ... the expected answer: it depends.

If you have a physics object such as a capsule (a cylinder with two half-spheres as caps), physics response would be easier to handle as a single object - position, velocity, rotation, etc. For the purpose of checking collisions for the physics capsule object, it would likely have a capsule collision object associated with it. If you have a collision object of capsule type, implementation would be better as a composition of two spheres and a cylinder - the collision detection is more straight-forward that way. Collision between two capsules would be handled as sphere-to-sphere and sphere-to-cylinder tests.

As mentioned previously, neither a physics object or a collision object would be itself a "game" object.

would you wait until you needed to calculate distance and use the 2 Ship object's public methods to get their current positions and feed it into a separate Point object?

If the distance between 2 object's is needed, calculate the distance from the difference of their positions. It's not clear from a physics, collision or game standpoint why another object would be needed.

FYI, the reason for separating physics/collision objects from game objects is primarily for generalization. E.g., a capsule physics and/or collision object (rather than being of type "ship") could be used for a ship, a bullet, a crew member, etc. They would be distinguished not by type ("ship" or "bullet"), but by their parameters - radius, length, mass, etc. The same collision detection routines would be applicable to a capsule shape with parameters, whatever game object type it's associated with. The response of a game object to those collisions may vary greatly, however. A bullet colliding with a ship would be handled differently than a bullet colliding with a powder keg, for instance. But.. the routines and math for determining whether a collision had taken place between two particular shapes would be the same every time.

Thanks guys, that helps a lot.