Getters/Setters. Evil. And point

Article by Egor Bugaenko September 19, 2014 | Posted in: Core Java This old debate was started by Allen Holub in his famous article, back in 2003, Why getter and setter methods are evil - are getters/setters an anti-pattern and should they be avoided, or is it something we should inevitably needed in object-oriented programming. I'll add my half a penny to this discussion. The gist of the text below is this: getters and setters are bad practice, there is no excuse for those who use them. But again, to avoid misunderstanding, I'm not at all suggesting that the use of get/set should be avoided where possible. No. I'm talking about the fact that you didn't even let them close to your code . How do you like this statement? Worthy of your attention? Have you been using the get/set pattern for 15 years and are you a respected Java architect? And you don't even want to hear this nonsense from a stranger? Well... I understand your feelings. I felt the same way until I came across David West's "Object Thinking" - it's the best book on object oriented programming I've ever read. So please. Calm down and try to understand what I am trying to explain. Subject of Controversy There are several arguments against "accessors" (another name for getters and setters) in the object-oriented world. And they are all very valid arguments. Let's take a look at them briefly. Ask Don't Tell: Allen Holab says, "Don't ask for the information you need to do a job; 'ask' an object that has that information to do the job for you." Violated Encapsulation Principle : An object can be taken apart by other objects, because they are able to embed any data in the object, through setters. An object simply cannot encapsulate its own state safely enough, because anyone can change that state. Disclosed Implementation Details: If you can get one object from another object, then it turns out that we rely too much on the implementation details of the first object. If tomorrow it changes (for example, the type of the result), then we will have to change the code. All of the above justifications certainly make sense, but the most important point is missed here. Basic Misconception Most programmers believe that an object is a data structure with methods. I quote Bozhidar Bozhanov's article: Getters and Setters are not evil. But most objects for which getters and setters are created simply contain data. This delusion is the result of a huge misunderstanding! Objects don't "just store data". Objects are not data structures with attached methods. This concept of "storing data" came to object-oriented programming from procedural languages, especially C and COBOL. I'll say it again: an object is not just a collection of data elements and the functions that manipulate them. An object is not a data object. What then? Ball and Dog In true object-oriented programming, objects are living beings, just like you and me. They are living organisms, with their own behavior, properties and life cycle. Can a living organism have a setter? Can you attach (“set”) the ball to the dog? Don't think. But this is exactly what the piece of code below does:

Dog dog = new Dog();
dog.setBall(new Ball());

Well, how is it for you? Can you get (“get”) the ball from the dog? Well, let's assume you can. In case she ate it and you performed an operation on her. In this case, yes, you can get (“get”) the ball from the dog. This is exactly what I'm talking about:

Dog dog = new Dog();
Ball ball = dog.getBall();

Or an even more ridiculous example:

Dog dog = new Dog();
dog.setWeight("23kg");

Can you imagine this in real life? Does it sound like you write every day? If yes, then you are a procedural programmer. Just admit it. Here's what David West says on page 30 of his book: The first step in transforming a successful procedural developer into a successful objective developer is a lobotomy. Do you need a lobotomy? I definitely needed it, and I got it while reading West's book "Object Thinking". Objective Thinking Start thinking like an object and you'll immediately rename these methods. Here's what you might get:

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

Now we treat the dog like a real animal that can take the ball from us and can give it back if we ask. Just in case, I note that the dog will not be able to return NULL. It's just that dogs don't know what NULL is! Objective thinking (thinking) immediately removes NULL references from your code. A Fish Called Wanda (1988) by Charles Crichton In addition, objective thinking will result in the immutability of an object, such as the "weight of a dog" in our example. You would rewrite the code like this:

Dog dog = new Dog("23kg");
int weight = dog.weight();

A dog is an immutable living organism that will not allow anyone outside to change its weight, or size, or name, etc. She can "report", on request, her weight or name. There is nothing wrong with public methods that expose requests for certain "internal" properties of an object. But these methods are not "getters" and should never be prefixed with "get". We are not "getting" out of a dog. We don't get her name. We ask her to tell us her name. See the difference? We're not even talking about semantics here. We differentiate the procedural approach to programming from the object-oriented one. In procedural programming, we work with data, manipulate it, get (get) , and set (set), and delete, if necessary. We lead, and data is just a passive component. The dog is nothing to us - she's just " PS . And yes, you might be asking, "What about JavaBeans, JPA, JAXB, and many other Java APIs that depend on get/set?" What about a built-in function in Ruby that simplifies the creation of accessors? Well, what can I say... you're out of luck. It is much easier to stay in the primitive world of procedural COBOL than it is to understand and accept the beautiful world of real objects. PPS . Forgot to say, yes, dependency injection via a setter is also a terrible anti-pattern. But more on that in the next post! Original article