Collision detection

It should be external to the entities. That way you can separate collision detection from your game objects, which will make life easier if you want to experiment with different implementations, etc. Also, parallelization will be much easier (you could have a collision detection thread, or n threads operating on n groups of objects from the list). By grouping the collision data and looping over it in a single bit of code you'll also get much better cache performance. Have a look into "data oriented design" for some ideas there.

Basically I'm of the opinion that it always pays in the long run to be as modular as possible, especially with potentially heavyweight subsystems.

It should be external to the entities. That way you can separate collision detection from your game objects, which will make life easier if you want to experiment with different implementations, etc. Also, parallelization will be much easier (you could have a collision detection thread, or n threads operating on n groups of objects from the list). By grouping the collision data and looping over it in a single bit of code you'll also get much better cache performance. Have a look into "data oriented design" for some ideas there.

Basically I'm of the opinion that it always pays in the long run to be as modular as possible, especially with potentially heavyweight subsystems.

This is correct, the collision detection should be within the engine itself rather than with the object directly.

What should the entity objects possess to determine if they hit something? Should each object contain a method/function that receives a "true" to the question "did I hit something" that the engine passes to the object?

They shouldn't. As said above, being as modular as possible pays a lot. Therefore, the entities shouldn't have a function which asks the engine if they have hit another entity. You should call a function from the engine itself which takes two game entities and determine if they collided. Like that, you separate work that the entity shouldn't be aware of.

An even better implementation would be to no pass directly entities to the engine's function, but objects representing collision shapes. You'll be able to reuse your engine's functionality on other projects like that, because it won't be dependent of your entities.

Ok. If the engine does determine that two objects collide then how is the referring object supposed to know if it is destroyed or not providing it is a bullet hitting a spaceship?

This is game dependent implementation. What I mean is the function's job should be to only check if a collision occurred between two collision shapes. The game should then determine which types are the entities that are colliding. If your entities hold a handle of the collision shape, or you have whatever means to know which shapes is held by which entities, then you can determine of which type is the entities that are colliding together and react accordingly by, for example, sending a message to the entity representing the spaceship to tell it it was destroyed by a bullet.

Something like this, where the collision is check by the engine, but the entities themselves handle the collision differently:

// Assume Hero is our player that collides with things, and Entities are objects the hero can collide with

// Loop through list of Entities that can be collided with
for(int i = 0; i < EntiityList.size(); i++)
{
Entity = EntityList.get(i);
if (Collides(Hero, Entity))
{
// notify hero he collided with Entity, and notify the entity it collided with hero
Hero->NotifyCollision(Entity);
Entity->NotifyCollision(Hero);
}
}


Just a simple example of one way to do this.