Getters and setters under should be used under ALL circumstances

Miscellaneous Topics
#1

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?


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.

#2

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:

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.

#3

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

#4

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.

#5

God no!
Nothing worse than not being able to see if the code executes a method or not. It’s just plain ugly.

#6

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.

#7

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

#8

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

#9

Ok how about this then, OOP purists:


interface Blah {
int x;
}

See what I’m saying?

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

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 :slight_smile:

#10

Nuts. Better redesign most of my classes.

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.

#11

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.

#12

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.

#13

Is there a better way to measure performance?

#14

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.

#15

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

I thought that just takes your stuff like this:


public string PropString
{
 set
  {
        localPS=value; 
  }
  get
  {
     return localPS;
   }
}

And parses it as this:


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.

#16

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 :slight_smile:
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 ;))

#17

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


public int getX() {
return x + 1;
}

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

Cas :slight_smile:

#18

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


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
#19

How about something like:

@Property(get=PUBLIC,set=PROTECTED)
private int count;
#20

much better :slight_smile: