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 immut

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?