Thread: public vs get, set

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

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