My current programming concerns: if something is going to affect the data members of a cube object, the cube class needs to be doing the changes. If something is going to be affecting the data members of a tile object (faces of a cube), the tile class needs to be doing the changes, etc… That’s basic encapsulation rules for OOP.
That said, there are changes that can only occur based on information gathered from multiple objects of the same type simultaneously (if we’re moving a cube, all tile objects attached to it need to be moved, obviously), so essentially, as an example, while the data members of tile objects are changed by an internal function in the tile class like TranslateVertices, that function should only ever be called by a cube class function TranslateCube, which should only ever been called by a map class function TranslateCubes (because moving one cube may collide it with another cube, or move it into a restricted area, for instance).
Keeping that in mind, I’m seriously considering using an interface for my cube and tile objects that would be read-only, and only ever using the editable version when in the scope directly above it. I can’t have the GUI scripts accidentally calling any tile or cube object functions directly, except to get data from them, because it would bypass all sorts of checks and balances the classes responsible for the collections of those objects should be making, if that makes sense.
Having to go through the cube class and manually cast most of the tile object references to “editable” sounds like a pain (and doing the same for cube objects in the map class), but it seems like something that needs to be done.
Any thoughts or better ideas?