How do you give a C# Auto-Property a default value? I either use the constructor, or revert to the old syntax.
Using the Constructor:
class Person
{
public Person()
{
Name = "Default Name";
}
public string Name { get; set; }
}
Using normal property syntax (with a default value)
private string name = "Default Name";
public string Name
{
get
{
return name;
}
set
{
name = value;
}
}
Is there a better way?
Source: Tips4all, CCNA FINAL EXAM
To give auto implemented properties a default value, you'd have to do it in the constructor.
ReplyDeleteWhen you inline an initial value for a variable it will be done implicitly in the constructor anyway.
ReplyDeleteI would argue that this syntax is best practice:
class Person
{
public Person()
{
//do anything before variable assignment
//assign initial values
Name = "Default Name";
//do anything after variable assignment
}
public string Name { get; set; }
}
As this gives you more clear control of the order values are assigned.
DefaultValueAttribute ONLY work in the vs designer. It will not initialize the property to that value.
ReplyDeleteSometimes I use this, if I don't want it to be actually set and persisted in my db:
ReplyDeleteclass Person
{
private string _name;
public string Name
{
get
{
return string.IsNullOrEmpty(_name) ? "Default Name" : _name;
}
set { _name = value; }
}
}
Obviously if it's not a string then I might make the object nullable ( double?, int? ) and check if it's null, return a default, or return the value it's set to.
Then I can make a check in my repository to see if it's my default and not persist, or make a backdoor check in to see the true status of the backing value, before saving.
Hope that helps!
Though the intended use of the attribute is not to actually set the values of the properties, you can use reflection to always set them anyway...The unintended consequences are not clear to me at the moment (e.g. if some Microsoft coder set the meta tag incorrectly, but actually defaulted it to something else in the constructor could you override that?)
ReplyDeleteAnyway...
public class DefaultValuesTest
{
public DefaultValuesTest()
{
foreach (PropertyDescriptor property in TypeDescriptor.GetProperties(this))
{
DefaultValueAttribute myAttribute = (DefaultValueAttribute)property.Attributes[typeof(DefaultValueAttribute)];
if (myAttribute != null)
{
property.SetValue(this, myAttribute.Value);
}
}
}
public void DoTest()
{
var db = DefaultValueBool;
var ds = DefaultValueString;
var di = DefaultValueInt;
}
[System.ComponentModel.DefaultValue(true)]
public bool DefaultValueBool { get; set; }
[System.ComponentModel.DefaultValue("Good")]
public string DefaultValueString { get; set; }
[System.ComponentModel.DefaultValue(27)]
public int DefaultValueInt { get; set; }
}
little complete sample:
ReplyDeleteprivate bool bShowGroup ;
[Description("Show the group table"), Category("Sea"),DefaultValue(true)]
public bool ShowGroup
{
get { return bShowGroup; }
set { bShowGroup = value; }
}
class Person
ReplyDelete{
/// Gets/sets a value indicating whether auto
/// save of review layer is enabled or not
[ System.ComponentModel.DefaultValue(true)]
public bool AutoSaveReviewLayer { get; set; }
}
Have you tried using the DefaultValueAttribute or ShouldSerialize and Reset methods in conjunction with the constructor? I feel like one of these two methods is necessary if you're making a class that might show up on the designer surface or in a property grid.
ReplyDeletePersonally, I don't see the point of making it a property at all if you're not going to do anything at all beyond the auto-property. Just leave it as a field. The encapsulation benefit for these item are just red herrings, because there's nothing behind them to encapsulate. If you ever need to change the underlying implementation you're still free to refactor them as properties without breaking any dependent code.
ReplyDeleteHmm... maybe this will be the subject of it's own question later
class Person
ReplyDelete{
private string _name;
[DefaultValue(true)]
public string Name
{
get { return _name; }
set { _name = value; }
}
}