There is no security breach allowing access to the fields (I don’t like the term attribute for this, further in this context). At most it is a encapsulation break, or abstraction leak, even so depends on the case.
If you only have the private field, everything normal, no problem, you can do it at will. The problem starts getting more complicated when you have both.
In fact nothing prevents you to access one or the other as needed. Obviously, direct access to the field only allows you to take the value and change its value. Methods getter/Setter 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’re only equivalent by coincidence, their purposes are different.
The ideal is to access the methods (when they exist) to maintain coherence. 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 established in the methods, it’s okay.
Here the answer is: it depends. The most important thing is to understand that the call of one or the other potentially has very different semantics. This could be very confusing.
The methods are usually slower, but when they are accessed privately there is an optimization and probably the method call will be replaced by his code (inline Expansion), if the implementation is simple.
As a curiosity, the methods are created by default by the programmers, even if their only action is access and direct assignment without doing anything else, that is, does the same as if accessing the direct field, because if one day you need 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 has to be added, changing the public API and requiring all of its consumer codes to be changed. Creating an abstraction increases encapsulation and improves decoupling by hiding the implementation 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 cannot guarantee this it is safer to create the methods. Unless the API is not so public and you agree to change consumer codes.
What is best depends on each scenario. What cannot be preached is decoupling and expose the implementation detail, which is the field. Either you have one benefit or the other, everything is tradeoff.
I replied something similar about C#.
I ended up "flying" here at the time of the question and put parameter instead of attributes. Then, the absence of getters and setters and direct reference to the attribute would be indicated when the developer is sure that the attribute will not undergo change relative to its validation and will not be exposed to another class?
– Leonardo
If you change the E you used in there for an OR, that’s right. Obviously if the field is only implementation details (it is private) there is no problem and there is no need to create the methods. There are people who create in this scenario because everyone creates, there is no real reason. It is recommended not to create in this case. Another situation now: if you’re going to expose the camp, consider that you can never make it private again if you ever need to. Because someone may have consumed the direct field, a change would be a break from the API. In anemic classes they make sense. In others you have to be careful.
– Maniero
Particularly I prefer to avoid creating the methods until they are necessary. But it is a mistake to adopt this as the default. You have to really look at it case by case. Because a mistake there can create huge complications. If I am developing alone or in a lean, cohesive team with good tools Refactoring, I would risk more not using abstraction and more exposing the field. In an API for third parties consume, I would go the safe way for sure and create the abstractions. Otherwise a change would force depress this API and create a new one.
– Maniero