Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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  
  Getters and setters under should be used under ALL circumstances  (Read 5179 times)
0 Members and 1 Guest are viewing this topic.
Offline K.I.L.E.R

Senior Member




Java games rock!


« Posted 2005-06-25 09:28:43 »

I can understand why they are used, and I know that they DO help code maintainability but at the same time there are places where they are USELESS.

What's the point of using getters/setters in this class? There is none, so why do it? You aren't trying to encapsulate anything, you want both variables to be fully accessed. Adding get/set will only introduce overhead.

Why are people so inclined to use get/set in these situations?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class Vector2f
{
   public float x, y;
   

   public Vector2f(float x, float y)
   {
      this.x = x;
      this.y = y;
   }
   
   public Vector2f() {}
   
}


I've just read articles about why people should use getters and setters. The examples are so poor, it makes me wonder if there is any common sense left in this world.

Have the teachings of OOP gone so far as to brainwash the masses?

I think it's about time for Sun to add properties (like in .NET, Python, etc...) to Java.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2005-06-25 10:06:40 »

the reason for using getters and setters all the time (which isn't *always* needed), is that at some point in time, management wants to offset x with 1, so that:
1  
2  
3  
public float getX() {
return x + 1;
}

if you had not used getters and setters, you would have to refactor a lot of code because of this.
Now this example is pretty lame, but its the general idea that is important.

That said, many classes, especially vector like stuff almost never use getters and setters.
And J2ME mostly never does either due to size limitations.

Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2005-06-25 10:31:22 »

What a strange post!

You've just stated the issue and the resolution. You're absolutely right, getters and setters are generally a good idea - but like most rules there are exceptions where they just don't make sense.

Well Done!

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #3 - Posted 2005-06-25 11:10:22 »

Well it is new for me as I've never previously came across anything in my work that didn't need getters and setters.
What I would like is for Sun to implement properties in order to use getters and setters without the overhead.

Recently I've been profiling and I've found that Java running in client mode doesn't inline well.
With this in mind, I've found out that the majority of the CPU time spent in code was on getters and setters.
This obviously means that this is my performance limitation.
So I'm going back and eliminating as many getters and setters as possible to reclaim a lot of lost performance.
This means that I'm going to dump a fair bit of functionality as well.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #4 - Posted 2005-06-25 11:15:58 »

Well it is new for me as I've never previously came across anything in my work that didn't need getters and setters.
What I would like is for Sun to implement properties in order to use getters and setters without the overhead.
God no!
Nothing worse than not being able to see if the code executes a method or not. It's just plain ugly.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2005-06-25 14:21:49 »

With this in mind, I've found out that the majority of the CPU time spent in code was on getters and setters.
This obviously means that this is my performance limitation.
So I'm going back and eliminating as many getters and setters as possible to reclaim a lot of lost performance.
This means that I'm going to dump a fair bit of functionality as well.

Never seen that before, hard to believe - I would assume your code has something *else* wrong with it, and not take that drastic action if I were you.


malloc will be first against the wall when the revolution comes...
Offline Mark Thornton

Senior Member





« Reply #6 - Posted 2005-06-25 15:36:06 »

Recently I've been profiling and I've found that Java running in client mode doesn't inline well.
With this in mind, I've found out that the majority of the CPU time spent in code was on getters and setters.
I suspect that there is something wrong with your measurement technique.
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #7 - Posted 2005-06-25 21:57:06 »

Getters & Setters allow you to change the underlying implementation without breaking code that uses your class.  I use them all the time except for simple classes like vectors, where the convenience of accessing the property directly outweighs the benefits of encapsulation.

Hotspot does a good job of inlining method calls except where the method overloads one in a superclass.  At this point it seems to give up, even if you declare the method final.  This only really matters in the tightest of loops.  I removed one method call in my software texture rendering code during optimisation, but all the rest of my getters & setters are present with little impact on overall speed.

Alan

Time flies like a bird. Fruit flies like a banana.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2005-06-25 23:23:24 »

Ok how about this then, OOP purists:

1  
2  
3  
interface Blah {
int x;
}


See what I'm saying?

Why use two bloody method declarations when a dot would do? Sheesh.

<edit> Before any smartass would like to point out you can't do this in Java - that's my point. Why not? It's not OOP that mandates get and set: it's Java.

Cas Smiley

Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #9 - Posted 2005-06-26 03:18:53 »

Quote
[...]method overloads one in a superclass.

Nuts. Better redesign most of my classes.

Quote
I suspect that there is something wrong with your measurement technique.

I'm using Netbeans profiler M7 with JDK 1.5_04.
I just look at my get/set methods within the profile during run time and that's where I see it mentions 2.2 seconds spent on them in total.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mark Thornton

Senior Member





« Reply #10 - Posted 2005-06-26 08:38:11 »

I'm using Netbeans profiler M7 with JDK 1.5_04.
I just look at my get/set methods within the profile during run time and that's where I see it mentions 2.2 seconds spent on them in total.
The profiler will prevent them being inlined. You should exclude trivial methods from profiling because you only end up measuring the performance of the profiler.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #11 - Posted 2005-06-26 08:49:25 »

Just wanted to point out the built-in profiler (-Xprof) does inlining.

You'll see often used methods disappear, and more will vanish when using the server VM.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #12 - Posted 2005-06-26 11:51:40 »

Is there a better way to measure performance?

I'm using Netbeans profiler M7 with JDK 1.5_04.
I just look at my get/set methods within the profile during run time and that's where I see it mentions 2.2 seconds spent on them in total.
The profiler will prevent them being inlined. You should exclude trivial methods from profiling because you only end up measuring the performance of the profiler.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline Mark Thornton

Senior Member





« Reply #13 - Posted 2005-06-26 19:05:42 »

Construct two versions of the essentially same code, just differing in the use or not of getters/setters. Take care that the computation is non trivial and won't get optimised away. Then time both versions, with enough runs to ensure that the JIT has actually compiled the code.
Offline Breakfast

Senior Member




for great justice!


« Reply #14 - Posted 2005-06-26 20:35:40 »

Quote
What I would like is for Sun to implement properties in order to use getters and setters without the overhead.
Do you mean in the way that c# handles them?

I thought that just takes your stuff like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
public string PropString
{
 set
  {
        localPS=value;
  }
  get
  {
     return localPS;
   }
}

And parses it as this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
public string GetPropString()
{
   return localPS;
}

public void SetPropString(string value)
{
     localPS=value;
}

Very nice to work with, but pure syntactic sugar as far as I can tell- I don't see that elminating overhead at all really.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #15 - Posted 2005-06-27 10:21:46 »

Ok how about this then, OOP purists:

1  
2  
3  
interface Blah {
int x;
}


See what I'm saying?

Why use two bloody method declarations when a dot would do? Sheesh.

<edit> Before any smartass would like to point out you can't do this in Java - that's my point. Why not? It's not OOP that mandates get and set: it's Java.

Cas Smiley

I can see your point, but if this would be an RFE for the java language, I would oppose. I'm not sure how to make myself clear why, but let's try :-)
It seems to that having a variable declaration in an interface makes things less clean, and it seems to go against java's implementation of OO as it encourages fields to be visible.
And it looks like a field declaration, but it's really not, while it actually is when you declare a static final in an interface. Furthermore, declaring variables like this in an interface would still be too limited as you can only declare fields which are alterable by anyone (like a public), which is something you more often don't want anyway (my code has more getters than setters usually).
So I would say that if you want property declarations like that, you would need some kind of new syntax for that to be able to make them read-only. Or just stick with getters/setters, which is not so bad anyway as far as I'm concerned (eclipse does the typing for me to create getters and setters anyways  Wink)

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2005-06-27 10:46:37 »

I use getters and setters now but my point is that it's just more shit to type and maintain and it lets smartasses do stuff like
1  
2  
3  
public int getX() {
return x + 1;
}

which as you can imagine is just a recipe for hilarious bugs.

Cas Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #17 - Posted 2005-06-27 11:50:38 »

Yes, I do see your point, I was just referring to your suggestion with the interface.
But it could be nice if you could mark a field to be read-only.
Something like
1  
2  
public[r] int x; // when written to from another object, it will fail at compile time
public[r,w] int x; // the same as a 'normal' public field as we have it now


Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #18 - Posted 2005-06-30 09:32:03 »

Yes, I do see your point, I was just referring to your suggestion with the interface.
But it could be nice if you could mark a field to be read-only.

How about something like:

1  
2  
@Property(get=PUBLIC,set=PROTECTED)
private int count;


Hellomynameis Charlie Dobbie.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #19 - Posted 2005-06-30 11:11:38 »

much better  Smiley

Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #20 - Posted 2005-07-03 19:07:50 »

If small methods do not get properly inlined, then they CAN make trouble. In the case of a fractal drawing program, I wrote a class for manipulating complex numbers with methods for basic algebraic operations. The simple complex operation "z^2 + c" would involve two method calls. After hundreds of iterations, this is quite a lot of method calls, and it turned out that manually inlining these bits increased efficiency several times. The method bodies themselves were just two or three lines with a couple of multiplications and assignments.

I can't imagine the horrors of further using getters and setters in that situation (which was, by the way, completely unnecessary since it all went on inside the class itself).
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #21 - Posted 2005-07-03 20:42:35 »

Quote
...it turned out that manually inlining these bits increased efficiency several times.
On the client VM I can imagine things to be not optimal, but was this also the case on the server VM?

Offline uj

Junior Member





« Reply #22 - Posted 2005-07-17 17:37:56 »

Have the teachings of OOP gone so far as to brainwash the masses?

From an OO perspective you preferably shouldn't expose the internal state of objects at all, neither in the form of naked variables nor variables wrapped in getters/setters, because it breaks encapsulation. You should ask the object to do stuff instead of shuffling data in and out of it. You should push information onto it rather than pulling it out.

Getters/setters have very little to do with OO. Sure, they offer a slight data abstraction but that's seldom utilized anyway. How often do you really change the internal representation of a variable leaving the getter/setter methods intact? If a class have variables you really want to expose and you feel there's a performance issue you can as well skip the getters/setters.
Offline Jeff

JGO Coder




Got any cats?


« Reply #23 - Posted 2005-07-18 00:39:03 »

Two Comments:

(1) Getters and Setters add NO overhead  in a modern VM. They get inlined away.

(2) The reason to use them is for future proofing.  In the future you might want to a sub-class that has the same access but does more invovled calculation for those values/.

Getters and Setters abstract the conceptual interface, the "contract" from the implementation and thus are always a good idea.

Having said that, Im lazy and dont create them many times where I am really sure I wont ever override.  Soemtimes thats bitten me and Ive had to go back and fix the wrong assumption later,  I've actually seen languages thjat create "implied setters and getters",  much like Java has an impleid default constructor.  Thats probably the best of all worlds...

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline uj

Junior Member





« Reply #24 - Posted 2005-07-18 04:40:14 »

Getters and Setters abstract the conceptual interface, the "contract" from the implementation and thus are always a good idea.
There's a problem with this statement. It says that data abstraction is good and getters/setters will give you data abstraction so therefore go ahead and make every variable publicly available. This is not a good idea. To mechanically promote variables to the "conceptual interface" is not data abstraction. It's a flagrant break of the principle of encapsulation and bad.

This "getter/setter on every variable in sight" mentality is confused with good OO. Instead use as few getters/setters as possible, preferably none. If you really want to expose variables there's little or no benefit in using getters/setters because then you most likely have what in C++ is called a concrete class. It's a class you design to be used as a primitive.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2005-07-18 08:46:01 »

Uj speaks the truth.

Cas Smiley

Offline Jeff

JGO Coder




Got any cats?


« Reply #26 - Posted 2005-07-19 03:38:58 »

Getters and Setters abstract the conceptual interface, the "contract" from the implementation and thus are always a good idea.
There's a problem with this statement. It says that data abstraction is good and getters/setters will give you data abstraction so therefore go ahead and make every variable publicly available.

No, I did NOT say that.  Please do not mis-characterize my statements.

We were explicitly talking about values you wish to expose. In that context I said that setters and getters are always a good idea.

There are lots of things that shoudl be "private", thats why its in the language.

Edit: Note that, udner certain very specific conditions, it MAY be also useful to use getters and setters that are not exposed beyond your own children.
This allows a child to modify the way the value is obtained for the entire class.  Its certainyl nto worth always doing but under the right circumstances it can add flexabiltiy to your classes.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline tortoise

Junior Member




<3 Shmups


« Reply #27 - Posted 2005-07-22 20:36:10 »

Quote
I think it's about time for Sun to add properties (like in .NET, Python, etc...) to Java.

As someone else has mentioned, properties in .NET get converted into standard get and set method calls by the compiler. Take the following C#:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public class Foo {
   private int a;
   
   public int A {
      get {
         return a;
      }
      set {
         a = value;
      }
   }
}


WHen you compile this class then look at the generated MSIL, you will find

int get_A()

and

void set_A(int value)



I dislike properties, because there is no way from the syntax to know if a property is read only or write only. With getters and setters it's plainly obvious.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

Dwinin (22 views)
2014-09-12 09:08:26

Norakomi (55 views)
2014-09-10 13:57:51

TehJavaDev (66 views)
2014-09-10 06:39:09

Tekkerue (33 views)
2014-09-09 02:24:56

mitcheeb (55 views)
2014-09-08 06:06:29

BurntPizza (38 views)
2014-09-07 01:13:42

Longarmx (24 views)
2014-09-07 01:12:14

Longarmx (30 views)
2014-09-07 01:11:22

Longarmx (29 views)
2014-09-07 01:10:19

mitcheeb (37 views)
2014-09-04 23:08:59
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!