Why are getters and setters that don't do anything a good practice?

[DtY]

I understand that using getters and setters can be good if you want to validate the input or something, but why is it good practice to write them when you're not doing that?

php:

class Something { private var x; function x() { return x; } function setX(n) { x = n; } } // Is better than? class Something { public var x; }

Why should I waste time doing the first one?

[Euphoracle]

Getters and setters are useful when you want to restrict how something can be set. Eg. if you have string PostalCode, you might want to restrict that to being set to a valid Postal Code and throw an exception if it isn't. If you don't have accessors doing anything... that's merely for consistency. You might also store data a different way than someone else might want it so in a getter you might convert it somehow.

The purpose is to control your classes internal data and only change it by your rules. Mind you, if you have no rules, I guess it's fine to not use them? This is where C# shines because the accessor functions aren't 'GetBleh' and 'SetBleh', it's just Class.Bleh and it uses the correct functions by itself (as they are defined).

[chrisbrown]

It also simplifies testing quite a bit. Rather than comb your code for bugs, you can just add an output statement to a particular method to examine all the data that is being passed through it. Seems trivial for small programs but it saves some headaches when scaling up.

[wtd]

And the only real reason not to use them are languages that make the common case overly verbose (and permit one not to). Consider Ruby's take on it. There are no public instance variables, so you have to use an accessor. But, if you just need a very simple accessor, it makes it very easy to write the simple accessor.

In the statically-typed world, the newest versions of the C# language make this easy as well.

[DemonWasp]

It's also helpful when extending existing code. The parent class may not care to validate X or know when X is set, but a subclass might. If X is public, you can't extend the parent class (because people will access it directly, not through the getters/setters); if X is accessed through accessor methods, then you can.

[[Gandalf]]

wtd @ 2010-04-23, 1:33 pm wrote:

And the only real reason not to use them are languages that make the common case overly verbose (and permit one not to). Consider Ruby's take on it. There are no public instance variables, so you have to use an accessor. But, if you just need a very simple accessor, it makes it very easy to write the simple accessor.

In the statically-typed world, the newest versions of the C# language make this easy as well.

The more I learn the more I realize wtd's teachings are wise, not that I didn't think they were wise earlier! QFT.

[2goto1]

I've found getters and setters to have more value as code scale increases. It may be subjective at times, particularly on smaller projects, but my preference is to take a consistent approach and always use getters and setters. Consistent clear rules can also benefit projects developed by larger teams. Consider that if the team's coding standards are more black and white, the net result is a more consistent source code tree. As well, the team's developers spend less time when designing their class properties, particularly when considering whether or not their properties should be encapsulated with getters and setters.