Re: classes question

Wojtek Bok wrote:
Thomas Weidenfeller wrote:
Typically, the method changes the state as a side effect of doing
something, but it has (unfortunately) also become very popular to
provide methods which just change an object's state, but doing nothing else.

This statement with:

In Java, methods just changing an object's internal variable/state are
called setters. Methods just reporting an object's state/variable are
called getters.

confuses me.

Getters and setters are there to change the state. Sometimes they also do some ancillary processing, but mostly they change the values of private variables.

So in the first statement you label this as a bad thing,

Yes, I do.

while in the second statement you endorse it.

No, I don't. I just report the reality.

It is a design issue. If you just treat objects as containers for values you end up with many setters/getters (which are still better than public access to the internal variables). But you effectively just use them as "link structures", the "behavior" part of objects gets largely neglected. If you treat your objects as "things which do something", you end up with less setters/getters and a set of methods (the "do something" methods) which more closely resemble some real-world object.

Typically, the later results in more powerful methods, while the first results in more, but dumber methods.

If you have the choice between public variables and setters/getters, use setters/getters. If you have the choice between setters/getters and methods which do more, use the later.

/Thomas
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
.