RE: Java Style Question -- JAVA400-L

As another seasoned Java programmer that has been through some ugly issues
in my day, I second the vote for using getter/setter methods. What seems
(and is) innocent access to variables at the time can cause terrible
headaches for you later. Two examples I've found:

1) Later you want to put in tracing support as your functionality gets more
complex and you need to quickly resolve problems for more users. There is
no obvious entry point for the cutting of a trace record... now you are
stepping through your trace and you get to a point where you know the
problem has happened and you don't have knowledge of what the state of the
object was at that point. Its horribly frustrating to look into a 50 Meg
trace and find you don't have the state change of a veriable captured right
before the system tanks. Of course you can handle this by cutting trace
records throughout your application at the right times.... but that's hard
to remember to do, clouds the core logic of a class and requires discipline
very few of us have.

2) Later you start multi-threading something that you never worried about
threading issues for initiallly. You start making various objects safe
from the outside users and that is pretty easy, but you have all kinds of
thread safety holes where two objects clobber each other's internal state
from two threads that are allowed to execute at the same time.

Both are real world problems I dealt with in JDBC. In the end, analysis
shows that these getter/setter methods are totally drowned out,
performance-wise, by the core work of the driver. In your specific
application or scenario, you might have a performance case for direct
variable access, but more likely than not, its a bad move and there are
much better ways of optimizing performance.

Just my .02 on the subject.

Richard D. Dettinger
iSeries Java Data Access Team

Democracy's enemies have always underestimated the courage of the American
people.
It was true at Concord Bridge. It was true at Pearl Harbor. And it was
true today.

Rochester Post-Bulletin
Tuesday September 11, 2001

>----------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <java400-l@midrange.com>
|
| cc:
|
| Subject: RE: Java Style Question
|
|
|
|
|

>----------------------------------------------------------------------------------------------------------------------------|

> From: Larry Loen
>
> The question is a practical one -- are you likely to have MyVar be the
> subject of some form of inheritance? Will the apparent simple assignment
> becomes something else in the child? In that case, getters and
> setters are mandetory.

This is a crucial observation, and one that is not easy to fully grasp.
The
idea is simple: will you at some point need to override how this field is
accessed? It is not always immediately obvious whether this will be the
case.

Let's take a simple example. On a web page, you want to output a colored
string. You specify two things: the string to display and the color. You
call your class ColoredString. The string and color are set when the
object
is created. Your formatter access those two values to create the
appropriate HTML. It seems safe enough to directly access the color value,
doesn't it?

Well, what if some day you want to extend that class so that the color
depends on, oh, I don't know, a flag in the output buffer perhaps? Dare I
call it an INDICATOR? <smile> In any event, the code that formatted the
output and directly accessed the color variable would start to get a little
more kludgy. In fact, it would have to actually set the internal variable
prior to calling the formatter, and that's not necessarily a good idea. At
the very least you have to add a setter method, and once you've done that,
it's pretty easy to add a getter method and the whole problem goes away.

I don't want to get into a long diatribe here about setters and getters as
opposed to internal variables. The purest way is to always use getters and
setters, thereby allowing subclasses the ability to override the behavior
of
the attribute. I have been bitten more than once by class variables being
accessed directly.

_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.