Are getters and setters poor design? Contradictory

Question

This question already has an answer here:

• Why use getters and setters/accessors? [closed] 38 answers

I'm currently working on a simple game in Java with several different modes. I've extended a main Game class to put the main logic within the other classes. Despite this, the main game class is still pretty hefty.

After taking a quick look at my code the majority of it was Getters and Setters (60%) compared to the rest that is truly needed for the logic of the game.

A couple of Google searches have claimed that Getters and Setters are evil, whilst others have claimed that they are necessary for good OO practice and great programs.

So what should I do? Which should it be? Should I be changing my Getters and Setters for my private variables, or should I stick with them?

Answer 1

As always the only answer is: it depends. If you are the only peron touching the code, you can do anything you're comfortable with, including taking shortcuts.

One of the benefits of using setters is that checks need to be performed at only one location in your code.

You might want to pay some closer attention to what is actually being get and set by these methods. If you're using them to provide access to constant values you are probably better off by using constants.

Answer 2

• Very evil: public fields.
• Somewhat evil: Getters and setters where they're not required.
• Good: Getters and setters only where they're really required - make the type expose "larger" behaviour which happens to use its state, rather than just treating the type as a repository of state to be manipulated by other types.

It really depends on the situation though - sometimes you really do just want a dumb data object.

Answer 3

I don't really think they are evil. But I would love to live in a world where I never had to use them unless I really needed to.

One example I read above was future-proofing your code. For example:

public void setValue(int value)
{
    this.value = value;
}

Then, the requirements change and you need to track how many times the value was set.

So:

public void setValue(int value)
{
    this.value = value;
    count++;
}

This is beautiful. I get it. However, in Ruby, would the following not serve the same purpose?

someobject.my_value = 100

Later, you need to track the number of times my_value was set. Well then, could you not just override the setter THEN and only THEN?

def my_value=(value)
    @my_value = value
    @count++
end

I'm all for beautiful code but I have to admit, looking through the mountains of Java classes we have and seeing literally thousands and thousands of lines of code that are NOTHING but basic getter/setters is ugly and annoying.

When I was developing in C# full time, we used public properties all the time and did custom getters/setters only when needed. Worked like a charm and it didn't break anything.

Answer 4

The presence of getter and setters tends to indicate (a "smell" if you are into that sort of primary school language) that there is a design problem. Trivial getters and setters are barely distinguishable from public fields. Typically the code operating on the data will be in a different class - poor encapsulation, and what you would expect from programmers not at ease with OO.

In some cases getters and setters are fine. But as a rule a type with both getters and setters indicates design problems. Getters work for immutability; setters work for "tell don't ask". Both immutability and "tell don't ask" are good design choices, so long as they are not applied in an overlapping style.

Answer 5

This depends on the programming language in question. Your question is framed in the context of Java, where it seems that getters and setters are generally thought of as a good thing.

In contrast, in the Python world, they are generally considered as bad style: they add lines to the code without actually adding functionality. When Python programmers need to, they can use metaprogramming to catch getting and/or setting of object attributes.

In Java (at least the version of Java I learned slightly a decade ago), that was not possible. Thus, in Java it is usually best to use getters and setters religiously, so that if you need to, you can override access to the variables.

(This doesn't make Python necessarily better than Java, just different.)

Answer 6

You've already had a lot of good answers on this, so I'll just give my two cents. Getters and setters are very, very evil. They essentially let you pretend to hide your object's internals when most of the time all you've done is tossed in redundant code that does nothing to hide internal state. For a simple POJO, there's no reason why getName() and setName() can't be replaced with obj.name = "Tom".

If the method call merely replaces assignment, then all you've gained by preferring the method call is code bloat. Unfortunately, the language has enshrined the use of getters and setters in the JavaBeans specification, so Java programmers are forced to use them, even when doing so makes no sense whatsoever.

Fortunately, Eclipse (and probably other IDEs as well) lets you automatically generate them. And for a fun project, I once built a code-generator for them in XSLT. But if there's one thing I'd get rid of in Java, its the over-dependence on getters and setters.