-2

Is this a legit use of getter

Lady lady = new Lady();
lady.getWater() = "hot water";

if we suppose getter returns

Class Lady {
public String getWater() {
     this.water;
}}

?

closed as unclear what you're asking by gnat, David Arno, Jörg W Mittag, Caleth, TheCatWhisperer May 18 '18 at 12:31

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

3

Short answer: NO

Long answer: You are misusing the Getter. You have Setters & Getters to encapsulate data, i.e. prevent direct access to the member variables. In your Setter, you might e.g. check that you actually set some kind of water (hot/cold/soapy). If you abuse the Getter to Set data you circumvent that. Also, it runs contrary to the expected use of Getters, so anyone else working on your code will be in for unpleasant surprises.

To conclude: This is all kinds of bad (I'm not sure it would even work in Java) don't do it!

  • No, in Java this wouldn't work. Though returning a reference to a variable is something that was done in C++ albeit, usually marked const to prevent it from being changed. However you could also conceivably set a class member in that way. Though I do agree that it does go against the notion of a "getter" being a read and "setter" being a write. – Neil May 18 '18 at 8:18
  • 3
    Setters & Getters provide nearly no encapsulation, because you get no control over when they are called This is how you get encapsulation – Caleth May 18 '18 at 9:19
  • 2
    @Caleth "Setters & Getters provide nearly no encapsulation" is a rather... strong statement. True, if you use Setters and Getters as a longwinded way of writing setFoo(bleh) and bleh = getFoo() instead of bar.foo = bleh and bleh = bar.foo then there is litte gain. But still,at the very least, you can look at who calls setFoo() without needing to look at getFoo() if you want to know writing accesses (or vice versa). BTW: Saying "This is how you get encapsulation" seems to convey a "this is the truth and the only truth and all who do not agree are idiots" feeling. Not a fan. – CharonX May 18 '18 at 9:37
  • 2
    Encapsulation is not "I can put a breakpoint here". It is the removal of knowledge from outside code. And you pretty much can't just look at the consumers of setFoo isolated from the consumers of getFoo, because any of them may be relying on any other of them doing a particular thing – Caleth May 18 '18 at 9:50
  • 1
    @Caleth I wasn't aware that I said "Encapsulation is I can put a breakpoint here". How silly of me. Well, to bad using getFoo() instead of bar.foo doesn't remove knowledge of the user from the underlying code. I really wish getFoo() could do more than return Foo - e.g. calculate foo on the fly, or using a cache, or delegating the call to another function. No, sadly getFoo() HAS to directly { return foo; }, there is NO way to make that function do anything else, and thus there is NO way to remove the knowledge of implementation details from the user. (/sarcasm) – CharonX May 18 '18 at 10:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.