In case I assign the methods get/set, and to stay in the pattern I change the initial letter to uppercase, getting:
string Nome { get; set; };
Now I can easily access the name variable through the get/set.
Ok, a lot of people do this, now you will access a private field (yes, it will be private automatically), and in this case the access methods called getter and Setter evening public
.
To do this which changes I put the code above as follows:
public string Nome
That way he will access equally as if he were get/set, is no longer practical and "clean" so do it this way?
The first most obvious change is that it finally made the field public, and did not even suspect that the others were not so.
Another important issue is that it is calling attribute because almost everyone doesn’t know the name of it and you were taught wrong. The name of it is field.
Your perception that this may be better is valid and above average. Many people have learned the formula that must use property and accept it as if it were absolute truth without question. Programmer is an engineer, he must be questioner. He has to work as a chef cooking, not a cake recipes cook. You’re on the right track.
In fact in many cases this is the best way. If no action should be taken when you assign a value to the field or when you take a value from it. It’s faster and simpler, and it’s usually what you want.
If you want to place an action, be it a validation, a calculation before delivering a value, or trigger an event, no matter what, then you need the property.
The cool part of C# is that the field and property have identical syntax to access. Then you start using the field and if one day you need to have an extra code in the access, you switch from field to property without problems. Or almost :)
But in your case you’re using the simple property, so why do so?
In simple applications where you compile all of it together it really doesn’t make sense, it’s a waste of time. Even if you have some optimization has no advantage using the expensive property.
But if you create a file Assembly irrespective of other parts of the application, if Assembly is part of a library or framework independent that is used in other applications, there you are stuck if you need to change from field to property. If you change your code and all consumer codes are not changed, it will be a problem.
Depending on how to do it will give error or access the field directly without going through the methods getter and Setter, and it’s no longer what you want. Before it was direct access, now you want this method of proxy. It changes everything. So if you had done it properly from the beginning you wouldn’t need to modify anything in the consumer, you would have a indirect and the internal code, whether it is basic access or with some extra logic, is implementation detail, in any case it will call the method, only what it will do can change according to the code that is in the Assembly of your class where is this field that is never directly accessed.
Some people consider always doing so as a "good practice". And I always say good practice is following a cake recipe without knowing what you’re doing. When you know what you are doing it ceases to be good practice and becomes correctly applied knowledge, even if it is the same thing.
An important note is also that the property can exist independent of a field, it can be just an access method that makes a calculation and gives you. Or it can give a fixed value. And of course, it can involve various fields and even other properties.
See more in:
I’m studying because even though I’ve answered this myself, I don’t know if it’s exactly encapsulation as many people think, I may have learned wrong like everyone else. That’s an abstraction, I don’t know if it’s encapsulation. Maybe it’s not, and then we get into another issue that I didn’t cover here is that some say you shouldn’t use methods getter/Setter or properties.
Related: https://answall.com/q/293801/112052 and https://answall.com/q/25995/112052
– hkotsubo
Possible duplicate of Methods and properties in C# - advantages and disadvantages
– Roberto de Campos
This is called encapsulation, an OO concept, gives a read on this and see the links above that posted that you will understand
– Ricardo Pontual
Did any of the answers solve your question? Do you think you can accept one of them? Check out the [tour] how to do this, if you haven’t already. You would help the community by identifying what was the best solution for you. You can accept only one of them. But you can vote on any question or answer you find useful on the entire site.
– Maniero