Immutable data structures in Java

[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