what is the use of getter and setter?

[vbbit]

So I am getting myself confused with setter and getter vs. a public variable. I realize that I have not used setter and getter ;-0
What is the use of getter and setters vs. public variable? I understand its' about encapsulation and data validation, but I still don't see any single example that will use getter and setter over a public variable.

I also use a lot of methods that pass parameters to return some result. Could someone point me to a nice easy understand example from a web development stand point?

Say a registration page asking for FirstName and LastName textfields, how would you use getter and setter to accomplish this? Instead of having a method below

public string fullname;
public string returnFullname(string fname, string lname)
fullname = fname & lname;
return fullname;

in the code behind I can access that information by calling classname.returnFullname.fullname;

[jmcilhinney]

First up, this code really has nothing to do with ASP.NET so it really doesn;t belong in the ASP.NET forum. It's just a C# question, so it would have better posted in the C# forum.

Anyway, the idea behind a property is that, from the outside, it appears to behave just like a variable, i.e. you can assign a value to it and retrieve a value from it, while from the inside it appears to behave like a method, or in fact a pair of methods. The fact that it behaves like a variable from the outside makes it easier and more natural to use in code, which is a good thing. It allows you to think of the value as simply some data that an object has. If you were to just a variable though, you lose the ability to validate the data, raise events, etc. If you use methods though, you would need two of them to be able to get and set the data. Java doesn't have properties, so if you wanted to get and set some text it would look like this:

private string text;

public string get_Text()
{
    return text;
}

public void set_Text(string text)
{
    this.text = text;
}

In C# that can be done like this:

private string text;

public string Text
{
    get
    {
        return text;
    }
    set
    {
        text = value;
    }
}

Personally, I prefer the C# version. Also, if you don't need to do anything other than get and set the private field then you can simplify it to this:

public string Text { get; set; }

You might wonder why you would bother with that rather than just using a variable, given that you don't need the advantage of being able to validate or raise events or whatever. Well, for a start, properties can be used in data-binding while variables can't. Also, it allows you to change the implementation at a later time, e.g. add a TextChanged event and raise it in the setter, without changing the interface and therefore without breaking any existing code that uses that property.

It's also worth noting that a property is actually implemented as a pair of methods when it's compiled, so the similarity to a variable is purely for the developer's convenience.

I should also point out that your example has nothing to do with properties. That's a method through and through, because you're passing it two arguments. Properties do support parameters but generally only for indexing. If you were to have a FullName property then it might look something like this:

public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName { get { return string.Format("{0} {1}", FirstName, LastName); } }

Notice that FullName has a getter but no setter. That makes it a read-only property, which is something else that you can't do with a variable alone. You can set the FirstName and LastName and the get the FullName. From the outside it appears as though the object just has this FullName value lying around but, internally, it's calculated each time.

You could also make that more powerful if you did include a setter for the FullName property that could then set the FirstName and LastName properties:

public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName
{
    get
    {
        return string.Format("{0} {1}", FirstName, LastName);
    }
    set
    {
        var names = value.Split(' ');

        if (names.Length != 2)
        {
            throw new ArgumentException("FullName must be in the format 'FirstName LastName'.");
        }

        FirstName = names[0];
        LastName = names[1];
    }
}

Again, FullName behaves just like a variable from the outside but inside it is much more.

[vbbit]

Thank you. Could you elaborate on this "Also, it allows you to change the implementation at a later time, e.g. add a TextChanged event and raise it in the setter, without changing the interface and therefore without breaking any existing code that uses that property." I am not quite understanding this scenario.

[jmcilhinney]

Thank you. Could you elaborate on this "Also, it allows you to change the implementation at a later time, e.g. add a TextChanged event and raise it in the setter, without changing the interface and therefore without breaking any existing code that uses that property." I am not quite understanding this scenario.

Let's say that there were no properties. If you started out just using a field and you then wanted to raise an event when the value changed you would have to change the implementation to use methods instead, which would break all code that already used the field. By using a property from the outset, if you wanted to add the event then you could without affecting any existing code.