Click here to Skip to main content
15,868,164 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
I want to know the diffrence between the public string test; and public string test{get; set;}.

see below code

C#
class test
{
 public string Name1;
public string Name2{get; set;}
}

class abc
{
test objtest = new test();
objtest.Name1="Hai Developers..";
objtest.Name2 = "C#";
}


i can access both Name1 and Name2 by creating object for the class test.
Then what is the diffrence between public string Name1; and public string Name2{get; set;} ?
Posted
Comments
johannesnestler 2-Jun-16 10:34am    
What a question... sry man, but better do some tutorial and read a book about C# and/or OOP - People give good answers here but your are just wasting your and their time. But maybe you don't want to learn, just have to know for a Course or whatever - I can understand that. So my short answer is - never use a public field - always use a public property, Keep all fields private to the class. My current project's codebase is not so big, just a few 100k lines of code, but you will never see any pulbic field even if it would have 100M lines of code ;)

The first one is a public variable (a field) of type string, the second one is a property.
Here you see 5 reasons why use properties over fields (http://stackoverflow.com/questions/4142867/what-is-difference-between-property-and-variable-in-c-sharp[^]):
1 - Fields can not 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
 
Share this answer
 
v2
Name1 is field whereas Name2 is property.
Check this[^] link
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900