Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Separating a "Data" object from a "Manipulation" object to reduce packet size  (Read 5770 times)
0 Members and 1 Guest are viewing this topic.
Offline Chumble

Senior Newbie


Exp: 1 year



« Posted 2014-08-05 20:05:47 »

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

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
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?
Offline BurntPizza
« Reply #1 - Posted 2014-08-05 20:15:01 »

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.
Offline Chumble

Senior Newbie


Exp: 1 year



« Reply #2 - Posted 2014-08-05 20:19:43 »

... Oh. So none of that matters... ok. Well this was a pretty lame topic. Thanks for the answer though.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pitbuller
« Reply #3 - Posted 2014-08-05 23:19:43 »

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

JGO Coder


Medals: 32
Exp: 3 years


White-bearded OGL wizard


« Reply #4 - Posted 2014-08-06 10:30:52 »

If you have setter for all variables why to even keep them private?
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.

My Blog | Jumpbutton Studio - INOP Programmer
Can't stress enough: Don't start game development until you haven't got the basics of programming down! Pointing
Online ags1

JGO Ninja


Medals: 66
Projects: 3
Exp: 5 years


Make code not war!


« Reply #5 - Posted 2014-08-06 22:21:11 »

Inlike public final immutable variables initialized in the constructor.

Offline pitbuller
« Reply #6 - Posted 2014-08-08 23:35:41 »

If you have setter for all variables why to even keep them private?
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.

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.
Offline PandaMoniumHUN

JGO Coder


Medals: 32
Exp: 3 years


White-bearded OGL wizard


« Reply #7 - Posted 2014-08-11 19:26:58 »

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.
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.

My Blog | Jumpbutton Studio - INOP Programmer
Can't stress enough: Don't start game development until you haven't got the basics of programming down! Pointing
Pages: [1]
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (38 views)
2014-10-17 03:59:02

Norakomi (28 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (55 views)
2014-10-14 00:39:48

TehJavaDev (55 views)
2014-10-14 00:35:47

TehJavaDev (44 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!