We Keep Coding

what is the exact use of auto implemented properties [duplicate]

This question already has answers here:
Public Fields versus Automatic Properties
(14 answers)
C# 3.0 auto-properties — useful or not? [closed]
(17 answers)
Closed 8 years ago.
May be its a duplicate question.
I did search about this and referred these Articles
use of properties vs backing field inside owner class,
should i prefer properties with or without private fields,
Properties Matter.
The point i understood was,
Access like making field read only
We can include some logics in
setter/getter used for data binding
What I really want to clear was,
public class Employee {
public string strName;
}
public class Employee {
public string strName {get;set;}
}
My questions:
Whats the difference between this two implementations
Is there any place ( i mean actual scenario) where we can justify a need for auto implemented properties instead the first implementation as shown above as first.
UPDATE
I know its a duplicate question and i mentioned it. Please consider my 2nd point in questions i asked.
what the answer precisely ?
I couldn't understand that.
Whether its a good practice or what is the need if i do not have any logic to set that value ?
Fine thank you all for replying. I got it now clear. Since i am very new i cant grasp it. But now i got the point. Sorry for wasting all your time.

With auto implemented properties you can do
public class Employee {
public string StrName {get; private set;}
}
And make an external read-only, but internal settable property. Which is something you can't do with your public variable

Having a field inside a class is not a good idea. using properties allows you to encapsulate your data better. and when you just want to have a field accessible without any logic in you class then you can use automatic properties.
there are many scenarios that using a field inside your class makes things go wrong and harder as your software evolve.
for example: assume you have
public class C
{
public int Value;
}
in your code base.
then suddenly you realize that Value can not be set to zero. Then you have to make Value private and provide a SetValue() and GetValue() method. This is easy. but wait, how you gonna handle all other codes that relies on Value now?
but think about this one
public class C
{
public int Value { get; set; }
}
now it just needs a backing field like _value and implementing the setter and getter.

Differences between getter and setter and a regular variable[C#] [duplicate]

This question already has answers here:
Auto-implemented getters and setters vs. public fields
(17 answers)
Difference between Property and Field in C# 3.0+
(10 answers)
Closed 8 years ago.
I've learned about the getter and setter topic and i couldn't understand the new type of this topic :
Let's say someone is declaring a new get&set method :
public int Id { get; set; };
What i want to know is what is the differences between doing what i wrote below and a regular public variable (public int id).
Comments are welcome.

Properties enhance the notion of encapsulation in OOP (oject oriented programming). That's the of a getter and setter in C#. Concretely, instead of using a simple variable class, you could use a property and a backing field in which actually your value will be stored. The property would be the way to access this backing variable and get it's value or altered it. The good thing about properties is that you can use any logic you want, before you store the value the user provide you. So instead of doing the same check in the methods of your class where this value is setted by the user and then used you could use your property.
Let we have a class called Customer where, one of it's fields is the customer's age.
public class Customer
{
private int age;
public int Age
{
get
{
return age;
}
set
{
if(age>0)
{
age = value;
}
else
{
throw new ArgumentException("age must be greater than 0.");
}
}
}
}
Having defined the above property, you avoid the check of the age that will be provide by the creator of an object of type Customer in any other place. the provided value will be stored somewhere that the creator/consumer of the object should not know (encapsulation) and in general terms would make you life as a programmer far easier.
So you contructor now will not contain any logic:
public class Customer(int age)
{
Age = age;
}
you simply assign the provided value to the corresponding property, without making any check about the validity of the provided value in your constructor.
Furthermore, say that in a method of your class some calculations are executed and the result is going to stored to variable called age. If you use it's corresponding property, you will not have again to make any validation check. This was a rather simple case with one variable. Try to think about what would have happened if you had 6 or 7 variables, a common case in production code.
The above are applicable wherever you have variables, whose values setting requires validation. On the other, if you class holds only varaibles, whose values aren't to undergo a validation testing, you could use the following syntax.
public class Customer
{
public int Age { get; set; }
}
This syntax, at first seems meaningless. Why we should declare this instead of the following one:
public class Customer
{
public int age;
}
The second declaration doesn't respect the principle of encapsulation (for more information about encapsulation in OOP, please refer here. Namely, the second declaration exposes the variable in which we will actually store the value of age.
In a few words, it wouldn't happened anything odd if you had use the second declaration and not the first one - provided that's there weresn't any logic in you value setting. However it's more consistent you use the first one.

A public property keeps the option open to perform validation or other logic while getting or setting the value. A public field does not.
For example:
- You might want to check that an age value isn't negative or ridiciously high
- You might want to make sure that when a first name is set, that it is properly cased
If you offer these properties as public fields you won't be able to enforce these rules later on.
You can also use properties to perform lazy instantiation, which might be useful when working with resource intensive code.

C# Get Set vs Without Get Set [duplicate]

This question already has answers here:
Auto-implemented getters and setters vs. public fields
(17 answers)
Closed 8 years ago.
I have looked at at least 10 SO questions on get/set but cannot find mine. So I hope this is not a duplicate.
public class myint
{
public int value{get;set;}
}
vs
public class myint
{
public int value;
}
The above 2 codes look the same to me. If I want to use the myint class, I just write the code below and it can run on either class.
myint A;
A.value=10;
So what is the get/set use for?

You're asking what the difference is between using a public instance variable vs. getter/setter properties I assume.
Properties allow you to further encapsulate logic around getting or setting a variable, for example adding simple validation logic. You could throw an exception if someone sets your value to less than zero for example. You could also add further logic in the getter/setter to for example synchronize a specific field.
A few other differences:
Properties can be used for data binding easily in most .NET UI frameworks.
Reflection works differently.
Differing access levels for get/set vs. for example your instance variable you can choose between readonly, private, protected, static, etc. as a whole.
There is more overhead accessing a property. This is usually unimportant in most use cases other than games and highly performance sensitive situations.

http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx
A property is a member that provides a flexible mechanism to read,
write, or compute the value of a private field. Properties can be used
as if they are public data members, but they are actually special
methods called accessors. This enables data to be accessed easily and
still helps promote the safety and flexibility of methods.
Here are few things off the top of my head that differentiate a public {get;set;} vs a public member variable:
Properties are needed for data binding.
get and set can have different accessors (e.g. public int Value {get; protected set;}
get;set; can be part of a interface e.g. interface IHasValueGetter { public int Value {get;}}
What is the difference between a Field and a Property in C#?

here is when do we use get set
According to the Property Usage Guidelines on MSDN:
Use a property when the member is a logical data member. In the following member declarations, Name is a property because it is a
logical member of the class.
Use a method when:
The operation is a conversion, such as Object.ToString.
The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
Obtaining a property value using the get accessor would have an observable side effect.
Calling the member twice in succession produces different results.
The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
The member is static but returns a value that can be changed.
The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the
internal array so that the user cannot change internal state. This,
coupled with the fact that a user can easily assume it is an indexed
property, leads to inefficient code. In the following code example,
each call to the Methods property creates a copy of the array. As a
result, 2n+1 copies of the array will be created in the following
loop.

you can remove get and set it will not affect the code and working due to the reason that you have defined a variable of type int with the Access type of public so that properties are mostly used to access the private members of class which is in your case do not exist so go on and remove it how ever if in top most class you define a variable with Private modifier the to access it get and set are necessary properties!

// This is an example of property...
public class myint
{
public int value{get;set;}
}
// This is an example of field...
public class myint
{
public int value;
}
The difference:
Databinding techniques only works on properties, and not on fields
Fields may be used as input to out/ref arguments. Properties may not.
Properties may throw exceptions - fields will never do that
Example:
class Person
{
private string _name;
public string FirstName
{
get
{
return _name ?? string.Empty;
}
set
{
if (value == null)
throw new System.ArgumentNullException("value");
_name = value;
}
}
}
Properties support different accessibility for getters/setters - fields do not (but fields can be made readonly)

What's the difference between two ways of getter and setter. which is better? [duplicate]

This question already has answers here:
What are Automatic Properties in C# and what is their purpose?
(11 answers)
Closed 9 years ago.
There are two ways to implement the getter and setter.
A:
public Object Name {get;set;}
B:
private Object _name;
public Object Name
{
get {return this._name;}
set {this._name = value;}
}
When we wanner get or set the property we all use
X.Name = "Joy";
String name = X.Name
So I just want to know the difference between them.
Thank you.

The first one is Auto-Implemented Properties which is basically syntactic sugar and results in the same as the second approach.
When using the first auto implemented properties the c# compiler will generate a backing field just like you have it declared in the second case.
If you want to make the property read only you can use declare it like this:
public Object Name {get; private set;}

They're just the same. The first one is just syntactic sugar.
But if you want to add some logic, say validate the setter value, the second one is what you need.

Property accessors [duplicate]

This question already has answers here:
C# 3.0 auto-properties — useful or not? [closed]
(17 answers)
C# getters, setters declaration [duplicate]
(5 answers)
Closed 9 years ago.
Is there any fundamental difference between
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
and
public string Name {get; set;}

You can access internal field, in second case it's autogenerated
You can set a breakpoint in VS, in second you cannot.

Nothing fundamental, and you can usually change between them safely.... until something has used the field name (I'm looking at BinaryFormatter here...).
otherwise, no. You can usually change between the, without breaking things, for example to add logic or to add attributes to the field.

Basically there is no fundamental difference, #2 just saves you a lot of lines if you want to do this for 20 properties when you don't need encapsulation upfront but would like to have the option for future.

To external consumers of your class (assuming _name is private), they are the same unless you are using something like BinaryFormatter that uses reflection to store the internal state of your object.
To your class, the major difference is that you don't have access to the field when you use an auto property. This means you can't do some things, such as use the property as a ref or out parameter. For example, if you have a int value and you are reading the default value in your constructor, you can't say Int32.TryParse(s, out Range). You can say Int32.TryParse(s, out _range).