Getters and Setters are bad OO design? [duplicate]

Answer 1

I suggest that you read the whole article carefully as it presents well thought out arguments and alternatives. The question itself is too open ended and the answers you get here will be just more opinions.

Answer 2

Getters and Setters are bad OO design?

Only when used without thinking.

If you're to create a value-object to transport data, they're fine.

If you're creating a more important object then they shouldn't be there. Take a look at the ArrayList interface^* for instance. You don't see Object[] getElementData() because that would break the encapsulation ( some one may temper the underlying array ) .

^* _{Im referring to the public interface of the class ( the methods exposed by the class definition )}

Answer 3

There are other articles that say they are good design. But the answer is this: getXXX and setXXX are good or bad based on usage. these mathods do make a lot of things easier. So if some article says it's a bad design I think; it's just trying to be too hard on the idea.

One of the biggest usage of these methods are in a lot of framework and used as a reflection mechanism.

So don't completely avoid using these, rather... use it judiciously.

thanks Ayusman

Answer 4

The way I read it, the author argues that blindly putting getters and setters around fields is no better than just making the field public.

I believe that the author argues that getters and setters should be placed sparsely, and with care, because the idea of OO is that objects should limit their exposure to what is needed only.

Answer 5

Getters and setters are just methods. What do they do? They change a field into a property, and that's an important distinction.

A field is a bit of data, of state, in the object. A property is an externally observable characteristic, part of the contract of the object. Spraying the guts of an object all over the place, whether directly or through getters/setters, is always a bad idea. Poor design. But raising that to the point of saying that getters and setters are always bad? That's just some poor programmer without a sense of good taste claiming that a vague rule of thumb (which they didn't really understand in the first place) is a cast iron law.

Personally, I tend to go for trying to keep properties as being things that don't change unexpectedly underneath the clients' feet. (Clients of the class that is.) The only properties that I'll change dynamically are ones they can't write, and even then I'll try to avoid it. I feel that properties are in many ways values that control the behaviour of the instance which are set by the client, not arbitrary things under the control of the class. (That's what normal field is for...)

Answer 6

Yes, getters and setters is an anti-pattern in OOP: http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html. In a nutshell, they don't fit into object-oriented paradigm because they encourage you to treat an object like a data structure. Which is a major misconception.