Re: classes question

Thomas Weidenfeller wrote:
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

I like when concepts appear on an apparently extrapolatable path like that; makes me wonder what the, "Next," level methods would be like, if they are to the do-more methods what the do-more methods are to the getters/setters.

Similarly with OO itself: the power of OO stems from its separation of interface from implementation; but what if there's more, if there's some thing beyond-an-interface that is to interface what interface is to implementation?

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html
.

Relevant Pages

  • Re: Holub on getters/setters again
    ... > help us because setters/getters are quite reasonable in some ... > wouldn't tell you if the interface should be adjusted. ... One of them is "how does this accessor ... between the class and its clients. ...
    (comp.object)
  • Re: Holub on getters/setters again
    ... help us because setters/getters are quite reasonable in some situations. ... wouldn't tell you if the interface should be adjusted. ... I'm saying that the "other quality" is one that applies to *all* ... what methods are getters/setters because "bad" getters/setters will ...
    (comp.object)
  • Re: classes question
    ... Getters and setters are there to change the state. ... So in the first statement you label this as a bad thing, ... 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). ...
    (comp.lang.java.help)