Separating a "Data" object from a "Manipulation" object to reduce packet size

Networking & Multiplayer
#1

I’m not really sure if what I’m asking makes sense. Here’s an example of something I currently have:


public class GameObject  implements Serializable
{
      protected static final long serialVersionUID = 1112122200L;
      private int health, stamina, mana, xPos, yPos;
      private String name;
     
      public GameObject (String name, int xPos, int yPos)
      {
            this.name = name;
            this.xPos = xPos;
            this.yPos = yPos;
            health = 100;
            stamina = 100;
            mana = 100;
      }
      public void setName(String name)
      {
            this.name = name;
      }
      public void setXPos(int xPos)
      {
            this.xPos = xPos;
      }
      public void setYPos(int yPos)
      {
            this.yPos = yPos;
      }
      public void setHealth(int health)
      {
            this.health = health;
      }
      // ETC. Setters and getters for all variables. 

}

When I create a packet, I scoop all this up and send it in a packet. But all those getters and setters REALLY don’t need to be in there. Both the client and server know what an “Entity” is. Can I trim it down so it is just the following:


public class GameObject  implements Serializable
{
      protected static final long serialVersionUID = 1112122200L;
      private int health, stamina, mana, xPos, yPos;
      private String name;
     
      public GameObject (String name, int xPos, int yPos)
      {
            this.name = name;
            this.xPos = xPos;
            this.yPos = yPos;
            health = 100;
            stamina = 100;
            mana = 100;
      }
}

And somehow have a second class with all the getters and setters? If I nest a second class in here, I know nested classes are not serializable… what will happen if I have a nested class, send it, then try to call that nested class?

#2

Methods are not saved per-object in any way. They are a part of the type (class) definition. The serialization of an object isn’t like a .class file with the fields filled in or anything, it’s just the field values and the name of the class to deserialize to.

#3

… Oh. So none of that matters… ok. Well this was a pretty lame topic. Thanks for the answer though.

#4

If you have setter for all variables why to even keep them private?

#5

It is still good practice to do so.
Later if he wants to change how a variable gets set (for example setXPos is going to set the center x position instead of the bottom-left corner) he doesn’t have to go in and rewrite the code everywhere, instead he just changes his setter and all done. For obvious variables like Vector2f’s x and y it makes sense to keep those public since the way you interpret or set them will never change but otherwise the best practice is to use getters/setters.

#6

Inlike public final immutable variables initialized in the constructor.

#7

Future proofing is not virtue. How often that really happen? If setter do have non trivial side effects it’s not that good idea. And when this happen its usually couple search and replace at most or else the code is untangleable spaghetti anyway. Road to hell is paved with best practices.

#8

Road to hell is paved with messy code and bad design decisions. Just because something is considered “best practice” you shouldn’t be mindlessly applying it to everything.
Non-trivial behavior can be documented so I don’t see how doing that is a bad idea. Also there are other serious reasons to consider getters/setters than adding non-trivial side effect. There are many pages on the web discussing why you should use getters/setters, just read the first few results.