3

I have a strange question. I'm trying to understand how to use accesssors correctly. I get the idea of using them with private and public variables in classes but C# 3.0 allows us to use them with only public ones (i.e)

public string Email {get; set;}

So, I'm writing an app - this a part of my code:

public class Customers
{
   public string Telephone;
   public string Email {get; set;}
   public void LoadCustomer(string _name)
   {
       DataSet dataSet = new DataSet();
       dataSet.ReadXml("Customers.xml");


       XDocument doc = XDocument.Load("Customers.xml");
       XElement root = doc.Root;
       for (int i = 0; i < dataSet.Tables[0].Rows.Count; i++)
       {

           var Klient = from wpisy in root.Elements("Customer")
                        where wpisy.Element("Name").Value.Equals(_name)
                        select wpisy;
           Telephone = Klient.First().Element("Telephone").Value;
           Email = Klient.First().Element("Email").Value;

       }
    }
}

private void Window_Loaded_1(object sender, RoutedEventArgs e)
{
    Customers customer = new Customers();
    customer.LoadCustomer(name);
    txt_Telephone.Text = customer.Telephone;
    txt_Email.Text = customer.Email;
}

As you can see, I have a class and a method which calls the class when the window is opened. Everything works whenever I use the accessors:

public string Email {get; set;}

or I don't:

public string Telephone;

So, my question (maybe silly) is what's the point of using the accessors with such public variables since there's no difference when I use them or not?

DanM7
  • 2,203
  • 3
  • 28
  • 46
Michal_Drwal
  • 526
  • 1
  • 9
  • 26
  • *"but C# 3.0 allows us to use them with only public ones (i.e)"* - That's not true at all. `public int Foo { get; private set; }` `private int Foo { get; set; }` `protected int Foo { get; set; }` etc. – Ed S. Oct 27 '13 at 21:05
  • See http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx - fields and properties are not the same thing. – Jon Skeet Oct 27 '13 at 21:06
  • 1
    possible duplicate of [Public Fields versus Automatic Properties](http://stackoverflow.com/questions/1180860/public-fields-versus-automatic-properties) – Tim S Oct 27 '13 at 21:07
  • possible duplicate of [Why use getters and setters?](http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) – Adrian Wragg Oct 27 '13 at 21:48
  • possible duplicate of [Auto-implemented getters and setters vs. public fields](http://stackoverflow.com/questions/111461/auto-implemented-getters-and-setters-vs-public-fields) – nawfal Jul 17 '14 at 20:05

1 Answers1

3

There is no functional difference between the two. However, public string Telephone; is a codesmell because it exposes your value with its plain data to the outside world and not trough an (implicit) accessor.

This means that you will never be able to add some sort of validation rule like this without breaking existing code:

private string _email;
public string Email {
 get { return _email }
 set {
  if(value.Contains("@") { _email = value }
 }
}

To the outside world this is still used as MyClass.Email, but you can add logic behind it which wouldn't be possible if you would simply use a field instead of a property.

Jeroen Vannevel
  • 43,651
  • 22
  • 107
  • 170
  • Ok, but if I don't need to add any validation rule, is it wrong just to use a public field instead of a property? What's the point of using EMPTY properties? – Michal_Drwal Oct 27 '13 at 21:29
  • Encapsulation is one of the basic principles of Object Oriented Programming. If you're going to stride away from this path, there is no consistency in your project (sometimes accessors, sometimes none), you can't expand functionality in the future, etc. So yes, it's wrong as in that it goes against the entire idea of encapsulation, a keystone of OOP. There is no such thing as an "empty property", rather it's a property with a very basic getter and setter. – Jeroen Vannevel Oct 27 '13 at 21:34