Which one is faster: method or field access?

[Chris Berg]

Consider this:

class Villain{

public static final String name="Osama";

public static String getName(){
return name;
}

}


Then, which one is faster:

Villain.name

or

Villain.getName()

???


Chris

 

[Michael Borgwardt]

class Villain{

public static final String name="Osama";

public static String getName(){
return name;
}

}


Then, which one is faster:

Villain.name

or

Villain.getName()

Theoretically, the first. But in practice, it will make no difference at all
because the JIT compiler will inline the method call.

The reason why you always use the method and make the member private
is that it allows the class to control access to its member, e.g.
by offering a get method but not a set method, effectively making
the member read-only for outsiders.

 

[DigiAl]

Consider this:

class Villain{

public static final String name="Osama";

public static String getName(){
return name;
}

}


Then, which one is faster:

Villain.name

or

Villain.getName()

???


Chris

Villain.name is, but it goes against encapsulation / OOP - but if you need
speed and you need to access the field many times then maybe its worth it -
also think about redesigning your code

alan.

 

[Linda Obsessed]

On Fri, 27 Aug 2004 11:54:08 +0200, Michael Borgwardt

.. . . .

The reason why you always use the method and make the member private
is that it allows the class to control access to its member, e.g.
by offering a get method but not a set method, effectively making
the member read-only for outsiders.

That statement is often seen, but then why does Sun violate that rule
all the time? Their classes are full of public constants, see for
instance java.awt.GridBagConstraints. The real reason to use getXX and
setXX methods seem to be to be able to use your class as a bean.

Especially if I don't intend to make my classes public, so I don't run
the risk of some dumb user modifying the public fields, I see no
practical argument why I should avoid public fields.

Chris

 

[Michael Borgwardt]

That statement is often seen, but then why does Sun violate that rule
all the time? Their classes are full of public constants, see for
instance java.awt.GridBagConstraints.

What I said does not apply to immutable constants, since they
don't need access control, being constant. Actually, most of them
are just a lazy man's replacement for enumerations, which leads
us to the realization that Sun's programmers aren't neccesarily
the best and brightest: there are a lot of places where the Sun
code is badly designed or just plain crappy in various ways.

The real reason to use getXX and
setXX methods seem to be to be able to use your class as a bean.

So why does the bean specification require get and set methods
instead of public variables?

Because it's more flexible and allows you to do all kinds of things
in the methods beyond getting and setting the value, such as notifying
listeners of the change - something that doesn't only make sense
for JavaBeans.

Especially if I don't intend to make my classes public, so I don't run
the risk of some dumb user modifying the public fields, I see no
practical argument why I should avoid public fields.

The dumb user may well be yourself. Encapsulation is just as much about
protecting you against your own mistakes as it is about others' mistakes.

And it's not just about mistakes, the main point is to keep behaviour
localized. If you ever realize that you need to do something whenever
a certain variable changes, e.g. write a log entry or notify listeners,
then if you used a setter method, you just add a single line of code.
If it is a public field, you have to look all over your code and
add the same line of code everywhere (or change it to a setter method).

 

[Thomas G. Marshall]

Linda Obsessed coughed up:

On Fri, 27 Aug 2004 11:54:08 +0200, Michael Borgwardt

. . . .

That statement is often seen, but then why does Sun violate that rule
all the time? Their classes are full of public constants, see for
instance java.awt.GridBagConstraints. The real reason to use getXX and
setXX methods seem to be to be able to use your class as a bean.

Especially if I don't intend to make my classes public, so I don't run
the risk of some dumb user modifying the public fields, I see no
practical argument why I should avoid public fields.

Are you ever going to access the class from more than one thread? Before
you say "no", think about all the ways in which multithreading is used. If
you are unsure as to why this is risky, then we can engage an entirely
different thread dedicated to that subject.

Is your code ever going to be maintained by someone else? That is another
reason that you might want to have the class to maintain control over how
its instance members are accessed/mutated.

 

[Rhino]

In the late 1940s (!), the Soviets developed a prototype of a translating
machine that would translate English to Russian and back again. At one
point, they decided to test the machine and gave it the English phrase "The
spirit is willing but the flesh is weak." The Russian translation? "The
vodka is good but the meat is rotten".

Source: Alexander Solzhenitsyn, Nobel prize winning author and a member of
the research team.