Getters/Setters is an anti-pattern, don't you think?

[Yegor Bugayenko]

Java programs are full of getters and setters (setName, getById, setRequest, etc.) Some people consider them an anti-pattern in object-oriented programming. Recently I wrote an article where tried to summarize the arguments: http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

Would be great to hear you opinions.

[Jelle Klap]

Articles with "is/are Evil!omg!!1" in the title. Evil. Period
The brief PS at the end of the article about JavaBeans and frameworks that rely on that specification - which are legion - kind of glosses over the fact that working with getter/setters is unavoidable reality.
That kind of makes the whole discussion academic. Also, this flawed reality turns out to be quite a productive little reality, as it happens. What with all these handy frameworks being able to work with your objects, using a convention-over-configuration approach. In my book that trumps taking the puritans stance on object orientation. For domain classes, anyway.

[Ulf Dittmer]

+1 on what Jelle said. Aside from pragmatic reasons of having to work with what is currently out there, the article argues a misplaced OOP fundamentalism, IMO. If a class that is nothing but a data container full of getters and setters makes for a better design, then it is a good thing to have such a class. Basically saying "that can by definition not be a good design because it clashes with my view of OOP" -when there is in fact no single widely accepted such definition- is not helpful.

[Yegor Bugayenko]

If a class that is nothing but a data container

This is where is the misconception I'm talking about. An object is NOT a data container. We're not in COBOL any more. Java is an object-oriented language! I hope

[Ulf Dittmer]

An object is an instance of a class - if that class is nothing but a data container, is an instance of it not an object? My point is, hard and fast separations of what is a good object -and what is not- are subjective, and not helpful. I'm not disagreeing with the gist of the post, but I am disagreeing with wanting to set absolute rules. A good design may well violate a purist's rules, given that there is no definite rule of what an object is or is not.

[chris webster]

Yegor Bugayenko wrote:An object is NOT a data container.

What's wrong with data containers? Java (prior to Java 8) expects you to wrap pretty much everything in an object, so when you need to pass some data around you often end up with "data container" objects which are mostly/completely state rather than behaviour. More generally, one of the core problems with OOP is that it's based on subjective and sometimes disputed ideas of what constitutes an "object" and how they should interact, hence the need for lots of ad hoc patterns (and anti-patterns) to help guide developers towards better implementations.

But I agree that getters/setters are a PITA e.g. when you have use Java Beans, even if you can auto-generate them where necessary via your IDE. This is one place where languages like Groovy or Scala make life easier, because this stuff "just works" without a load of hand-coding or pointless boilerplate in your code. I'm starting to appreciate Scala's approach in particular i.e. properties are public and immutable by default but you can make them private/mutable if necessary (often it isn't). And Scala's case classes are a bit like Java Beans, but done properly!