What's with all the Get/Set lines?

I'm new to this so excuse me if this question is obvious.

A lot of the examples I am seeing for variables are using get set methods.

In C++ you only needed to declare the variable in the header file of the class and then assign it a value with the = operator.

But in C# I see this:

Code:

---

private string m_csTitle;

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

---

And yes I understand private / public but never really used it that much so just used public most of the time in the past.

This way of doing varriable assignment seems to take up so much more room ( 12 lines instead of 2 ) !

Do I have to do it this way? I have a program with several hundred variables in one class due to the large number of controls on the form.

for simple properties like that I usually just put it all on one line:

Code:

---

private string m_csTitle;
public string Text { get { return m_csTitle; } set { m_csTitle = value; } }

---

in c# you can also just make vars public and access them without using get and set
using get and set is called properties
http://www.c-sharpcorner.com/UploadF...rtiesInCS.aspx
and is generaly seen as a prettier way of handling member functions
for classes

It's called Encapsulation. Imagine the following:

Code:

---


public class Example
{
  public int Month;

  public Example()
  {

  }
}

....

public class GetExample
{

  public GetExample()
  {
      Example e = new Example();
      e.Month = 13;
  }
}

---

The above example demonstrates that anyone / anything can create an instance of "Example" and set the public variable "Month" to what ever they please. In the below example you can see why it makes sense to use get and set for class properties:

Code:

---


public class Example
{
  private int m_Month;
  public int Month
  {
      get
      {
        return m_Month;
      }
      set
      {
        if (value !> 12)
        {
              m_Month = value;
        }
        else
        {
          throw new Exception("Invalid Month");
        }
      }
  }

  public Example()
  {

  }
}

....

public class GetExample
{

  public GetExample()
  {
      Example e = new Example();
      e.Month = 13; // this now throws an exception
  }
}

---

In summary, never allow class variables to be publicly accessible or bad stuff WILL happen!

Using get and set allows you to make properties write only (i.e. only allow a set) or make them read-only (only allow a get). If you're ever designing a reusable library, you will have to make extensive usage of these.

Suppose you have an int which tracks how many times the user of your library can do a certain thing, if you made that int public, then your user can just go: myInt = 100000; and do it as many times as he wants. However if you exposed the int using a property with only a getter, the user couldn't do that.

Secondly, you now have Automatic Properties, so you can declare your 12 lines in just one:

public string CsTitle { get; set; }

or for readonly:

public string CsTitle { get; }

Great, thanks for that example and link.

The name of the link was "Understanding Properties in C#"
If I had known that member vars are called "properties" maybe I could have found it easier :ehh:

This whole thing is like the VBism of C++ sheesh.

Hope this learning curve pays off.

Well, you have member variables *and* you have properties

A member variable looks like this:

Code:

---


private int myInt;
internal string myString;
protected char myChar;
public float myFloat;

---

A property could be used to access those

Code:

---

public int MyInt
{
    get { return myInt; }
    set { myInt = value; }
}

---

Properties have getters and setters, member variables are still member variables like in C++. This is actually a really nice feature as you don't have to write stupid methods like: SetMyInt() GetMyInt() anymore like you do in C++, you can make it look a lot prettier ;)

Quote:

---

Originally Posted by Consola

In the below example you can see why it makes sense to use get and set for class properties:

---

So, you're using validation as the case for the voluminous get/set lines?

Not a very good case if you ask me.

int nNum;
if(nNum > 12)
message

This is/was much shorter and easier.

Quote:

---

Originally Posted by Consola

In summary, never allow class variables to be publicly accessible or bad stuff WILL happen!

---

Um prove it?

I used public variables often in millions of lines of code in classes sharing variables cross classes, etc... never had a problem

Quote:

---

Originally Posted by Mutant_Fruit

Using get and set allows you to make properties write only (i.e. only allow a set) or make them read-only (only allow a get). If you're ever designing a reusable library, you will have to make extensive usage of these.

Suppose you have an int which tracks how many times the user of your library can do a certain thing, if you made that int public, then your user can just go: myInt = 100000; and do it as many times as he wants. However if you exposed the int using a property with only a getter, the user couldn't do that.

Secondly, you now have Automatic Properties, so you can declare your 12 lines in just one:

public string CsTitle { get; set; }

or for readonly:

public string CsTitle { get; }

---

Sorry not understanding only read or only set. WHen I use vars I always get and set them both. So... guess I would always use automatic?

Quote:

---

Originally Posted by Mutant_Fruit

Well, you have member variables *and* you have properties


Properties have getters and setters, member variables are still member variables like in C++. This is actually a really nice feature as you don't have to write stupid methods like: SetMyInt() GetMyInt() anymore like you do in C++, you can make it look a lot prettier ;)

---

Ok, the property concept is starting to come back to me from my VB days (which I would prefer to forget).

I never wrote the stupid methods and don't care about pretty, other wise I would have a career as a graphics designer lol.
I do care about efficiency (less lines, condensing code, etc..)

But I get it a little more now.

Quote:

---

Originally Posted by alan93

I used public variables often in millions of lines of code in classes sharing variables cross classes, etc... never had a problem

---

I'm sure Steve McConnell and Erich Gamma wouldn't agree ;)


http://www.amazon.co.uk/Design-patte...2435733&sr=8-1

http://www.amazon.co.uk/Code-Complet...2435800&sr=1-1

You don't have to take my advise and I am often wrong, but just because you've never had any problems does not mean they do not exist in your code!!

Quote:

---

Originally Posted by Consola

I'm sure Steve McConnell and Erich Gamma wouldn't agree ;)


http://www.amazon.co.uk/Design-patte...2435733&sr=8-1

http://www.amazon.co.uk/Code-Complet...2435800&sr=1-1

You don't have to take my advise and I am often wrong, but just because you've never had any problems does not mean they do not exist in your code!!

---

Just color me the cynical programmer. I'm not into phrases like "this is the way its done".

I want proof, reason, details. I'm stubborn that way. If someone can show me a better way , I'm receptive, but I have to see why its better.

Quote:

---

Originally Posted by alan93

I want proof, reason, details. I'm stubborn that way. If someone can show me a better way , I'm receptive, but I have to see why its better.

---

The reasons for using properties, and ALWAYS keeping data private, is that it gives you the flexability to change the internal representation without effecting your clients. It also provides "hooks" for intercepting all read/write accesses.

There is (almost) nevery a reason to have data members directly exposed.

Quote:

---

Originally Posted by alan93

I want proof, reason, details. I'm stubborn that way. If someone can show me a better way , I'm receptive, but I have to see why its better.

---

Quote:

---

Originally Posted by Mutant_Fruit

Suppose you have an int which tracks how many times the user of your library can do a certain thing, if you made that int public, then your user can just go: myInt = 100000; and do it as many times as he wants. However if you exposed the int using a property with only a getter, the user couldn't do that.

---

Is that reason enough for you? If you made that int public, how could you control how many times your user does action X? You couldn't. This is why it's better.

Quote:

---

Sorry not understanding only read or only set. WHen I use vars I always get and set them both. So... guess I would always use automatic?

---

You have three types of properties:
1) Readonly: This type of property *only* has a get method, so you can "get" the value.
2) Writeonly: This type of property *only* has a set method, so you can "set" a new value. However you can never check what value is there.
3) Read/Write: This type of property has both a get and a set so you can read the value that's there and write a new one.

Automatic properties are a compile time trick. They allow you to write:

Quote:

---

public string CsString { get; set; }

---

and at compile time it magically turns into

Code:

---

private string m_csTitle;

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

---

This allows you to write less lines of code for the same result.

Of course, generally people do condense the gets and sets to something along the lines of this:

Code:

---

private string m_csTitle;

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

---

One of the main advantages of using properties is that you control access to your variable while still being able to treat it as a regular object of that type. For example in c++ you might have to write:

int myInt = myobj.GetValue() * myobj.GetCost();

but in c# you write:

int myInt = myObj.Value * myobj.Cost;

However there are some cases where you can't use properties. Running from memory i think it's when you want to use the object as an "out" argument or "ref" argument. You'd want to double check that yourself ;)

Quote:

---

Originally Posted by alan93

I want proof, reason, details. I'm stubborn that way

---

I would highly recommend reading the two books I posted links for. Especially "Code Complete" this will give you enough proof, reason and details to last you a life time.

I too am anti "the right way" (especially concerning microsoft), but I do maintain the mentality that there is always a better way of coding something regardless of age, experience or salary ;)