So after the availability of automatic implementation, and initialization of a property, do I even need a field for my property?
This seems much cleaner:
class A {
public int X {
get;set;
} = 1;
}
Than this:
class A {
int x = 1;
public int X {
get {
return x;
}
set {
x = value;
}
}
}
In the first case, the compiler is already providing a backing field - it's just implicit (and it's given a name that you can't refer to in code). Note that there has to be a backing field in the generated code, as a property itself is really just a pair of methods with some metadata linking them - the presence of a property does not add any state to the object. State is only stored in fields.
It's even cleaner when written on one line - I'd usually see this as:
class A
{
public int X { get; set; } = 1;
}
You dont need a backing field in this situation, but if you want to manipulate the Property with e.g a OnPropertyChanged() then you need to have a backing field
public int X {
get {
return x;
}
set {
x = value;
OnPropertyChanged()
}
}
Related
Read only properties can be assigned in a constructor. But when I try to explicitly implement get method, compiler shows an error (Property cannot be assigned to -- it is read only.) Can I implement getter or it's supposed to be without implementation?
public class PersonalIncome
{
private decimal _anualRate;
public decimal AnualRate
{
get { return _anualRate != 0 ? _anualRate : 40_000; }
}
public PersonalIncome(decimal paymentRate)
{
switch (paymentRate)
{
case var rate when (rate > 300):
AnualRate = rate; // **Property can not be assigned to -- it is read only.**
break;
default:
break;
}
}
}
You can implement the getter, but then you can only assign values to the backing field directly:
_anualRate = rate;
Once you decide against using the convenience of the auto-property, you have to do everything by yourself.
Your class could be rewritten like this:
public class PersonalIncome
{
public decimal AnualRate { get; private set; }
public PersonalIncome(decimal paymentRate)
{
AnualRate = paymentRate > 300 ? paymentRate : 40_000;
}
}
You refer to a property with a readonly backing-field.
That´s exactly what the compiler also generates from C#6 upwards when using an auto-implemented property with a default-value:
int MyProperty { get; } = -1;
This will be translated to the following:
readonly int _myProperty = -1;
int MyProperty { get { return this._myProperty; } }
Now the compiler replaces every call to your property by the backing-field. However this only works for auto-properties that do not have a body defined. In your case you already have one, which is why the compiler can´t replace that one. As a property itself is nothing but a get- and a set-method, what you want to do is the following, which is obvious non-sense:
int get_MyProperty() { return this._MyProperty; }
...
this.get_MyProperty() = 1;
The reason this works for an auto-property is that the compiler knows how to replace the call to the property. However suppose your own getter was more complex:
get
{
DoSomething();
return this._myProperty + 5;
}
Now the compiler can´t replace the call to the property.
So the only way to have your own get-implementation tigether with a property which is get-only, is to use the backing-field:
this._myProperty = 1;
Lets have a simple class with an int property
public class SimpleClass {
public int myInt { get; set; }// for having a property and not "public int myInt;", see Jon Skeet remark
}
I instanciate it twice assigning myInt or not
assignedObject = new SimpleClass() { myInt=0};
notAssignedObject = new SimpleClass();
Now by reflection, I query the value of myInt in each case using
Object value;
value=assignedObject.GetType().GetProperties().Where(o=>o.Name.Equals("myInt")).First().GetValue(assignedObject,null)
value=notAssignedObject.GetType().GetProperties().Where(o=>o.Name.Equals("myInt")).First().GetValue(notAssignedObject,null)
I am getting twice 0 for myInt, but I need to be able to differenciate them. How?
Unless you have code to specifically remember the difference between a property which has been initialized with its default value, and one which hasn't been set at all, you can't tell the difference. I have two suggestions, however:
You could make it an int? property, and then check whether the value is null. Of course, it's possible for it to be set to null explicitly, unless you prohibit that, but it may be good enough.
You could keep a separate bool value to know whether or not it's been set explicitly, and just set it in your property setter, along with the value.
Sample code for the second option:
public class SimpleClass
{
private int value;
private bool valueSet;
public int Value
{
get { return value; }
set
{
this.value = value;
this.valueSet = true;
}
}
public bool ValueSet { get { return valueSet; } }
}
I understand how to create a getters and setters
public myClass
{
public int myVal { get; set; }
// more stuff
}
but I don't understand how to call it later on.
public myOtherClass
{
public myOtherClass()
{
myClass localMyClass = new myClass();
localMyClass.???set??? = 42;
// Intelisense doesn't seem to give any obvious options after I enter
// the period.
}
}
How should I set the value of myVal in localMyClass?
localMyClass.myVal = 42;
Getters and setters let you treat the values like public properties. The difference is, you can do whatever you want inside the functions that do the getting and setting.
Examples:
store other variables
private int _myVal, myOtherVal;
public int MyVal { get; set { _myVal = value; myOtherVal++; } }
make numbers up / return constants
public int MyVal { get { return 99; } set; }
throw away the setter
private int _myVal;
public int MyVal { get { return _myVal; } set { ; } }
In each of these cases, the user will feel like it's just a public data member, and simply type
localMyClass.myVal = 42;
int i = localMyClass.myVal;
The gettors and settors let you make an implementation of your own. Also, as Hogan says, "There are a number of libraries and add-ons [e.g. MVC.NET] that require you to use getter and setter functions" - even if it's for the trivial {get; set;} case.
Set:
localMyClass.myVal = 42
Get:
int variable = localMyClass.myVal;
From the outside, the syntax for accessing getters and setters is indistinguishable from that of accessing variables. Assignments translate into calls of setters, while plain expression uses translate into calls of getters.
In intellisense, the list of getters and setters should open upon placing a dot . after the variable name. Properties should have blue markers to the left of them (as opposed to magenta-colored markers to the left of methods).
You want this
localMyClass.myVal = 42;
to call the setter
and this
varName = localMyClass.myVal;
to call the getter.
Get: var tmp = localMyClass.myVal;
Set: localMyClass.myVal = 2;
Well I am learning properties and I am not sure about the following:
class X
{
private int y;
public X(int number)
{
this.Y=number; // assign to property
OR
this.y=number //?
}
public int Y;
{
get; set;
}
}
When you use auto-properties (get; set; or a variant thereof), the backing variable is not accessible. Those can, for the most part, be treated as simple variables, especially internally.
If you need to perform custom validation or mutation logic in the mutator, or otherwise have the need for an explicit backing variable, you cannot use auto-properties but have to write stub get and set methods yourself.
They do different things; I would do Y = number; and remove the (unused) field y. In an automatically implemented property, the compiler creates it's own field (with a horrible name that you can't see in C#) - you don't need to provide your own field. So:
class X
{
public X(int y)
{
Y = y;
}
public int Y { get; set; }
}
Other points: changed number to y to be clearer to the caller, and also you don't need this. since it isn't ambiguous (field vs parameter, etc).
Only assign to a field (private int y) inside the property representing that field (public int Y {get;set}). No where else in the class should the backing field be assigned to directly. Always do it through the property... yes even in the constructor. It follows from the do not repeat yourself (DRY) principle.
This is recommended because whenever in future you want to associate some behavior to be triggered by that assignment you only have a single place (the set accessor) to write code into.... not all the places where the field is assigned to !!
class X
{
private int y; //not strictly necessary but good for documentation
public X(int number)
{
Y = number;
}
public int Y { get; set; }
}
When you use autoproperties like:
public int Y;
{
get; set;
}
You don"t need a private property because it's autogenerated. so you class will be:
class X
{
public X(int number)
{
Y = number;
}
public int Y // no semicolon here, comment added for edit length
{
get; set;
}
}
Hope this helps
You have two choices :
class X
{
private int y;
public int Y
{
get { return y; }
set { y = value; }
}
public X(int number)
{
Y = number;
//equivalent to
y = number;
// but you should use the public property setter instead of the private field
}
}
or with auto-properties , it's even simpler :
class X
{
private int y;
public int Y
{
get; set;
}
public X(int number)
{
Y = number;
}
}
When not using auto-properties I always use the Property setter because there can or will be code in the setter that I need to be executed. This code could be a domain check or the raising of an event such as PropertyChanged.
A point I usually try to make about accessing backing variables:
Sometimes the public getter might contain complicated data validation,raising property changed events or some other complex code that is triggered when some external code changes it's value.
When changing that value internally (from inside the class), it might be a valid point to use the backing variable directly if your intention is to skip all the validation and events from the public setter. It's like saying "i'm the class instance, I know what I'm doing". This way the public setter is acting like a guard-dog, sanitizing external input, while I can still set the property internally to whatever I need.
class X
{
private int y; //not strictly necessary but good for documentation
public X(int number)
{
y = GetYValueFromDB(); //we assume the value from DB is already valid
}
public int Y {
get{ return y};
set {
if (ComplexValidation(value)
{
RaiseOnYPropertyChanged();
y = value;
}
}
}
Suppose I have:
public class Bob
{
public int Value { get; set; }
}
I want to pass the Value member as an out parameter like
Int32.TryParse("123", out bob.Value);
but I get a compilation error, "'out' argument is not classified as a variable." Is there any way to achieve this, or am I going to have to extract a variable, à la:
int value;
Int32.TryParse("123", out value);
bob.Value = value;
You'd have to explicitly use a field and "normal" property instead of an auto-implemented property:
public class Bob
{
private int value;
public int Value
{
get { return value; }
set { this.value = value; }
}
}
Then you can pass the field as an out parameter:
Int32.TryParse("123", out bob.value);
But of course, that will only work within the same class, as the field is private (and should be!).
Properties just don't let you do this. Even in VB where you can pass a property by reference or use it as an out parameter, there's basically an extra temporary variable.
If you didn't care about the return value of TryParse, you could always write your own helper method:
static int ParseOrDefault(string text)
{
int tmp;
int.TryParse(text, out tmp);
return tmp;
}
Then use:
bob.Value = Int32Helper.ParseOrDefault("123");
That way you can use a single temporary variable even if you need to do this in multiple places.
You can achieve that, but not with a property.
public class Bob {
public int Value { get; set; } // This is a property
public int AnotherValue; // This is a field
}
You cannot use out on Value, but you can on AnotherValue.
This will work
Int32.TryParse("123", out bob.AnotherValue);
But, common guidelines tells you not to make a class field public. So you should use the temporary variable approach.