A Setter method can receive a getter + value as a parameter?

Question

I created the advisory methods Setter and getter for the balance attribute.

It is correct to use these advisors within each other? One being used as parameter for the other.

More specifically the getSaldo() being a parameter of setSaldo() that is within the method sacar().

The line:

this.setSaldo(this.getSaldo() - saque);

Example code in Java:

public class ContaBanco {
    private int saldo;

    public int getSaldo() {
        return saldo;
    }

   public void setSaldo(int saldo) {
        this.saldo = saldo;
   }

   public void sacar(int saque){
            //this.saldo = this.saldo - saque;
            this.setSaldo(this.getSaldo() - saque);
   }

}

The code itself worked. But I don’t know if it’s correct and within the standards that way.

The subject of the test:

public static void main(String[] args) {
        ContaBanco c1 = new ContaBanco();
        c1.setSaldo(500);
        c1.sacar(100);
    }

Answer 1

It’s okay to do that. But there’s one question that the use of this type of pattern creates: the code gets a little less DRY and has two ways to access the field, directly and indirectly. It is not the end of the world, but has to think about the use.

Conceptually speaking the most correct would only call through the access method, so it gets more DRY and ensures that the lit is done uniformly at all points. But there are reasons for performance or even different semantics that are desired at that time.

Of course, if it is known that the method does nothing extra and is an indirect over access to the field in pure form, then I question a little the creation of this type of method. I even understand that this is necessary for a language deficiency.

You have to understand that if you change the way you access the field if you take its value by the method this change will be reflected in what you took, and if you use the field this change will not be noticed in direct access. Keep this in mind in the decision.

Use whatever is most suitable for intent, and in doubt it seems that the method is the best, since it was created.

Write code that makes sense, not what meets standards. When the pattern makes sense, ok, but make sense comes before the pattern.

Answer 2

I wanted to supplement Maniero’s answer with something I think I had to say.

I created the advisory methods Setter and getter for the balance attribute.

Did you really need to create it? It’s important to differentiate between the interface exposed by the object and the implementation details that exist within it. Your account has an internal field called saldo, but it might not exist, there could be a historical list of financial transactions that you go through summing up the results to get the current balance at the time you call the getSaldo() (for example).

With this differentiation you protect the external interface of your object, which tends to be more stable, without losing opportunity to change the internal details as needed.

Does this Ttertter make sense? I mean, does it make sense to provide a transaction to change a bank account balance to an arbitrary amount? Or what you really need in your account are credit and debit transactions (public methods)? That change the balance in a controlled way. Think about it.

About there being a setSaldo() intern, private, Martin Fowler talks about but it does not impose it. But this is quite different from making it available for public use by all clients of the object, and the object may not have the need to expose this arbitrary balance change.