This question already has answers here:
What is the difference between a field and a property?
(33 answers)
Closed 9 months ago.
Similar questions has been asked a lot but it still doesn't make sense to me as I am beginner.
here is the link
What is the { get; set; } syntax in C#?
As that answer states
(I will be using age instead of "name" to avoid confusion)
Case 1
public class Genre
{
public int Age { get; set; }
}
and
Case 2:
public class Genre
{
private int age;
public int Age
{
get
{
return this.age;
}
set
{
this.age = value;
}
}
}
Both are the same things.
So for Case 1, where is private age variable?
Does it get declared in the backend.
If Yes, then what name will be assign to it?
Surely not (Age => age) Right?
It feels like,
public int Age { get; set; }
// is same thing as
public int Age;
Now, people have mentioned that one is property another is field. But they both can be used in similar way. So what is the difference on application level?
Can you please give me an example?
It feels like,
public int Age { get; set; }
is same thing as
public int Age;
Absolutely not, the first one is two functions, the setter and the getter, while the second one is a field, an integer. As a physical example of the difference, you can do ref Age in the second example, since it has a physical location in memory, but not in the first example, since it's just functions, it's code.
So for Case 1, where is private age variable? Does it get declared in the backend. If Yes, then what name will be assign to it?
Yeah, it gets generated for you by the compiler with a name you can't declare in C# because it contains invalid characters (that are valid in .Net in general). The actual name doesn't matter, just know that you can't possibly use it or collide with it.
The main difference between the two members in your last code snippet is encapsulation
See the "Encapsulation" part on this page:
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/oop
Hiding the internal state and functionality of an object and only allowing access through a public set of functions.
You asked about what private field gets generated if you use an automatic property. In fact the compiler will generate a private backing field usually called something like k__BackingField or similar.
For example, I created a basic class as follows:
public class Dog
{
public string Name { get; set; }
}
This definitely creates a field in the background, and I can find out by using ILSpy to decompile it and we see the following:
Notice the Name property is there as you'd expect, with its getter and setter. But notice also the k__BackingField.
When we inspect it, it is comprised of the following code:
[CompilerGenerated]
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private string <Name>k__BackingField;
So we can see that there is definitely a private field in the background being generated for the property. We can also confirm that it actually uses that field by inspecting the get_Name getter on the Name property:
[CompilerGenerated]
{
return <Name>k__BackingField;
}
The getter for the Name property indeed returns the private field that was compiler generated for us.
I think what you're stuck on is why we would do this. Basically, if you simply have a public field on a class, you're giving permission for all-and-any other classes to set and get that field without any kind of checks or balances or rules about what goes on when setting or retrieving that value. For small applications that aren't very complex, this won't create an issue for you. But in the future when you're writing bigger applications or libraries, when you want to guarantee certain functionality behaves the same way all the time, this best practice will be necessary.
There is no difference when you use them as simple variables but using a variable as property gives you the ability to perform a check or create an event handler. For example:
private int _onetoten;
public int OneToTen
{
get => _onetoten;
set
{
if ((value > 0) && (value < 11))
{
_onetoten = value;
}
}
}
Related
This question already has answers here:
Should I use public properties and private fields or public fields for data?
(13 answers)
Closed 7 years ago.
Just want to make sure.
public class Product
{
private decimal unitPrice;
public int Id { get; set; }
public string Code { get; set; }
public string Name { get; set; }
//private string code;
public decimal Unitprice
{
get
{
return unitPrice;
}
set
{
if (value >=0)
unitPrice = value;
}
}
}
Why we would have to make private variable to unitPrice to return the value to UnitPrice, does it written for some reasons ?
You dont make it private just to return the value for it. private is one of the access modifier here. They are used to limit the scope of the access/usage of that particular variable in your code.
private here means that unitPrice is currently accessible or can be used by this particular class only. No other outside assembly can use this variable.
If you want to access a variable outside in other areas, you can opt to make it public.
Hope this clears it.
From design perspective the unit price property is exactly the same as the other properties but because there is a constraint on it.
if (value >=0)
only positive prices are valid, you have no other option than to foresee a private variable whereon the property is based.
In earlier versions of .NET we could not do something like this :
public int Id { get; set; }
And had to write it out in full all the time. The notation above is more handy and it makes the code clearer too. It used to be like this :
private int _id;
public int Id{
get{ return _id;}
set{ _id = value;}
}
Yes, get and set properties are useful when you want to have some control over variable. Consider the following case.
If you specify the variable as private you want no one to be able to access your variable.
But if you want others to be able to access your private variable but you dont want others to change it. In this case you can use Properties
public class Product
{
private decimal price;
public decimal Price{get{ return price;}}
}
now others have access to the price but they cant change it
In your case you are allowing others both to get and set your unitprice, which is equal to giving unitprice public access. However you are allowing on one condition that the unitprice should be set to 0. So C# properties are perfect match for this scenario.
Hope this helps!!
The public property UnitPrice is exposed to other classes to be read or modified. But being a property allows your class a degree of control over the value - you can validate any change for instance. Also, internally you can completely change how the value is obtained and modified without changing the contract of the class. So in other words, you would be able to make such changes without affect any consumers.
The backing field unitPrice is purely an implementation detail, it is internal state that is encapsulated by the class. Exposing this field means you lose any and all chance to modify the derivation of the value and you have no entry point for validating changes to the value. Properties may seem pointless abstraction at first but they will help make your code more maintainable as changes can be more easily confined to single classes.
The get and set blocks are purely syntactic sugar and under the covers the compiler creates two methods called get_UnitPrice() and set_UnitPrice(x) that are used for read/write operations on the property. You could just use similar methods but properties are more readable and designed to be a low cost way of interacting with class state and methods are for providing behaviour.
This question already has answers here:
What is the purpose of the "get" and "set" properties in C#
(7 answers)
Closed 8 years ago.
I'm an aspiring student who in future aims to pursue a career in computer science. Ive been reading documentation for quite a bit now, and i understand fundamentals of OOP, But im wondering exactly how the {Get ; Set;} Methods are used in c#. Thanks in advance.
E.G.
public class Car
{
public Name { get; set; }
}
This public string Name { get; set; } is called an auto implemented property. The compiler will create a private backing field that will hold the value we will set using this property. Furthermore, it will create two methods, one for the set (setting the value) and one for the get (getting the value) of this value. You could consider that set is an assignment and get is a read. So when we say that we set a value actually we mean we assign a value to a variable. While when we say that we get a value actually we mean that we read the value that is stored in a variable.
Furthermore, this public string Name { get; set; } is equivalent to the following:
private string name;
public string Name
{
get { return name; }
set { name = value; }
}
Comparing one another the first one does the same job with fewer lines of code. However, in both cases C# compiler will create as I stated above one method for setting the value and one method for getting the value. The main difference, it is that in the second case, the creation of backing field isn't needed.
Update
In order to be more clear the above , I created a console application, in which I added a class called Customer with the following definition:
class Customer
{
public string Name { get; set; }
}
I run my fantastic application and then I looked at the MSIL code that had been created by the C#.
I created the above using a free .net disassembler, called Ildasm.exe (IL Disassembler). This tool as it's name implies shows the IL code C# compilers creates, when we build one application. A good tutorial about this tool can be found here.
As you notice the type Customer is compiled to a class that has a backing field and two methods, get_Name and the set_Name. These have been created automatically by the C# compiler.
I don't program in C#, but get and set methods work the same way in most OOP languages. It has to do with the encapsulation concept in Object Oriented Programming. You declare a data member of a class private, and then access it using a get method, and change it using a set method. This hides the actual implementation of these methods from the client/user, so it hides the data.
Here is a simple Java example:
public class SomeClass {
private int data;
public int getData() {
return data;
}
public void setData(int newValue) {
data = newValue; // Hidden from the user
}
}
I was trying to help my friend to understand things such as fields and properties, and getters/setters. He then used properties without a private field, and told me it worked. I never even knew this was possible and can't seem to find too much about it online.
As an example:
public int Number { get; set; }
Instead of:
private int number;
public int Number
{
get { return number; }
set { number = value; }
}
It seems to work (as far I can see), but now I have the following questions:
What is happening behind the scenes?
What way is prefered?
Any pros/cons?
EDIT:
I always thought { get; set; } was the same as get { return x; } set { x = value; }. Oh well, good that I now know it. The question however remains the same. Is one considered better than the other? Pros/Cons?
In the first case the compiler is automatically creating a private field as the backing store for the property, giving it a name not accessible in user code, and creating methods to get and set its value.
In you're code you're taking the time to do it explicitly, and also creating a valid identifier in the scope of the class for that backing field, unlike the previous example.
This question already has answers here:
Difference between Property and Field in C# 3.0+
(10 answers)
Closed 9 years ago.
why to use accessors in c#.net while we can use simple assignment like
public string name = "Haymen";
instead of doing this:
public string Name
{
get
{
return name;
}
set
{
name = value;
}
}
and how this property gonna set or return something since it don't have any way to set anything apparently ?
public class Movie
{
public int ID { get; set; }
}
Skeet has ยป an article about just that! Your case is covered by automatic properties, so you don't have all the writing work.
It depends on what your trying to do, you use accessors for a variety of reasons, one of which is to ensure that class properties are kept private and can only be directly manipulated internally.
An example :-
private int _myAge {get; set;}
public int MyAge
{
get
{
if(_myAge == null)
{
_myAge == GetMyAge();
}
return _myAge;
}
}
Use
public string name = "Haymen";
If you know for sure you will never need to debug the access to that variable (i.e. set a breakpoint when somebody reads/writes it).
If you know changing it will never effect the internal state of your object (i.e. side effect that you depend on or expect).
You want to have less lines to look at and you have met the above.
You want a "data only class" for XML Serialization and you don't want to create a lot of code to do the conversion for private methods (at least as of C# 3.5).
NOTE That being said, in general, you should not be exposing fields as public members. See here.
I learned c# recently, so when I learned to write properties, I was taught to do it like this:
public string Name { get; set; }
Auto properties are great! But now I'm trying to do something a little more complicated, so I need to write a custom pair of accessors.
private string _Name;
public string Name {
get { return _Name; }
set { _Name = value }
}
I know the compiler makes a private instance variable down in it's murky depths when one uses autos, but I'm spoiled and don't want that private variable sitting around looking pointless.
Is there a way to use custom accessors without a private variable?
Properties don't need backing variables (fields) at all. While they can be used for encapsulating simple fields you can also use them to access other data.
public Decimal GrandTotal { get { return FreightTotal + TaxTotal + LineTotal; } }
or
public string SomeStatus { get { return SomeMethodCall(); } }
If the goal is to simply encapsulate some field with a property you would need some sort of backing field if you are not using automatic properties.
The answer is No, you cannot do that.
It is because of recursion. (See line numbers 9 and 7):
Line 1 : public string Name
Line 2 : {
Line 3 : get
Line 4 : {
Line 5 : return FirstName + " " + LastName;
Line 6 : }
Line 7 : set
Line 8 : {
Line 9 : Name = value; // <-- Goes back to Line 7
Line 10 : }
Line 11 : }
No, I'm afraid not. The compiler is smart enough to make this happen for you on auto-generated properties, but with standard properties I imagine the logic behind something like that would end up getting in the way and doing more harm than good.
For example, what if I create a property like this...
public int SomeValue
{
get
{
return 0;
}
}
Would the compiler (with the feature you're looking for) create a backing private variable? Why? It doesn't need one.
Additionally, if the private value isn't created until compilation time, what are you going to reference in your code:
public string Name {
get { return _Name; }
set { _Name = value }
}
What is _Name? What if you have another value somewhere else called _Name? Then what would the compiler call the backing value for this property? What if I need two backing values? Would the compiler be smart enough for that?
public string Name
{
get
{
return string.Format("{0} {1}", _FirstName, _LastName);
}
set
{
// some parsing magic
}
}
It's been asked before, but I imagine the answer is going to continue to be "no" for the foreseeable future.
An auto-property is syntactic shorthand for simple direct member access. (And I imagine one of its driving forces was simply to try to get people to stop creating public values directly.) Properties can grow in complexity well beyond that very easily and I personally wouldn't want the compiler trying to figure out what I can easily just tell it to do.
I know this is an old question, but there is at least one other option here. I'm doing something similar to the below for my own app.
This might not exactly be for your use case, but it shows that a custom getter and setter can be used without a private instance variable. In this case, the getter and setter are shortcut or helper methods to access the Name property of the User for the Account.
We can let the value be set by doing Account.AccountUser.Name = "John Doe";, but sometimes that seems a bit clunky and it works against the idea of separation of concerns. Do we want someone using the Account class to know there's a User imbedded in it? If for some reason we don't, we now have a way to still update the User.Name even if we make AccountUser private.
In this case, AccountUser is public, but it doesn't have to be. When it's private, a Json or XML conversion utility (such as Newtonsoft) should ignore the AccountUser and show just the Name as if the Account were a flat model, instead of having multiple levels.
public class User
{
public int Id { get; set; }
public string Name { get; set; }
}
public class Account
{
public int Id { get; set; }
public User AccountUser { get; set; }
public string Name
{
get
{
return AccountUser.Name;
}
set
{
AccountUser.Name = value;
}
}
}