Hi all,
I'm just learning C# and completed a book exercise. They had a different answer and I'm not sure the difference between the two.

The way I did a method was like this:

public int ShiftsLeft {
return shiftsToWork - shiftsWorked;
}

However, when I looked at the book they had written:

public int ShiftsLeft {
get {
return shiftsToWork - shiftsWorked;
}
}

Can someone tell me the difference between the two (if there is one) please as it confused me as to why they had done it like that.

Many thanks for any light you can shed on this

John

Your first example is a syntax error because it's neither a method nor a property. If you add a parameter list, it works and becomes a method:

public int ShiftsLeft() {
  return shiftsToWork - shiftsWorked;
}

>Can someone tell me the difference between the two
Methods are named executable blocks of code that take a predetermined number and type of parameters and return a single value (possibly of type void). Properties are a controlled interface around (typically) a single class field. Let's look at it from the perspective of a lack of properties:

class Test {
  private int _field;
}

Let's say you want to give public access to _field, but you still want _field itself to be private. Unrestricted access could break your class' assumptions about that field. For the sake of argument, say the value of _field should be in the range of [0,100).

In the absence of properties, one might use methods for the interface:

class Test {
  private int _field;

  public int GetField() { return _field; }
  public void SetField(int value)
  {
    if (0 <= _field && _field < 100) {
      _field = value;
    }
  }
}

Then callers can access _field through the restricted interface and all is well, yes?

Test foo = new Test();

foo.SetField(55);
Console.WriteLine(foo.GetField());
foo.SetField(10000);
Console.WriteLine(foo.GetField());

The syntax is kind of awkward, but it's not horrible. Properties are simply another way to do the same thing with a more intuitive syntax:

class Test {
  private int _field;

  public int Field {
    get { return _field; }
    set {
      if (0 <= _field && _field < 100) {
        _field = value;
      }
    }
  }
}

The property allows callers to use the field as if it were public, but access is still restricted:

Test foo = new Test();

foo.Field = 55;
Console.WriteLine(foo.Field);
foo.Field = 10000;
Console.WriteLine(foo.Field);

So properties, useful as they are, are really just syntactic sugar.

Comments
A superb explaination and it really helped me out. Thanks
Excellent lexplanation.

Your first example is a syntax error because it's neither a method nor a property

Although the rest of your explanation is quite good, I was asking myself, why must a method have parameters? IMO it can be parameterless, or did you mean something totally different?

Narue

Thank you so much for your comprehensive explaination.

Am I right in thinking there's a typo with this bit of code though:

class Test {
  private int _field;

  public int GetField() { return _field; }
  public void SetField(int value)
  {
    if (0 <= _field && _field < 100) {
      _field = value;
    }
  }
}

Should it be:

class Test {
  private int _field;

  public int GetField() { return _field; }
  public void SetField(int value)
  {
    if (0 <= value && value < 100) {
      _field = value;
    }
  }
}

??

Thanks again for your excellent reply.

;-)

Theoretically, both could be valid. You could conceivably have a situation where you allow the modification of _field as long as _field is within a given range. Once it leaves that range, the field is essentially frozen.

However, in the likely scenario, option 2 is more likely what you were trying to accomplish.

So properties, useful as they are, are really just syntactic sugar.

Indeed. In fact, the compiler will turn them into getter and setter methods around a field. With that said (@JohnnyT), unless you have a compelling reason to create your own getter and setter methods, stick with properties as Narue outlined above. It's what other C# developers will expect to see if having to consume or maintain your code.

Apegram,
Thanks for your info.
The replies here have been brilliant and I've got a clear idea of it now. So... back to it...
Thanks again. I'm sure I'll be back to pick your brains again before this book is finished!
Cheers
John ;-)

>Am I right in thinking there's a typo with this bit of code though:
Yes, the test should be against value rather than _field. Serves me right for writing untested code inline. ;)

Thanks Narue.

Just moved on to learning about 'interfaces' now...

My head's fried but I'll struggle on. Thanks again for all your help.

Cheers

John ;-)

This question has already been answered. Start a new discussion instead.