GettersAreEvil

Our coach pointed out that "getters are evil". Amusingly one of our team has this slogan pasted above his desk in big letters.

How would you explain the reasoning behind this? Maybe one of the problems with entity beans (and similar infestations of getters and setters) is that they encourage irresponsibility-driven design ;-) --DafyddRees

My take would be that with getters you are being informed of an objects innards. It comes down to method naming really - have the function of a getter, just call it something that fits with the business function (better still pass the object about - something to do with Visitors I'm sure...) - like you didn't pull it apart and it is nice and OO. --DanPollitt

Yes. How best to interact with a candle object:

candle.light();
candle.blowOut();

Not:

candle.getWick().getFire().setHeatIntensity(10);
candle.getWick().getFire().setHeatIntensity(0).

As well as it being easier to read candle.light() it also allows you to later on change the implementation of candle without having to modify hundreds of candle related objects.

--MpC

Getters are especially pernicious when they take arguments. This syndrome is far too common:

f = x.getFoo(z);
f.doStuff();

The computation is inside-out. It should be:

x.doStuff(z);

BenedictHeal? has a nice phrase for this. A lot of "getters", he says, are really "givers".

So what that transformation really says is that x has the StuffDooer? role, not the f? --DafyddRees

As far as the caller is concerned, yes. That X collaborates with F to fulfill its doStuff responsibility is no business of the caller. It's a Demeter thing. --KeithB

Be careful, though, not to get confused: getters are evil, but getters are not the only kind of accessor.

See also: CrC RrC