Question

I recently started making simple 2D games, and came across a dilemma - to use or not to use getter and setter methods for the x and y positions of an object. It would look clearer if i wouldn't use methods, but access the variables directly instead, and also, many method calls on the object would hurt performance. Also getting and setting the position pretty much remains simple, so there is really no need for encapsulation here? Or should we always stick to the convention of getter and setter methods at all times?

Was it helpful?

Solution

It's always better to stick to the convention. Plus, the JIT will simplify operations in order to access directly to the field instead of going through all the methods stack.

It's called method inlining.


The Java 2 release of the Java VM automatically inlines simple methods at runtime. In an un-optimized Java VM, every time a new method is called, a new stack frame is created. The creation of a new stack frame requires additional resources as well as some re-mapping of the stack, the end result is that creating new stack frames incurs a small overhead.

Method inlining increases performance by reducing the number of method calls your program makes. The Java VM inlining code inlines methods that return constants or only access internal fields.


Resources :

On the same topic :

OTHER TIPS

You shouldn't have getter and setter nor you should make the attributes public.

Instead you have methods like .updatePosition(), .draw(), .moveTo(), .collideWith(), etc so you won't ever need to get or set values directly from the outside.

There are a few rare cases where you really want to get/set values directly from outside, but these instances are rare and more often than not indicate a bad design (though there are valid uses).

I would use getters/setters. Why ?

  1. Encapsulation is key. Perhaps you'll change how you store locations later on (e.g. Cartesian to polar?). Getters/setters will allow you to perform appropriate conversions.
  2. Setters will allow your object to enforce conditions (e.g. is x > 0 and < 10 ?)

A further reason (though perhaps not appropriate for your needs currently) is that numerous Java frameworks make use of reflection and introspect classes for setters/getters in the conventional setX/getX format. By implementing such methods, your classes are immediately available for reuse in a wide variety of frameworks.

Don't worry about performance until it's a known concern. Premature optimisation will cause you too many headaches.

In Stendhal we do use getters/setters. We have about 60,000 movable object that are processed each turn. From my experience in Stendhal simple methods do not have any measurable performance impact at all. We did quiet a bit of profiling to find various issues, and hugely improved performance in the last couple of month.

The main bottle neck we have is path finding (especially collision detection with other movable objects). There had been issue like creating a new Pair object on every possible collision check, or creating a new Rectangle object whenever a Entity was asked for its position and size.

Those things are very easily spotted in a Profiler (See Profiling server side game loop in java on gamedev).

Other common causes for lag outside the logic part of game loop is client/server communication and database access.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top