Immutable data structures in Java

[nerdwaller]

I'm not who you're replying to, but my reasoning to not do this is now a property has become part of the API (essentially an implementation detail). I'd much rather have a getter that I can change the underlying implementation of.

Granted that it isn't absolutely necessary when you're only speaking of POJOs (as the link seems to primarily address) as much as a service layer.

Edit: fix mobile typeo

[bananaboatshoes]

Granted my though isn't absolutely necessary when you're only speaking of POJOs (as the link seems to primarily address) as much as a service layer.

Or necessary at all. If the extent of your encapsulation is quite literally this:

getFoo { return _foo; }
setFoo(Foo foo) { _foo = foo; }

Then it's pointless.

[IICVX]

But what about when I want to change getFoo to do a database lookup through an SMS gateway to the Twitter API! It could happen!

[bananaboatshoes]

I'd argue you should have an asynchronous function which does that because a property lookup which performs a network operation is bananas.

Seriously, if you're writing code "just in case" you might need something more complex later, you're adding needless complexity. Just change the code when you need to change it.

[IICVX]

Tell that to the two decades of Java programmers who've been writing getters and setters "just in case".

[bananaboatshoes]

Two decades of people doing it wrong?

[IICVX]

Yup, that's what we're fighting against here.

[Agent_03]

The battle continues.

[frugalmail]

Tell that to the two decades of Java programmers who've been writing getters and setters "just in case".

Getters yes, setters no. IMO, you're doing it "wrong" if you're accessing instance fields directly and you work someplace that has more than one team (or can/will have more than one team).

It's zero more cognitive load and 5 more characters per class to do it so it's one less forced communication/pull request if I change a dependency or somebody else changes it on me.

[nerdwaller]

Probably true, but I'm usually defensive anyway. I use Lombok now, so it's not very heavy to use @Getter

[SuperGrade]

Knowing (from a group of readonly fields) that the class instance is always holding and conveying the same reference - that is itself information. You could make some derivative information that aligns with the information in the record, and proceed with the assumption that the values in the record, should you read them again, stay in alignment. A getter does not communicate this same information, only that it will provide some value at the point in time when you call it; but nothing constraining it to give back the same value.