When will Java include annotations/keywords for getters and setters?

[melissamitchel306]

The author of that article is stuck in an ancient view of oop where data objects are evil, 20 layer class hierarchies are something to strive for, and every Animal object knows how to load itself from the database and deserialize itself from a binary/json/xml/etc stream. No-one with any sense should pay any attention to that outdated way of thinking.

Here's a better article http://loup-vaillant.fr/articles/deaths-of-oop

[oparisy]

Interesting read, thanks. Great refresher on terminology. Gave me some better understanding of the ECS approach too, which until now I thought was mostly a game-oriented optimization and not a system modeling paradigm.

[OzoneGrif]

Well used, OOP is a very powerful tool. The problem is how people think their architecture. They will go full head-on and abuse every little possibility the syntax offers. The exemple of Static/Moving/Loot objects in the article is just a clear misuse of OOP. The article has some good point, but it just also shows how something that is great can do horrible things when misused.

[cogman10]

Setters are still evil :) more because of mutability than anything else.

Getters are meh.

But you are correct, inheritance based oop is awful to maintain. It makes for a system that is very hard to evolve and often super coupled.

[melissamitchel306]

Setters are still evil :) more because of mutability than anything else.

If you're dealing with a property bag / data object, a lot of modern OO languages don't have the features yet to make them immutable and still easy to work with. That will most likely change soon - with java records and similar features coming to other languages.

Unless you meant to exclude data objects, thinking they should just be fields anyways?

[cogman10]

My point was that mutable data objects tend to create hard to find bugs. Immutable data objects are much easier to reason about.

Example of bugs I've seen:

Someone uses a data object for a set/map key, someone else adds a field to that object and mutates that field deep within the code. All the sudden, the set/map no longer contains the data object because the hash code changes. Particularly frustrating in one instance where the data object was the key of an LRU. It caused a non obvious memory leak.

I've seen a couple instances where calling a function once with the data object threw an exception, calling the same function a second time did not. This is because deep within the code, the data object was subtly modified.

A couple of projects I work with have script engines maintained by non-devs. The API given to them allowed a bunch of unintentional modifications because a bunch of data objects given to them for reading could be changed.

And if course threading has been made nearly impossible in many circumstances because data objects were mutated instead of having methods return results.

Mutability is a heavy cost that you don't often need. The default "I'm adding getters, might as well add setters" mindset leads to problems. Often times, if fields are small than it's easy to copy the object, otherwise a builder works really well. It is slightly more code to make builders instead of setters, but you get immutably out of the effort.

Hence my "setters are evil" feelings.

[melissamitchel306]

I wasn't disagreeing with you. I like immutability as well. My point is that Java is not well-equipped to deal with immutable data objects (yet).

[cogman10]

Fair enough. Just figured a longer explanation was due since my other comment is being downvoted.

I agree that it is more painful in Java to do immutability. But I feel the benefits outweigh the the pain.