Set result of getter instead of setter

Question

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;
}}

?

As this shouldn't compile, you can guess that the answer is no. Why would you want to do that in the first place ? — xlecoustillier, May 18 '18 at 06:56
[Hint: Software Engineering Stack Exchange doesn't do coding help and expect research before asking](https://softwareengineering.meta.stackexchange.com/a/7826/31260) — gnat, May 18 '18 at 06:57
The technical term for this distinction is *lvalue* and *rvalue* - you should read up on them. — Kilian Foth, May 18 '18 at 07:02
I believe in some languages, like C#, the getter can return the reference to the member. In this case it is a valid code, but still a bad Idea. — Bojan Hrnkas, May 18 '18 at 07:09
@BojanHrnkas, C# does indeed support ref returns in getters. The purpose of them though is to return structs (stack based "objects") by reference rather than by copying the value. This is designed for performance gains though. You are completely right that it should not be used as a "sneaky" way of changing a value via a getter. — David Arno, May 18 '18 at 07:28
Btw. dont downvote the question just because the idea in it is bad. It is still a good question. A beginner can learn a lot out of it. — Bojan Hrnkas, May 18 '18 at 07:32
Also, 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 Burton, May 18 '18 at 12:26
@TheCatWhisperer Why? This is Software Engineering site. Where would you ask the question like this? — Bojan Hrnkas, Jun 19 '18 at 14:18

score 3 · Answer 1 · edited May 18 '18 at 12:01

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!

edited May 18 '18 at 12:01

Chen Li

123
4

answered May 18 '18 at 07:30

CharonX

1,633
1
11
23

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 08:18
3

Setters & Getters provide *nearly no* encapsulation, because you get no control over *when they are called* [This is how you get encapsulation](https://softwareengineering.stackexchange.com/a/285193/126524) – Caleth May 18 '18 at 09: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 09: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 09:50
I am also not saying that encapsulation is *required*. I am describing what it *is*. I'm a *big fan* of value objects when they make sense – Caleth May 18 '18 at 09:52
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
I'm not saying `Foo getFoo() { return foo; }` is the only way to write a getter. I'm saying having *any* `Foo getFoo()` is unencapsulated, *especially* if there is also a `void setFoo(Foo)`. Why does the world have to know there is a `Foo` *at all*? – Caleth May 18 '18 at 12:18
It depends on the level of abstraction: I can imagine a `Circle` class with a `Point centerPoint`, which has a `Point getCenterPoint()` and a `void setCenterPoint(Point point)` function. At the very basic that get/set function would only return/assign the centerPoint. If your Circle gets more complex, you could e.g. change the `get` function to maybe calculate the centerPoint on the fly (as you now use a 3-point definition of a circle instead of center + radius, for whatever reason). By writing a `getter` / `setter` for centerPoint you **are** able to change the underlying implementation later – CharonX May 18 '18 at 13:41

Set result of getter instead of setter

1 Answers1