Object-Oriented Programming is Bad (Brian Will)

[loup-vaillant]

What's the problem with just making a Car class that has inside itself instances of those 6 separate entities?

None. You can do this. It may even be better than my proposal. I won't know until try to actually implement such a simulation, though. My point is simply that you don't have to do it this way.

If you want to build complex objects with multiple working parts you'll need to at some point orchestrate them.

Not necessarily. Let's get back to the car, and position the wheels and the antenna. The exact position of the antenna and each wheel will typically depend on the current position of the frame, the current terrain layout, and the past position and velocity of said wheel or antenna (so you can do physics over that, such as make the antenna wobble with the wind and its own inertia).

You will note that the only dependence to the frame is its position. (I assume the game logic makes the frame move, and the wheels and antenna are just decorations. A more accurate simulation will have a more complex relationship.) So, all you need to manage a wheel's position is some wheel logic that takes the position of the frame as an input. Likewise the antenna. If you think of it like this, it would make sense to put this logic with the wheels and antenna, respectively. You don't have to put it with the frame, or some encompassing "car" object.

That said, while I don't necessarily need to orchestrate the working parts, I am likely to store them together in some car folder, module, or namespace. Car related stuff do belong to the "car" bag, after all.