8
I received this question in a test and could not answer:
"How is it possible to declare a property readonly
in . NET / C#?"
8
I received this question in a test and could not answer:
"How is it possible to declare a property readonly
in . NET / C#?"
9
Just use the modifier readonly
in a field:
public readonly int Numero;
For example. So, Numero
only one value can be assigned in the Constructor of the class.
Note that it is not used readonly
property; To make a read-only property, its setter
as private
:
public int Numero { get; private set; }
9
Mads Torgersen (from the C#design team) announced that this is a Feature that is being considered for the next release (C# 6.0?).
At present:
private readonly int x;
public int X { get { return x; } }
With a C# 6.0:
public int X { get; } = x;
2
To place a read-only feature, we have two options, put only get in the property statement or declare set private.
2
One way is to create a property without the Set
public int PropriedadeReadOnly
{
get { return propriedadeReadOnly; }
}
And a second form, which allows the property to be written only once, usually in the constructor of a class. It is using readonly
public readonly PropriedadeRead;
0
In the case of VB net, you can write like this:
Public ReadOnly valor_pi as Single = 3.1415
OP specifically asked in C#.
Puts, I went through it unnoticed uahuahu Thanks ;D
-1
If you want a property readonly make it have only the Get, for example:
public int Meuinteiroreadonly { get; }
This will cause this property to be defined only in the constructor of its class, which is the behavior of a readonly field.
This is different from having a private set, where any class method could change the value of the property and not just the constructor.
So public int Meuint{get;} is different from public int Meuint{get;set;}
If you want to readonly use the first option.
Q.S.: I know this post is old, but it may be that the answer still helps someone who might be looking for similar help. ;)
Browser other questions tagged c# .net property
You are not signed in. Login or sign up in order to post.
Note: It is not good practice to expose public papers - it is advisable to keep the field
readonly
private, and use a get-only public property to return the field.– dcastro
Concepts, concepts. If you use right immutability, why wouldn’t that be good practice? A self-contained property has exactly the same function as a public field. Encapsulation is a Design Pattern, not a Good Practice. The world doesn’t revolve around Object Orientation -- not all the time.
– André Leria
It’s not just about immutability. Today you compile an Assembly X that depends on the Assembly Y, and le a public field "Number" of Y. Tomorrow, you decide to add logic and change the field "Number" to a property "Number". The Assembly X will now crash.
– dcastro
Jon Skeet presented a million other reasons here. Breaks the Assembly, breaks the ability to use Reflection, can no longer use
ref
orout
, etc. The Fields must be (almost) always private.– dcastro
Good point, but it doesn’t fit with Read-Only, I’d say. If I were to use mutable values, I would surely expose a self-ownership in the place of a field.
– André Leria
Why not? You have a readonly field today, but tomorrow you might want to encapsulate the field reading with some extra logic, like
Logger.Log("O campo foi lido 1 vez"); return _numero;
. Then you will have to encapsulate the field in a property (get-only). Ai will break everything.– dcastro
This is a specific case. In most cases, changing the treatment of a property can cause undesirable changes in dependencies; Who know I don’t always want to log in the field, for example? The ideal would be to add a new get-only property that Loga and then returns the field.
– André Leria
@dcastro As a note, I think that in C# 6, read-only auto-properties are a good alternative to private fields. But unfortunately we are still at C# 5 at the time of this question, which explicitly refers to fields and keyword functionality
readonly
.– André Leria
The logger was just an example, but I only wanted to demonstrate that it is possible (and often probable) that Fields will be encapsulated in properties, readonly or not, for various reasons. And as such, we must program defensively and think ahead. Just to clarify: I agree with the rest of the post, the answer this' correct, and gave +1 ;)
– dcastro
@dcastro I also agree with yours that is winning from mine thanks to my upvote at the time of this comment xD I understand that we have to think about the future. I have only studied functional programming and seen that immutable fields are a quick approximation to immutable classes.
– André Leria