Calling a method will always be slightly slower than getting a field directly, but this will not have a noticiable effect unless they are called hundreds of times per frame. (Ex: You probably shouldn't use getTile(x, y)
in your rendering code, lighting code, whatever applies)
I must say using DataContainer
s for all of your properties seems a bit unconventional, however they are certainly useful for serializing your data.
If you want to use them, instead of complicating your code and adding methods to get and set them, you can use properties. (Take a look at this tutorial)
Properties let you control access to a private member, call a function, or compute logic, while still looking like regular variables.
Here is an example in your case:
public int Health
{
get
{
return (data[0].getValue());
}
set
{
data[0].setValue(value);
}
}
This way you can simply change your fields over to properties, while implementing your logic. Also note, as I said earlier, how methods do cause a very, very slight amount of time to be used. Properties are really methods beneath the hood, so calling get or set will be the same as calling a method. This, combined with searching the data
array for the specified member, will be very fast, but not as fast as a field. So, with that said, you shouldn't notice any lag, but if the game is big enough their may be a slight amount (Although it shouldn't bother you for now, really only applies if you were to add indexing to your tile array or something, just a thought)
If you were to ask me, I would say just keep it simple and go with the standard approach using fields and properties in your program, no need to introduce custom DataContainers, in fact, in my opinion you shouldn't need to.