Can anyone clearly articulate when you use a field and when to use a property in class design?
Consider:
public string Name;
Or:
private string _Name;
public string Name
{
get { return _Name; }
set { _Name = value; }
}
I realize that the second method is more proper and flexible, so that's what I try to use, generally.
But then why do I see people use the first method? Are they just lazy, or is there some specific situation where it's the correct choice? Is it just a matter of preference?
Well in C# 3.0 you can actually write:
public string Name {get; set;}
Which allows you to be proper and lazy.
Generally speaking, with properties, you get proper encapsulation. You have the choice to allow setting a value, or getting it, or both. Using a public member, you don't have that option.
It's probably one-part preference, and one-part how your team decides to handle quick and dirty class definitions, but I would say, use properties for get/sets.
To answer
Can anyone clearly articulate when you use an attribute and when to use a property in class design?
You shouldn't ever use a public attribute. You should always use a property instead. It's safer and more flexible. That said, people will be lazy, and just use a public member. However, with C# 3.0 you can use a more terse syntax to define properties, which should satisfy your inner laziness.
Simply type prop and hit <tab> to expedite the laziness in adding a property.
Just some additional information to Alan's reply:
public string Name {get; set;}
is the same as
private string _Name;
public string Name{
get { return _Name; }
set { _Name = value; }
}
If you want to disallow the set function of Name, you can have
public string Name {get; private set;}
Properties are more maintainable than fields, you can encapsulate logic in your setters/getters, allowing you to hide the implementation.
They also make refactoring easier.
More information:
Property Usage Guidelines
Field Usage Guidelines
Using properties you can control it's security:
public string Foo { protected get; private set; }
Properties gives easy way to raise events:
public string Foo
{
get { return _foo; }
}
set
{
bool cancel = false;
if(BeforeEvent != null) // EventHandler<CancelEventArgs> BeforeEvent
{
CancelEventArgs e = new CancelEventArgs();
BeforeEvent(this, e);
cancel = e.Cancel;
}
if(!cancel)
{
_foo = value;
if(AfterEvent != null) // EventHandler<EventArgs> AfterEvent
{
AfterEvent(this, new EventArgs());
}
}
}
Also I often use code like this:
string Foo
{
set
{
IsFooSet = value != null;
}
}
bool IsFooSet
{
get { return _isFoo; }
set
{
_isFoo = value;
if(value) // some event raise or controls on form change
}
}
When you make the field public, you allow the user to do whatever they want to do to the field. They can assign unexpected values, invalid values, values that can cause overflow, etc.
With the property, you have control over whether to allow the setting of new values to the field, massaging the value before storing it, notifying interested parties about the change of the field's value, etc. And the same idea for returning value through the getter. For .NET framework from 2.0 up, you can set the accessor for the getter, setter. Say, you only want the user to only have read access to the field, then you make the getter public, but the setter private or protected.
In addition to the already-given reasons for preferring properties, there's also lots of cool stuff in System.ComponentModel to do with data binding and change notification that only works with properties, rather than fields. For example, look at the documentation around PropertyChangedHandler.
A property like defined above acts like a getter and setter. The only benefits of using a property is that you can treat it like a variable with access restriction.
public string Name { get; private set; }
This property can be accessed publicly, but can only be set privately. (You wouldn't want anyone changing your name with out your consent now would you! ;) )
Related
Usually I would build my field like this:
private string name;
public void setName(string name){
this.name = name;
}
public string getName(){
return name
}
that works perfectly when doing this: string myString = object.getName() or object.setName("Alex").
However, I thought I might give the inbuilt C# functions a try.
So I did this:
private string name { get; set; }
however, that won't work at all. When I try to access the field with object.name, I can't even access it due to private restriction.
Did I misunderstand something about these predefined get/sets?
If I had to mark every field as public, why should I even use getters or setters? I could access the field like in the snippet above without get and set?
You're mixing up way too many things - you might want to read a book on C#, really. It usually takes some time to get rid of some of the preconceptions from your old programming language - but you really do want to do that; even Java and C# are incredibly different when you go beyond the surface appearance.
First, nothing is forcing you to use auto-properties. If you want to use properties while keeping your manual backing fields, you can simply use this:
private string name;
public string Name { get { return name; } set { name = value; } }
If you do want to use auto-properties, you have to understand that the backing field is hidden - you're only declaring the property; and you want that property to be public (though you can also use accessibility modifiers on the individual get/set "methods", e.g. private set). But the field is never accessible - it's "always" behind the property.
To mirror your original code, this is what you want:
public string Name { get; set; }
Only if you ever need to move away from using auto-properties (that is, you need to add some logic to either the getter or the setter), you will have to reintroduce the manual backing field, and stop using auto-properties - see the first code sample in my answer.
Did I misunderstand something about these predefined get/sets?
Yes, you did. The property itself has to be public. If you're using auto-properties, then you can't do any validation since the backing field is compiler generated. If you want to actually do something with the value before, you can use a property with a backing field:
private string name;
public string Name
{
get { return name; }
set
{
if (string.IsNullOrEmpty(name))
throw new ArgumentException("name cannot be null");
name = value
}
}
Because this:
public string Name { get; set; }
Generated a backing field like this:
[DebuggerBrowsable(DebuggerBrowsableState.Never), CompilerGenerated]
private string <Name>k__BackingField;
public string Name
{
[CompilerGenerated]
get
{
return this.<Name>k__BackingField;
}
[CompilerGenerated]
set
{
this.<Name>k__BackingField = value;
}
}
Just do
public string Name { get; set; }
That compiles down to a private field with an unspeakable name, and a public property. That public property has a public get method and a public set method.
Seems to be exactly what you want.
Alternatively, use
public string Name { get; private set; }
Your get method will be public as before, but the set method will be private then.
As of C# 6 (Visual Studio 2015), you can even do
public string Name { get; }
In that case, there is no set method, not even a private one, but you can assign to the underlying field through the property in the constructor.
Did I misunderstand something about these predefined get/sets?
Yes, a bit.
If I had to mark every field as public, why should I even use getters or setters? I could access the field like in the snippet above without get and set?
This is the part that you're missing. The syntax you are talking about it called an auto-implemented property. That is, when you write:
public string Name { get; set; }
the C# compiler generates a private field, getter, and setter behind the scenes for you. You can see them if you look at the metadata for your class, and get access to them via reflection. They have the exact same names as the getter or setter you would write yourself (typically get_Name and set_Name). The only difference is, you didn't have to write them.
The reason to do this is because most getter/setter pairs only exist to add a layer of abstraction over a private field, and consist of a single return name or name = value line of code. If that's all you want, you may as well let the compiler write it for you.
However, if you ever needed something more complex, you can manually implement the getter and setter yourself, and callers won't know the difference. In other words, if you change:
public string Name { get; set; }
to
private string name;
public string Name
{
get
{
return name;
}
set
{
name = value;
RecalculateSomeStuff();
}
}
then the metadata for your class is identical. Anyone using your class does not have to even be recompiled to pick up the new setter, because as far as the callers are concerned, they're still called set_Name directly.
What the others want to tell you is that you should deferentiate between fields (privates) and properties (public) (is not a rule but a convention)
private string name;
public string Name{ get; set;}
// you can acces to the property:
var objectName = YourObject.Name
// and set the value of your property:
YourObject.Name = "whatever"
First of all the equivalent of your code is
private string _name;
public string Name
{
get {return _name;}
set { _name = value; }
}
OR simply
public string Name { get; set; }
To define the accessibility level of the "Name" field, you put the access modifiers (public, protected, etc.) before get or set
Example
//Read only properties
public string Name
{
get {return _name;}
private set { _name = value; }
}
To have more details and see difference between public fieal and public property see Difference between Auto - Implemented Properties and normal public member
PS :
To write this in Visual studio you can use snippet, type prop keyword then tab key or propfull and press tab key. press tab key our shift+tab to navigate between highlighted fields
In C#, can you use a property without a field?
Edit for clarification:
private string _name;
public string Name
{
get { return _name; }
set { _name value; }
}
It seem's like they are always paired, is there a circumstance where we don't use the field at all?
All properties must have a field, assuming they are simple properties to store a value (*). However, the language (as of version 3.0) offers a way to declare the field implicitly. For example:
public int Value { get; set; }
That would declare a property named Value with an implicit field backing it and the getter and setter both public. You can include an accessibility keyword on either the getter or setter to restrict access to the property. For example:
public int Value { get; private set; }
In this case, only the owning type may call the setter, but any class can call the getter.
The next version of C# will have additional features for dealing with these "automatic properties", allowing you to provide a concise initialization syntax for them. For now, you have to initialize them in a constructor.
EDIT: based on your edited question, it seems worthwhile to address this specific question: "is there a circumstance where we don't use the field at all?"
The answer to that is, it's not common for no field to be involved at all. But it is possible, and it's not uncommon for a property to not use a field as storage for the property. For example, imagine a Rectangle object with an Area property:
class Rectangle
{
public double Width { get; private set; }
public double Height { get; private set; }
public double Area { get { return Width * Height; } }
}
Obviously there are fields involved (two of them), but there is not a field specifically dedicated to the Area property.
Another example would be where the property delegates. For example, in a WinForms Form subclass, it's common to expose specific control values via a property:
class MyForm : Form
{
public string EditText
{
get { return textBox1.Text; }
set { textBox1.Text = value; }
}
}
Again, the textBox1 field is being used here. But it actually represents something other than the property itself. The property is using a member of the object that field references.
I hope that clarifies the relationship between fields and properties adequately for you. Please feel free to ask for further clarifications if needed.
(*) Note that the only real rule for properties is that they have at least one of the getter or setter, and those methods can do whatever you want. I assume we are talking about simple value-based properties here.
A property is not required to have a field
public string Version
{
get
{
return "1.3.Awesome";
}
}
If you're asking what I think you are, the answer is yes, you just put get; set; inside the property declaration. C# encapsulates a variable for you.
EDIT: example
//no need for field declaration
public string Name
{
get;
set;
}
New to C#, and I understand that encapsulation is just a way of "protecting data". But I am still unclear. I thought that the point of get and set accessors were to add tests within those methods to check to see if parameters meet certain criteria, before allowing an external function to get and set anything, like this:
private string myName;
public string MyName;// this is a property, speical to c#, which sets the backing field.
private string myName = "mary";// the backing field.
public string MyName // this is a property, which sets/gets the backing field.
{
get
{
return myName;
}
set
{
if (value != "Silly Woman"){
myName = value;
}
}
}
But I've been seeing code in c# which just looks like this:
public string MyName { get; set; }
Why would you just have a get and set with nothing in there, - isn't that the same as just declaring your private backing field public? If you can just get and set it from outside, why wouldn't you just do it directly?
Indeed, creating an auto-property as follows:
public string Name { get; set; }
is identical to building a property backed by a field:
private string _name;
public string Name {
get { return _name; }
set { _name = value; }
}
The point of these properties is not to hide data. As you observed, they don't do this. Instead, these properties can do other stuff instead of just working with a field:
public string Name {
get { return _name; }
set { if (value == null) throw new Exception("GTFO!"); _name = value; }
}
Another thing is, you can make properties virtual:
public virtual string Name { get; set; }
which, if overridden, can provide different results and behaviours in a derived class.
By using public string MyName { get; set; }, you leave an ability to change its logic later without the need to recompile/change other code that uses your property.
For example, if you are making a library and v1 uses a field and v2 uses a property, applications that work with v1 will not work with v2 without recompilation (and, potentially, code changes if they are written in some .NET language that has different syntax for accessing fields).
Another important difference is in serialization scenarios -- a lot of them do not support fields. Also any interface that requires a property can not be implemented without using one, but depending on interface it may not be required to do any additional checks/logic in it.
It makes it easier to add logic later. If you have a class that has a public field that you want to change to a property, you have to recompile everything that uses your class. That's a key point that I didn't understand initially.
If you have a class:
public class MyClass
{
public string MyString;
}
You could access the value like this:
var myClass = new MyClass();
string s = myClass.MyString;
Now change that to a property:
public class MyClass
{
public string MyString { get; set; }
}
How is it accessed? The exact same way:
var myClass = new MyClass();
string s = myClass.MyString;
So no big deal, right? Well, actually....
Properties are actually compiled into getter and setter methods:
get_MyString() and set_MyString(string value)
So the two methods do produce different compiled code. Now if all your code that uses this class is in the same project, is not as big a deal, because it will all be compiled together. But if you have an API library that you've distributed, it can be a much bigger deal to update.
Because it is easier to change the Code if you want to add the checks/tests later on.
Especially if you have many inheritance and many classes in your code it is very hard to change the implementation from a public variable to a public Property.
Moreover you can add to the get and set within the property different attributes, e.g. if you are using reflection. The get and set of the property are internally different methods. If you have just a public variable /field it is not possible to added different properties to the different access ways.
Yeah, but you can easily change it to:
public string MyName { get; private set; }
Plus, properties are used in other scenarios, like DataContracts and Serialization... so, this is a nice feature... (Mostly, syntactic sugar. I think) EDIT: I take that back.. you can apply virtual to it, so it's not the same
Is there a way to do something like this in C#:
public class Class2 {
public string PropertyName1 { get
{
return this; //i mean "PropertyName1"
}
set {
this = value;
DoAdditionalFunction();
}
}
Because I need to call additional function in the "set" I need to have an extra private field like
private string _propertyName1;
public string PropertyName1 { get
{
return _propertyName1;
}
set {
_propertyName1= value;
DoAdditionalFunction();
}
I don't want to use additional property like _propertyName1. Is there a way to accomplish this or any best practices?
No - if you need any behaviour other than the most trivial "set a field, return the field value", you need to write "full" properties. Automatically implemented properties are only a shorthand for trivial properties.
Note that you haven't really got an "extra" private field, in terms of the actual contents of an object - it's just that you're explicitly declaring the private field instead of letting the compiler do it for you as part of the automatically implemented property.
(It's not clear what your first property is trying to do - setting this in a class is invalid, and you can't return this from a property of type string unless you've got a conversion to string...)
In C# do properties need to reference private member variables, or can I just declare the properties and use them directly in the class code?
If the former is the best practice, then does that rule out using C# property short-hand? I.e.
public string FirstName { get; set; }
Properties, when implemented like this:
public string FirstName { get; set; }
Automatically create a private member variable (the compiler does this for you), so you don't have to worry about it. This will behave exactly the same as if you do:
private string firstName;
public string FirstName {
get { return firstName; }
set { firstName = value; }
}
There is no reason not to use the automatic properties ( { get; set; } ). The provide the same advantages as making your own private member variable.
In addition, if you later decide you need to do extra processing (for example, if you decide to implement INotifyPropertyChanged in your property setter), you can add this without changing your public API, but putting a backing field in manually.
You don't need properties to access private fields but in general it is considered best practice.
And you can use auto-properties (short hand) untill you need to add more functionality to a property, like validation. Changing it to a 'real' property is always a non-breaking change.
Properties created like this
public String Caption{ get; set; }
this will be compiled as
[CompilerGenerated]
private string <Caption>k__BackingField;
public string Caption
{
[CompilerGenerated]
get
{
return this.<Caption>k__BackingField;
}
[CompilerGenerated]
set
{
this.<Caption>k__BackingField = value;
}
}
The above code is extracted after compilation using reflector tool.
They do not need to reference private member variables. You can use them directly in the class.
Properties do not need to reference private member variables. It is best practice, though, to have them do so. You can think of properties as methods if it makes it easier to understand. You can run code inside of them. You can return whatever you want. You can call methods and use private member variables. You can even simply return a constant.
I use private member variables in almost all cases. It allows me to create a readonly property, or to provide some rules to those outside my class of getting or setting properties that my class doesn't have to follow.
To add on to Reed's answer, inside of your code (within the class itself) the member functions should adhere to this and actually use the Property rather then the actual private member. For instance if you had this:
public string FirstName { get; set; }
And you had a strange method called public char GetFirstLetter() that returned the first letter in a person's first name you'd want to do it like this:
public char GetFirstLetter()
{
return FirstName[0];
}
Instead of actually using your private variable. When you set a property a programmer may have written code to set it in a particular manner. So it only makes sense to simply use that property within your class methods.
C# can reference private variables as in:
public class A
{
private string _b;
public string B
{
get { return _b; }
set { _b = value; }
}
}
The get;set; designation is automatic properties which when compiled will generate the private variable for you, as a way to make it easy to setup your code.
Using properties is the best way to provide a method of control and security to the attributes in a class, always keep the attributes private if possible.
if you use like
public string FirstName { get; set; }
compiler will automatically adds getters and setters for this property automatically.it not a bad practice.
Here is the proof
if you declare
private string firstName;
public string FirstName
{
get { return firstName; }
set { firstName = value; }
}
like this also compiler will takes it as
so its not ruled out... :)