0

In am developing a program that shows data from a game being played in its GUI. I have therefore made a Player class with many fields such as, _hp, _maxHp, _mp, _maxMp, _tp, _maxTp, _summonHp, _xCoordinate, _yCoordinate, _zCoordinate, etc.. This class reads from memory the required data in a while(true) loop that updates the GUI if the value has changed.

How would you recommend storing these fields in the player class? Should I put them in some kind of dictionary, or simply have them each as their own private field.

Note: They have different types (some are int, some are float, some are ushort and some are string).

Thanks a lot for any ideas.

Magnus
  • 6,791
  • 8
  • 53
  • 84
  • Public properties sounds reasonable. Just remove the underscore from the beginning, and start it with a capital letter. – gunr2171 Aug 26 '14 at 19:42

1 Answers1

5

You have some inherent structure in your fields that you are not reflecting in your class design. Consider something like

public class Health
{
    public int Hp { get; set; }
    public int MaxHp { get; set; }
}

public class Location // Or use an existing Point3D implementation.
{
    public double X { get; set; }
    public double Y { get; set; }
    public double Z { get; set; }
}

public class Player
{
    public Location Location { get; set; }
    public Health Health { get; set; }
}

You can change the scope of the classes as needed for your overall design (e.g. private or internal).

Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • Thanks, I should have mentioned I actually have a struct already for the coordinates. Follow-on questions: 1) You would actually have a new class for each and every bucket? 2) What's the rational behind that, vs just having Properties in the Player class for each? 3) Would it not be a lot of cs files to have, when you really just hold less than 3 fields in each? 4) If you actually have a class for each, why not make them structs instead? Thanks! – Magnus Aug 26 '14 at 20:33
  • 1) I would have a separate class for each category of thing; 2) You may later wish to abstract the concept of Location or Health. Having one big Player class with everything makes that more challenging (avoid the "God object" http://en.wikipedia.org/wiki/God_object); 3) There is nothing wrong with extra .cs files, but you can put multiple classes in one file if you wish; 4) Structs behave differently. They are value types. This can lead to subtle issues. For that reason, I always prefer a class unless I have a very specific reason to use a struct http://stackoverflow.com/a/3924092/141172 – Eric J. Aug 26 '14 at 21:42
  • Great, thanks. A couple of quick additional questions to your answers: 2) What exactly do you mean by "abstract the concept of..."? 4) Structs have the advantage that since they are value types, new instances of them will be placed on the stack, not the heap. Stack operations are considerably faster, which makes a difference here as the Player class' Location Property returns "new Waypoint" (new instance of the struct) every time someone calls it, and the Location is requested continuously as the player moves (several times per second). Would you agree that struct makes sense then? – Magnus Aug 26 '14 at 22:26
  • Please post a new question to discuss these issues. That way, the question can be more easily found by others and will help more people. You will probably also get a variety of answers. Feel free to add a comment with a link to your new question, so that I can also answer it. – Eric J. Aug 27 '14 at 02:31