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;
}}
?
-
3As this shouldn't compile, you can guess that the answer is no. Why would you want to do that in the first place ?– xlecoustillierCommented May 18, 2018 at 6:56
-
1Hint: Software Engineering Stack Exchange doesn't do coding help and expect research before asking– gnatCommented May 18, 2018 at 6:57
-
4The technical term for this distinction is lvalue and rvalue - you should read up on them.– Kilian FothCommented May 18, 2018 at 7:02
-
1Also, generally if your getter is returning a reference you would return a const reference, precisely to stop people breaking encapsulation by doing this sort of thing.– Sean BurtonCommented May 18, 2018 at 12:26
-
2@BojanHrnkas It is still off topic for this site– TheCatWhispererCommented May 18, 2018 at 12:32
|
Show 4 more comments
1 Answer
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.– NeilCommented May 18, 2018 at 8:18
-
3Setters & Getters provide nearly no encapsulation, because you get no control over when they are called This is how you get encapsulation– CalethCommented May 18, 2018 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)andbleh = getFoo()instead ofbar.foo = blehandbleh = bar.foothen there is litte gain. But still,at the very least, you can look at who callssetFoo()without needing to look atgetFoo()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.– CharonXCommented May 18, 2018 at 9:37 -
2Encapsulation 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
setFooisolated from the consumers ofgetFoo, because any of them may be relying on any other of them doing a particular thing– CalethCommented May 18, 2018 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 wishgetFoo()could do more thanreturn Foo- e.g. calculate foo on the fly, or using a cache, or delegating the call to another function. No, sadlygetFoo()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)– CharonXCommented May 18, 2018 at 10:00