Core object scheme and hierarchy

Today I was thinking more closely to the overall object hierarchy of the entire project. As well as the bodies in our solar system “attached” to theirs “parent” bodies (like the moon is a “child” of our Earth, it goes around the Earth, and Earth goes around the Sun), and all the space bodies goes around the Sun, my structure tries to stay closer the same hierarchy.

The scheme of object hierarchy can be seen below. Of course, I believe I will modify it in time due to some new ideas, but the core idea should look that way.



Basically almost every entity on this scheme has a name of “factory”, and it’s pretty self-explanatory. Each this entity handles the generation of the named object in the space, stores it’s parameters and handles some object routines.

For example, PlanetFactory is responsible for generating the planet body with all the stuff, that planet consists of, like surface (that’s been generated by PlanetSurfaceFactory), water (PlanetWaterFactory) or whatever liquid the planet may have, sky (PlanetSkyFactory), and maybe some more later (RiverFactory, CityFactory, etc.). Therefore PlanetFactory is a child to PlanetarySystemFactory – class, that is responsible for processing all the bodies, including the planet itself, that orbits around, let’s say, the center of mass of the planet – Planet itself, planet moons, celestial bodies like Saturn rings, asteroids, debris… If we go higher, there is a SolarSystemFactory, and, as you can guess already, stores and processes all space bodies of the star system, including the star itself, planets, asteroids and asteroid belts, comets and all others.

The scheme looks good and logical for me, and I will definitely try to follow it. Next step will be to define common variables and procedures for each node of the scheme.