Add 2 attributes and return to a third attribute

Question

I am trying to add two attributes and return the value to a third attribute, follow example, it is possible and if yes what I am doing wrong?

package testesomaatributos;

public class TesteSomaAtributos {

    public static void main(String[] args) {
        AtributosAqui o = new AtributosAqui();

        o.setN1(10);
        o.setN2(5);

        System.out.println(o.getR());
    }

}

---

package testesomaatributos;

public class AtributosAqui {
    private int n1;
    private int n2;
    private int r;

    public int getN1() {
        return n1;
    }
    public void setN1(int n1) {
        this.n1 = n1;
    }

    public int getN2() {
        return n2;
    }
    public void setN2(int n2) {
        this.n2 = n2;
    }

    public int getR() {
        return r;
    }
    public void setR() {
        this.r = this.n1 + this.n2;
    }
}

Answer 1

I see some problems in this code, all conceptual.

What you call an attribute is actually called a field. Hey I know, there’s plenty of place teaching wrong, it’s not your fault.

This code should probably have a builder. Everything suggests that it is more suitable (with little information, I can not dig). And there you have to wonder if you should have getters and setters, this is the mechanism of fashion but that people use without thinking if they should have it in their code, if it is meeting a real reason and not just following rules invented around. The thing is so serious that people give more value to it than the builder.

Especially should you think about whether a Setter it is necessary, in many cases should not be able to change the state after its construction. Even in many cases this should not even be a class, but for now Java does not have a way to create a type without being this way, which has always been a language deficiency that "now" will be fixed.

But the getter may also be wrong for not being necessary for what you want to do, may just want to access the direct data and never otherwise, so there’s no reason to follow the good rule if that’s what you want to do. Adopt the correct semantics. If it was forbidden to directly access the field the language would not even let you do it. Some people have appropriated the absolute truth and say they should never do this, even the most pragmatic language, allowing. But in other cases it should even have a way to access the data without the direct field, but it would be a method that makes something more semantic and not a getter that has a very simple semantics and some say that this is conceptually wrong.

The names all say nothing and this in itself is a conceptual mistake, giving meaningful names to everything is fundamental for the code to be readable and give an understanding of what it should do.

This is a seemingly artificial case that probably shouldn’t even be a class, making a simple algorithm would do better. Modeling classes is always about doing something that makes sense. If you don’t need it and do it for "study" you are studying wrong, because class is not just a mechanism, it is a philosophy of how to build software, if you do wrong learn wrong.

Maintaining the general idea your code seems to do what is written in the question, but fails to execute correctly, by a conceptual error. If an object depends on a previous operation to function correctly (which shows the Mauroalmeida comment) then there is something wrong with it, it is not an object cohesive, and your code does that. If you don’t execute the method setR() the sum will not be available. Actually this is not even a Setter, although it uses the same name. A project pattern called Setter always has a method called setXXX(valor) or something similar (there are languages that have a better syntax for this and call it property), so you always have to receive a value, your method does not receive one and is not a Setter (I’m sure you think it’s one). That’s why I say you need to understand what you’re using.

Even if you insist on that mistake, getter (getR()), should give error if the sum was not realized. And yes, you would need to create a mechanism to control this, which seems to me absurd (I have a question on the subject, in other times some active users of the site would have already responded). I am not suggesting to do this, the most correct is this getter just give the result and not even keep something in another field, so:

public int getR() { return n1 + n2; }

I put in the Github for future reference.

As the hkotsubo comment above. The only question is that this would eliminate the field r and the question says you want this. Of course, I think it is an XY problem, it is wanting to solve a problem caused by the problem created by a previous wrong decision.

I’m not getting the idea that all this stuff I said is wrong can’t be used properly in another case or in some case that’s clearer what you want to do.

There’s no point in trying to object-oriented programming, when the goal of this technique is to make the code more organized and semantic, if you don’t understand the semantics of the problem or the semantics of the language or the semantics of the patterns you’ve decided to adopt, is already doing wrong by definition.

That’s why I always say that the examples you have out there are not to make right, because they are cake recipes, in general television show recipes, are not made to produce delicious foods that anyone can make, it’s just to make people’s mouths water. If the person does not dominate that much the recipe serves for nothing.