public vs get, set

Hello,

I'm coding some C# and cant really get the difference between public and the properties get, set. In me world the two things is kinda the same but my guess is that I have missed something so any help would be nice ty.

Example:

Code:

---

class TheNumber
{
    public int number;
    public int Number {get; set;}
}

---

Then from any part of the code I can write:

Code:

---

TheNumber theNumber = new TheNumber();

theNumber.number = 10;
theNumber.Number = 10;

---

so why cant I just have a public member instead of the property one in this case?

get set can be methods. You can do more than just setting the variable.

Code:

---

int num_div_2;
public int Number {
    get {
          return num_div_2 * 2;
    }
    set {
          num_div_2 = value / 2;
    }

---

You can also only define one of them to make the property read-only or write-only.

There may not even be a variable associated with the attribute.

For example, for a linked list, you can have a read-only attribute Length that goes through the list to calculate the length, but to the user it would just look like a variable.

You can make immutable objects (objects you cannot modify once created):

Code:

---

public class Location
{
  public Location(int X, int Y)
  {
    this.X = X;
    this.Y = Y;
  }

  public int X { get; private set; }
  public int Y { get; private set; }
}

var MyLocation = new Location(1, 2);
var MyX = MyLocation.X; //Ok
MyLocation.X = 3; //Invalid

---

The backing store for the property is not needed. The compiler will create one for you.

Of course, if you don't want to use anything more sophisticated you can turn them public. Personally I use public variables for personal projects because I am lazy. A good practice is to use set/get for flexibility. Maybe you want to add something later. In C++ that could be a must. In C#, though, you use the same syntax. So I guess if you wanted to use a get/set you can just create one without change your whole code.

Another reason to use properties instead of public variables:

Properties help you follow the better programming practice of "program to an interface, not an implementation". With a property, you can alter the get/set accessors at will to make changes to the class functionality without changing any code outside of the class. The world outside of your class doesn't need to know -- or care -- how that property is internally stored or calculated. As long as the new class has the same interface as the old, it should be a direct substitute.

Your class should be a 'black box' to the rest of the code -- the code using your class should know everything about how to use the class (the interface) but nothing about how the class works internally (the implementation).

There are of course some downsides. You might get tempted to make your code very safe decreasing performance drastically. A simple example is when you have an Execute() logic. You pass some parameters on you object and then you want to change the object with an Execute() command. You might put a get/set on every parameter, which is fine.
But you might go too far and put the Execute() command everytime you set it. You idea is to make sure that the changes are reflected on the object. But then you might have some code like:

Code:

---

obj.height = 10;
obj.x = 1;
obj.y = 2;
obj.color = Color.Red;
...

---

and everytime the Execute() command will be called, when you could call it only when you are done passing parameters. If the Execute() is very costly, your program might get too slow. The problem with the above is that the code might indeed be a "black box" so you won't know that Execute() is called all the time. So using get/set by itself is fine, but that doesn't imply that you should not provide the basic mechanisms on simply being able to assign variables if that is what you really want in your program.
So, you need some planning when using a get/set.

I believe the idea is mostly intended for code that will be re-used. Otherwise it is more or less a preference the way you program.

If you only want to call Execute when you're done passing parameters, why not make those 'properties' arguments to the Execute method? Properties are intended to set object state, not to perform functionality. If the Execute is very costly, I'd argue that it doesn't belong in a property definition at all.

Many controls in winforms/asp.net use them specifically for data binding. While that doesnt mean squat in a discussion about core language features, it's vitally important on a discussion about why to use them. It is very correct to say that properties are more for the interface, while private/public variables are for the implementation.

In designing libraries for other programmers at work, my typical use of properties includes:

providing the expected hook for data binding
providing a wrapper around a specific storage paradigm (viewstate, session, cache, db)
providing the necessary access for initializer lists (again, a real keystroke saver)
providing the necessary access for linq operators

notice all of my uses are for the interface, not the implementation