What is the difference between referencing an attribute directly or by get / set

There is no security breach to allow access to the fields ( I do not like the term attribute for this , yet more in this context). At most it's an encapsulation break, but it still depends on the case.

If you only have the private field, everything normal, no problem, you can do at will. The problem starts getting more complicated when you have both.

In fact nothing prevents you from accessing one or the other as needed. Obviously, direct field access only allows you to pick up the value and change its value. The getter / setter methods may give the impression that it is a common access, but they may be performing other actions at the time of access or assignment. So they are only equivalents by coincidence. Their purposes are different.

The ideal is to access by methods (when they exist) to maintain consistency. But if you have a good reason to access the field and know of the implication that direct access will not perform the actions normally set in the methods, that's ok.

Then the answer is depends. The most important thing is to understand that the call of one or the other potentially has quite a different semantics. This can be very confusing.

Methods are usually slower, but when accessed privately, there is an optimization, and the method call is likely to be replaced by its code ( inline expansion ).

As a matter of curiosity, methods are created by default by programmers, even if their only action is access and direct assignment without doing anything else, that is, it does the same as if they were accessing the direct field, because if one day of the methods, they were already being used. If you start by making the field public and one day you need to add a processing to your read or write access, then the method will have to be added by changing the public API and requiring all of its consumer codes to be changed. Creating an abstraction increases encapsulation and improves decoupling by hiding deployment details.

So if the code will only have access to the field privately OR you are absolutely sure that you will never have a method to access that field, you can expose the field. If you can not guarantee this, it is safer to create the methods. Unless the API is not so public and accepted to change consumer codes.

What is best depends on each scenario. What you can not do is nail the decoupling and expose the implementation detail, which is the field. Or you will have one benefit or the other.

I replied something similar about C # .

First of all, you spoke in security. Security is not intended to choose to use private variables. The intention is to protect against programming errors (especially the coupling) that lead to a degradation of the quality of the code.

There are those who will talk about performance concerns, but this is paranoia - it is very easy for the compiler to remove this extra call or during compilation to bytecode or during execution itself. And, of course, concern for performance without measurements is premature optimization, famous for being the source of all ills.

The private attribute does not let you access the variable or method in another class, except in the class itself, by using the this keyword.

When you need access in another class, you need to use get and set .

So using this.getParametro () in the class containing the private variable does not make much sense because it would be easier to use this .

As you said, if you do not have access, then you do not even need to create the get and set methods.

Answering your final question: No, it would not be wrong to use this.parametro , it's actually the right way. I hope I have clarified your doubt.

With the setters, you can check for conditions before actually changing the variable.

public setIdade(int anos) {
    if (anos > 0) {
      idade = anos;
    }
}

After all, an age should not be negative, although an int may.

Using the attribute directly, there is no way to check the semantics of the change. That is, does it make sense to be a negative age?

In the case of getters, you can change implementation without changing the abstraction. In the example, stop using an integer to save the age and start using the current and birth dates.

The class customer code will not need to know about this change. Just call getIdade () as it already does.

public int getIdade() {
  return this.idade;
}

public int getIdade() {
  return diferenca(hoje, nascimento);
}

A good analogy for this problem is the classic one of opening the television to change the channel (private variables) instead of using the remote (methods).

Imagine that you have a television class. And you want to change the channel.

It may be easier to access the channel variable directly (opening the television), but you want to keep the logic of switching channels on television.

Making changes directly to the television variable, you can make the software work now, but it is much easier for the logic to break into a future maintenance.