
Getters/Setters. Evil. Period - yegor256a
http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html?2014-37
======
ggchappell
Interesting article.

But I see a problem -- or at least a _challenge_ :

> Dog dog = new Dog("23kg");

> int weight = dog.weight();

> The dog is an immutable living organism, which doesn't allow anyone from the
> outside to change her weight, or size, or name, etc. She can tell, on
> request, her weight or name.

See the inconsistency? We have code demonstrating the creation of a Dog with
the weight property specified. Then there is a discussion of some of the
properties a Dog has -- but the other properties are not specified in the code
we just saw. The description of a Dog, and the code shown above it, are not
based on the same design.

Of course, one can argue that this code is merely a sample; it is there for
clarity, to get an idea across. We do not want to obscure that essential idea
with zillions of extra parameters; this would only confuse the reader.
However, _that same argument applies to "real" code, too_.

Ensuring that an object has all the properties it is supposed to have, is
something that we need to be able to do. Some APIs give you a creation
function with gobs of parameters. These irritate me. I find code to be easier
both to write and to read if there is a short call to create, followed by
several property-specifying calls, each handling a single property. Another
name for such calls is _setters_.

The latter approach has other advantages, too. If the creation function gives
me an object with sensible defaults, then I do not need to specify properties
that I am not interested in. And new properties can be added without breaking
existing code.

Now, actually, I think I am basically in sympathy with this article. In OO,
the point of an object is not to be a bare tuple with some code hanging off of
it. An object is the concrete expression of a collection of responsibilities;
it exists in order to fulfil them. An interface with getters & setters
generally does not mesh well with such thinking.

However, that does not mean that banning getters & setters entirely is a
desirable design guideline.

So, yegor256a, how do you think all those properties that a Dog has -- or
might have in a future revision -- ought to be specified?

