Yes, of course if property has some logic which checks the set value or
> count the get value from something then yes, you should use the property,
> but why to use it when it contains only eg get {return this.value} ? and one
> more thing about your message:
>
In general, I find it good practice to use Get Properties (where they exist)
as a default. They might only say
return _abc;
but then they might say
if(x || y) { _abc = _service.Refresh(); } else { _abc = service.Load(_id); }
return _abc;
And they also might *change* from example 1 to example 2. If you
consistently use the Get Property, if the logic changes, your code will
still work. Remember - another developer might change the logic contained in
the property but NOT check the the rest of the code for where it is used.
So, elsewhere in the class, if you say
int a = _abc;
Then your code breaks.
But if you say
int a = PropertyABC;
Then your code continues working. It is a safety net - win/win, if you will.
If the property only returns _abc, then the compiler will inline this to int
a = _abc anyway, so there is no performance hit.
> -If the property is read-only, then there is a reason for this (i.e. logic
> already exists internally to set the value of the underlying field)
> and that logic is? Sorry, but I don't quite understand that, coding classes
> always means to create some its own logic and how does look a logic to set
> the variable? Maybe this.variable = value? Oh no, sry, you can't, you must
> use property for this... but property is read-only? Damn, so there already
> MUST be some logic that sets it...
> --that was test of some irony, don't get it personally ;-)
>
>
I don't really get what you mean here.
In the case of a read-only variable, you want to prevent *external* classes
from changing the value of the field. Therefore, you do something like
public string Name
{
get
{
return _name;
}
private set
{
_name = value;
}
}
And you use the property as normal.
