How to NOT use getters and setters

Question

I've been reading on reasons why I should and why I shouldn't use getters and setters. I read this article (A design strategy) on how/why not to use getters and setters but I'm just not "seeing" in what situation I wouldn't use them or, better yet, an alternative. Yeah, I need to see an alternative to getters and setters.

Answer 1

Why would you not want to use one besides in the class where it's declared (unless it involves some other business logic). I can't really think of a real alternative. Call it what you want but what you're doing is just declaring a method to get your values. It's just boiler plate code.

Also people using your API will expect getters\setters and might get confused when there are none.

For a nice read check out: Are getters and setters poor design? Contradictory advice seen

Answer 2

It's the second article I read from JW in less that three days and they both share the Why XXXXX is/are evil motto... leaving that behind I think I'll quote the final words of the article and give my opinion about it.

You shouldn't use accessor methods (getters and setters) unless absolutely necessary because these methods expose information about how a class is implemented and as a consequence make your code harder to maintain. Sometimes get/set methods are unavoidable, but an experienced OO designer could probably eliminate 99 percent of the accessors currently in your code without much difficulty.

I believe the author refers to concrete objects, like POJOs (why not entities) that do not interact with anyone. Your site has a login feature, so you have an user... why should you bother with getName and setName if it's just a String?

While this can be true, what happens if a name is null? Are you exposing yourself to NullPointerExceptions all around your code? Unless you do a check everytime you use that variable or you make sure no user has a null name you can never be sure. A getter can make it easy, but IMHO it's all about taste. You're just moving a check from one place to another.

Getter/setter methods often make their way in code because the coder was thinking procedurally. The best way to break out of that procedural mindset is to think in terms of a conversation between objects that have well-defined responsibilities. Cunningham's CRC card approach is a great way to get started.

Here, the author seems to be diggin further in the principle of CRC (explained in the article itself), which is a valid argument against most accessors.

Again, it's all about knowing your application and what will you let the others know about it. I can't think of an alternative right now, but instead of alternatives I prefer to dig into the concept of Cost VS Benefit, what's the benefit of avoiding a getter and how much does avoiding it cost to you (time to understand a variable, time to do checks, time to find the field, time to determine and handle the impact of a change where there's no accessor to limit it).

Another interesting point (and now that I think of it, one of the most important) is WHEN to avoid getters and setters. They're obviously evil if you expose something you're not supposed to, like some important variable that holds a counter and can leave your application in an inconsistent state (in other words... "go insane"). In those cases, a getter suffices.

Finally, a lot of frameworks and tools rely in those accessors to set and get values. Avoiding them means losing "compatibility" with those tools... unless you create indirect accessors or wrappers, for example.

Answer 3

Here's one:

public class Point {
    public int x;
    public int y;
}

There's no need for getters and setters, because the definition of a point is an x, y value.

A constructor like this would make the class easier to use.

public Point (int x, int y)

as well as the empty constructor

public Point()

Answer 4

Whether or not you use "getters" or "setters" really comes down to a question of need. For example, there are some persistence frameworks that require managed objects to declare getters and setters. Some templating frameworks require it.

If you want to limit visibility (from a code perspective) of a certain object's members, you can use a modifier on a getters for this. If you want to limit mutability, you can use a modifier on a setter for this.

It isn't really a matter of "preference" in terms of using a getter/setter. It is a matter of the goals you are trying to achieve and the requirements of the technologies you are working with.

Answer 5

From my experience:

In really most cases getter setter are best.

But when using fields inside the class it often is better to directly access the variable.

A disadvantage to getter / setter is when using in complex mathematical formulas, they are less readable, and more prone to erros, because the code does not look, like the formula in literature.

Example:

 return (p2.x- p1.x) / len;

is more readable than

 return (p2.getX()- p1.getY()) / len;

And thats only a simple example.

In rare situation you have the need for very high performance calculations. An example is java.awt.Rectangle The had the need to make x, and y public for performance reasons. But this is an exception.

Other programming languages have solved this, by introducing properties (C# and Objective C). They are used with dot syntax, but internally the getter or setter is called.