Do not store the type (class) of an object in an object if you are dealing with a language with strong typing. This is usually a design error. You can easily google the Russian translation of the book "Slippery C ++ Places", which describes in detail why it is impossible to do so - except in very rare cases - in brief: overhead, extra code, manual checks, a lot of errors.
For other languages, I think, similar articles / textbooks are also easy to find.
Understand that the type of object and its value are two completely different concepts.
Polymorphism is invented just so that the programmer does not choose, for example, "and what function to call if the object should move?"
- Stone - does not move
- Bird Flies
- Chicken - (supposedly not a bird), walks. but if frightened, he jumps and flies a little, and almost always flies if he jumps from a height.
- Cat - walks
- Car rides
- Mina with motion detector - explodes
in a language with strong typing and polymorphism support, you simply call the move method and the object itself executes its move method, and if it does not have such a method, you can (can) get an error when compiling. Without unnecessary checks, without unnecessary errors
PS In addition, in C ++ and Java there are ways to find out the type of an object:
- for C ++ - RTTI in runtime or SFINAE at compile time
- for Java,
someObject.getClass()
for Java, I suppose, the call to getClass may incur additional overhead in runtime, if you start storing the type as a separate value, the costs (memory / CPU) will increase even more
for C ++, using RTTI always incurs additional costs (and a handful of problems), and is rarely used
PPS speaking about metaprogramming, then in C ++ using templates / library in the spirit of boost: hana, the concepts of type / value may be slightly blurred, but this is a completely different topic for conversation
PPPS if you need it and / or really need (for example, in the case when your materials are not some classes, but simply texture numbers), then they should be stored in constants accessible to the language (for c ++ it is define / enum / enum class ), and not in string values.
The constants will be processed at compile time, take up less space in memory, and in addition, you will get support for auto-completion of your IDE (since it will see that the constant MATERIAL_TYPE_CONCRETE (aka concrete, let's say) is present in the code), and the lines will hang here and there with all their designers and overheads and without any support from the IDE
PPPPS does not specifically address the issue, but can help you: if you are making a game or something similar that requires many different resources, textures, object models, etc., I would do the following if I were you:
stuff all the resources in the database (mysql / postgres / sqlite - see the situation) let's say as a record (ID, name, type of resource, object hash can be)
make a simple web editor or command script to add a resource to the database.
write a simple script that generates a C ++ header file or a Java class from this database
this will require a day or two of work, but you will begin to feel a profit every time when you don’t have to manually add the file to the code, place it in the right directory, etc.
if, for debugging mode, you also add an entry in the database for the frequency of using the resource, you can, for example, get statistics on a simple request, which resources you do not use, or for which resources there are too few textures, etc.
