koobas.hobune.stream
Can I preserve the values in a parent class when I overwrite it with a child class?
Hello, my current problem is that I've got a class FieldInfo which has a child class called Building.
Now I generate FieldInfos for every field of my map during map generation. I store those FieldInfos in a 3d array FieldInfos[,,]. When I want to build a building I can stick the child class into the parent array. fieldInfos[x,y,z] = new Building(Construction.House);My problem here is that this would overwrite the values in fieldInfos (which are kind of important since they contain gameplay relevant map data) with the standard constructor of FieldInfos if I understand it correctly.
Is there some way to maintain the properties of the old FieldInfo object when I overwrite it with a Building object? Or would it make more sense to just make another array for the Building class and don't have it inherit from the FieldInfo class?
All you really need to do is pass the values to be preserved in the original FieldInfos[] to the constructor of the Building so it copies those values into its base. There's no way to 'preserve' the original FieldInfos, the Building is a separate instantiation, it can't slice the derived part onto an existing instantiation of the base.
That said, the question that comes to my mind is a mystery from my viewpoint, since I don't get any information about your design - but is a Building a FieldInfo? More to the point, not just from the standpoint of data, but from the standpoint of member functions, does a Building need any of the member functions of the FieldInfo base in order to function correctly as a Building?
If the answer reveals that a Building is otherwise so separate from the methods and data of FieldInfo that you're merely tacking the Building onto a FieldInfo because that base has pertinent bits of data but is otherwise not a functional base component, then perhaps the relationship isn't inheritance, but one of ownership. Perhaps a Building should be something that attaches to an existing FieldInfo, and can use the FieldInfo through an interface that communicates between them.
From this distance I have no information that informs me which is the truth in your case, but such is the nature of object design where the basic question is to differentiate between things that "are a" (or "is a") and those things that "have a" class. If shape is a base, then obviously circles, squares and triangles ARE shapes. That satisfies the "is-a" relationship, and indicates the circle, square and triangle may well derive from the shape base. However, consider the relationships established in Unity itself (they are well chosen) where components are added to a GameObject because they are "owned" not "comprised of" the attached classes. Derivation is an intimate relationship, whereas ownership is causal and requires a protocol for interaction (and that limitation is functional, lending a design a more solid foundation).
Thank you very much for the explanation. You're right, a Building doesn't require all the Information of a FieldInfo only a bunch of them. (And sometimes most of them).
$$anonymous$$aybe just attaching the building class to the FieldInfo would be more efficient. $$anonymous$$ight be sensible to just copy the bits of data that are required for my Buildings into the classes before I attach them. Would it make sense to use Interfaces here? (Never used those before)
I don't think interfaces are indicted here.
When I used the word 'interfaces', I was speaking more generically about the way classes interact with each other. I'm primarily a C++ programmer, though like many in the field I know and use several languages, and the word 'interface' is uniquely a keyword in C# in this case, it is more a generic term for a C++ programmer (and others), and to a gray beard like me, C# is a new language ;)
Attaching the relevant data into Building may result in faster operation when using that data in Building as opposed to giving Building reference to the 'owner' FieldInfo, but either will do and is a matter of tuning you'll be in a better position to recognize (with the code in front of you).
