   C# Properties, get, set.
  I understand this way of doing it.public class Testing{    int m_id;    public ID    {   get   {  return m_id;   }   set   {  m_id = value;   }    }}But In reading an XNA book I just came across this codepublic Matrix view {get; protected set;}could somebody explain?   
Quote:But In reading an XNA book I just came across this codepublic Matrix view {get; protected set;}could somebody explain?This is just shorthand for a trivial property (a trivial property looks like the first piece of code you wrote -- the getter simply returns some underlying field and the setter simply writes it). The "protected" bit in that XNA example just marks the setter as protected, which has the same effect as marking any other method protected.The shorthand produces a property equivalent to your first example, with an automatically generated backing field. You thus only need to write out the more verbose property if you need special behavior in the set or get methods -- if you only need a simple, trivial property, you can use the shorthand and save yourself typing and time.   ;  In addition when you use the autogenerated properties you can't access the auto created back variables that it creates to store the values. You have to use the property to access the value even in class methods.So that is the reason you would declare the auto generated setter as protected so that your class (as well as derived classes) can still set the property but anything outside the class can only call the getter.Just felt that warranted a little more explanation.;  There is no point to writing trivial properties, by my understanding.For the first version, just use a public member:public class Testing{  public int ID;}When you decide, for example, that the value should be read-only, then you change to a trivial read-only property:public class Testing{  public int ID { get; }}When you later decide that the ID is calculated in terms of existing data members, then you write a normal property:public class Testing{  private int foo, bar;  public int ID { get { return foo * bar; } }}Naturally, you can do the same things for write-only, and read-write properties, and even mix and match techniques. But a read-only property with no logic reduces to { get; }, a write-only property with no logic reduces to { set; }, and a read-write one with no logic reduces to just a data member.The book code writes { get; protected set; } because it is almost just a public data member - any outside code can read the value, but only derived classes can write it.   ;Quote:Original post by ZahlmanThere is no point to writing trivial properties, by my understanding.That's not nessecarily true in .NET. There are many things which work on properties but not public fields (e.g. XML serialization), so you have to use trivial properties if you want them to work with XML serialization, for example.;Quote:Original post by ZahlmanThere is no point to writing trivial properties...True, there is no functional point, but I personally understand not wanting to mix different ways of exposing things...  I don't like to expose ANY member variables directly, and I wouldn't want to expose a single variable while using properties for everything else.I usually organize my source in such a way that the member variables are in one section with other private data, and public properties are somewhere else.  Just exposing and capitalizing a member variable makes it harder to organize like that, and if you want to change logic later it is more difficult than if you had used a property in the first place.In other words, the point is more practical than functional.EDIT: Good point made by Codeka.   ;  Another reason to do it would be for growth reasons. If you know it some point you might be putting logic behind the getter/setter for validation or triggering then it's best up front to create the trivial property and use it in your code.That way in the future when you expand the code you don't need to rewrite to support the additional functionality.;Quote:That way in the future when you expand the code you don't need to rewrite to support the additional functionality.How do you mean? Given client code that uses member M (of type T) belonging to type Foo:Foo f = new Foo();f.M = default(T);that code does not need to be changed if Foo changes from:public class Foo {  public T M;}to public class Foo {  public T M { get; set; }}or indeed the other way around. It's just reflection-related stuff that does not or cannot consider fields where its an issue.   