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.

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)

Properties vs Public member variables [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between a field and a property in C#
I'm a beginning programmer and I've read all about class properties. Books state that properties allow you to indirectly access member variables. Ok, so what makes it any different than just making the field public and accessing it directly?
Here's a quote from Learning C# 3.0 by Jesse Liberty:
For example, you might want external
classes to be able to read a value, but not change it; or you might want to write
some code so that the internal field can accept only values in a certain range. If you
grant external classes free access to your member fields, you can’t control any of that.
I don't understand what he is saying here. Can someone further explain this or give an example of why I would want to use a property over making the field public. As I understand it now they would both accomplish the same exact thing...so I'm obviously missing something here.

The other answers provided so far provide details of the advantages of accessor/mutator logic, but all seem to miss out on the ideological point about object encapsulation.
You see, class member fields are an implementation detail. If you have a class that represents a collection, for example, then you could implement it as a linked list (and expose the root-node via a public field) or you could implement it as a resizable array and expose the index0 member.
The problem with revealing implementation details is that you lose any kind of defined interface between your class and its consumers. By ensuring all operations are done via defined methods (controlled by the class itself) you make it easier to work with and provide for a long-term viewpoint. For example, you are far more easily able to convert your collection implementation from one type (the linked-list) to another (the array) without breaking any contracts with your class' consumers.
Don't worry about any performance impact of trivial accessor/mutator methods: the JIT compiler will inline the property methods. If you'll run some benchmarks you'll see the performance of properties vs fields is identical.

He's saying that properties can provide a getter but not a setter, therefore making them read-only (for example)
Properties are just syntactic sugar for a method e.g.
public int SomeProperty { get; set; }
is just sugar for
private int _someProperty;
public int SomeProperty_get()
{
return _someProperty;
}
public void SomeProperty_set(int value)
{
_someProperty = value;
}
This means that property setters/getters can apply logic that a mere public field can't
Edit: I'm not exactly sure what field names the CLR gives the backing fields for auto-properties - it's just an example :)
Edit2:
An example of a read only property:
public int SomeProperty { get; }
and finally a public read - private write (for autoproperties)
public int SomeProperty { get; private set; }
Really useful when you can't be bothered to type a backing field in :)
Just remember, if there is a possibility that you wish to apply logic to a member, then a property is the way to go. This is the way a lot of frameworks work (e.g. tracking 'dirty' objects by using a property to tell some sort of object manager that something has changed, this would not be possible using a public field)

Properties can have side-effects, They provide syntactic sugar around 'getter' and 'setter' methods.
public class MyClass {
int sizeValue = 0;
public int Size {
get {
return sizeValue;
}
set {
if ( value < 10 ) throw new Exception("Size too small");
sizeValue = value;
}
}
}
Properties can also have different levels of protection for get and set, you cannot do that with fields.
public class MyOtherClass {
// only this object can set this.
public int Level {
get; private set;
}
// only things in the same assembly can set this.
public string Name {
get; internal set;
}
}

There are a number of important differences between "properties" and "member access".
The most significant is that you can, through a property, make a member read-only (you can access the state, but you cannot change it). Just like "getter()" and "setter()" methods in Java.
You can also return a computed value from a property (generate a value "on-the-fly", as though it were a variable).

Properties can be configured so that:
they are read-only, Public MyProp {get;}
they are write-only Public MyProp {set;}
they are readable by external objects, but can only be set by the class's internals
Public MyProp {get; private set;}
As others have posted, you can also put logic into your getters and setters. For example before allowing the property to bet set to a new value, you can check that the value is acceptable.
You cannot do any of that with a public field.
Basically, a public field is the dumbest sort of property that you can have. Given that .Net now allows autobacking fields for your properties. There is no good reason to use public fields any longer.

If you have Public Int MyAge
I can set it to -200 or 20,000 and there is nothing you can do about it.
If you use a property you can check that age is between 0 and 150, for example.
Edit: as per IanNorton's example (man, that was fast)

What is the difference between a property and a variable

I have a confusion about understanding Property and Variables
public class ABC()
{
public int A;
public int B { get; set; }
}
What is the exact difference between in A and B?

As many have pointed out, A is a field, B is a property.
The real question is, why should you care, and what to use?
I refer to a blog post of Jonathan Aneja:
(Its in VB, but it applies to C# as well ;))
So why use properties over fields, 5 reasons:
1. Fields can’t be used in Interfaces
You can’t enforce the existence of a
field in an object’s public contract
through an interface. For properties
though it works fine.
2. Validation
While your application currently may
not require any validation logic to
set a particular value, changing
business requirements may require
inserting this logic later. At that
point changing a field to a property
is a breaking change for consumers of
your API. (For example if someone was
inspecting your class via reflection).
3. Binary Serialization
Changing a field to a property is a
breaking change if you’re using binary
serialization. Incidentally, this is
one of the reasons VB10’s
auto-implemented properties have a
“bindable” backing field (i.e. you can
express the name of the backing field
in code) – that way, if you change an
auto-implemented property to an
expanded property, you can still
maintain serialization compatibility
by keeping the backing field name the
same (in C# you’re forced to change it
because it generates backing fields
with unbindable names).
4. A lot of the .NET databinding infrastructure binds to properties but not fields
I’ve heard arguments on both sides as
to whether or not that’s a good thing,
but the reality is that’s the way it
works right now. (Note from me: WPF bindings work on properties)
5. Exposing a public field is an FxCop violation
For many of the reasons listed above
:)
There might be more reasons.
I would also like to point to a blog post of Jeff Atwood and conclude with a quote from it:
The really important thing to take away here is to avoid writing code that doesn't matter. And property wrappers around public variables are the very essence of meaningless code.

A is a field, B is a property. A property is basically syntactic sugar for getters and setters. The class you have defined will be compiled into something like this:
public class ABC()
{
public int A;
private int backing_B;
public void set_B(int value)
{
backing_B = value;
}
public int get_B()
{
return backing_B;
}
}
Note that this kind of conversion is true for all C# properties -- accesses to ABC.B will be converted to method calls. Properties basically provide the illusion of a "variable" while actually just being a cleverly disguised pair of methods.
This is important, because it allows you to declare your own get and set method body, which can validate values or do other interesting things:
private int b;
public int B {
get { return b; }
set {
if (value < 0) throw new ArgumentOutOfRangeException("value");
b = value;
}
}
Note that most properties will use a field to store their value. Properties seldom exist on their own, apart from fields.

In C# any "variable" that has a getter and setter is referred to as a property. A variable has no getters and setters or so that is what the text books say.
My programming instructor made us have getters and setters for almost every variable that we created in Java. Even indexing variables he made us use a getter and setter if they were declared at the global class scope. I think this might have been overkill but it did get me to make getters and setters.
The real things about getters and setters are that they more than likely do more than just set an internal variable. Most setters are going to perform some type of data validation to make certain that data can be set to the variable. A getter might also check returning data for some criteria.
If your property is private and your setters and getters are public technically anyone could access your variable and change it as if they had public access to the actual variable. So, in reality, you should check your data to make certain that it is valid or some other data check.
private int myVariable;
public int myVariable
{
get
{
return myVariable;
}
set
{
if (value < 0)
{
throw new Exception("This is your exception some where else in code");
}
myVariable = value; //remember value is something that is
//declared automatically
}
}
public string FirstName { get; set; }
The above is a shorthand way of writing the following
private string firstName;
public string FirstName
{
get
{
//...code here
}
set
{
//...code here
}
}

A property is sort of a short getter and or setter. You can add logic to the set or get of the property or make them private which means that they are not accessible from the out side, where a variable is always accessible (if it is public).

Variable is, well, a variable.
Property is a special type of method that exposes that variable. And since it is a method, therefore, you can do some other things in it apart from just exposing the variable.
From MSDN:
The Property statement introduces the declaration of a property. A property can have a Get procedure (read only), a Set procedure (write only), or both (read-write). You can omit the Get and Set procedure when using an auto-implemented property. For more information, see Auto-Implemented Properties (Visual Basic).
You can use Property only at class level. This means the declaration context for a property must be a class, structure, module, or interface, and cannot be a source file, namespace, procedure, or block. For more information, see Declaration Contexts and Default Access Levels.
By default, properties use public access. You can adjust a property's access level with an access modifier on the Property statement, and you can optionally adjust one of its property procedures to a more restrictive access level.

There is a very good article (link below) about using fields/variables vs Properties from Microsoft itself. Though the article essentially talks about a FxCop violation rule, it clearly defines the difference between the two and the exact usage guidelines.
An excerpt from the article:
The primary use of a field should be as an implementation detail.
Fields should be private or internal and should be exposed by using
properties. Accessing a property is as easy as accessing a field, and
the code in a property's accessors can change as the type's features
expand without introducing breaking changes.
Refer:
https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-3.0/ms182141(v=vs.80)

In your example A is a public field on the class ABC and B is a public property on the class ABC. Specifically, B is an auto-implemented property. What this means is that "under the hood" the compiler does some of the work for you and effectively transforms your code into:
public class ABC()
{
private int b;
public int A;
public int B
{
get
{
return b;
}
set
{
b = value;
}
}
}

Variable is defined basically for accessing value from a class or into the same class according to their modifier assigned to those variable.
When we define a property there two methods created for single property so extra overhead is generated that is the drawback of property.
The advantages of properties is to get or set value into private variable of class.

Where's the Encapsulation?

I'm a new programmer, so please excuse any dumbness of this question, how the following code is encapsulating private data? -
public class SomeClass
{
private int age;
public int Age
{
get { return age; }
set { age = value; }
}
public SomeClass(int age)
{
this.age = age;
}
}
I mean, with no restriction logic or filtering logic in the properties, how is the above code different from the folowing one -
public class SomeClass
{
public int age;
public SomeClass(int age)
{
this.age = age;
}
}
Is the first code providing any encapsulation at all?

It's providing one piece of encapsulation: it's saying, "there's an Age property you can get and set, but I'm not going to tell you how I'm implementing it."
That's not very strong encapsulation, but it does keep the implementation details separate from the public API. Without changing the public API at all, you could start to store the age somewhere else - in two short fields, in a service somewhere, as part of a long field or whatever. You could put logging in the property to see how often it's used. You could add an event which gets fired when the age changes (that's an API change, but won't break existing callers).
EDIT: One thing to note: even though this does nothing now, the change to make it do something later is both source and binary compatible. Changing a field to become a property is not backward compatible, either in source or binary forms. In most cases it will be source-compatible, but not binary-compatible. In some cases source will no longer build. In more evil (and contrived, admittedly) both versions will build, but with different effects.
Also note that as of C# 3, you can declare a trivial property as easily as a field:
public int Age { get; set; }
I have an article about all of this which provides more details.

This is a bit of a vacuous example. As you've correctly noted, the property doesn't seem to do anything.
But it could. For example, SomeClass could put restrictions on how the Age property is modified (by say not changing the age to a bad value like -2 or 823). Also, SomeClass need not represent age as an int internally. Age could be the result of a computation (by say subtracting today's date from a person's date of birth) or it could be stored within SomeClass as another data type (say a byte, long or a double).

I mean, with no restriction logic or filtering logic in the properties, how is the above one different from the folowing one
Its not the fact that you have or have not implemented the validation logic in the property, encapsulation here means that nobody can directly access/modify your private data. The only access available is to go through the property.
Using the bottom code, anyone can genereate exceptions and cause all kinds of havoc because they can do anything they want to your data.
Using the top code as its written allows this same havoc, but at any time in the future you can implement restriction logic in the Property and not have to modify an API for users of this class.

It's encapsulating, or wrapping, changes to the private variable age. Private variable Age can't be modified by external callers directly, only through the public methods given. It's setting up an interface so future changes to age won't break callers. The benefit is to external callers in the future, which is why it's hard to see now.

In your first example, SomeClass.Age is a property. The field "backing" the property is private. In your second example, SomeClass.age is a public field. While in many cases there may be no difference, choosing a property over a field gives you the ability to change the implementation without changing the API, or "shape" of the class. Maybe you want to do something (persist, or notify) whenever the property changes -- that would be impossible to do with a field.

Is the first code providing any encapsulation at all?
NO (at least the particular code you wrote).
The 2 pieces of code are almost the same. The first one doesn't provide any useful difference compare to the second one (as the code is written).
When using getters and setters, you can restrict access to the private variables. This could be a form of Encapsulation.
i.e.
private int x
public int getInt(String password){
if(password == 'RealPassword'){
return x
}
}