   [C#] Get/Set, what is it?
  I been seeing alot of code (especially in XNA) where you set up a method with get/set properties. I don't really know what it means. I looked up a tutorial on the MSDN site and that doesnt make sense to me either --all it looks like is someone physically writing out the code that Gets the value to a variable and sets what you got into the Set... which looks the same as (for example) x = 20, which gets the value of x and sets it to 20what is get/set actually doing?   
  That's exactly what it is doing. Properties provide a way to easily implement mutator methods (http://en.wikipedia.org/wiki/Mutator_method) while keeping the interface clean and familiar. For instance, if you had a range that you always wanted to be between 10 and 32, you would write...public UInt8 Range{  get { return _range; }  set { _range = Math.Max(0, Math.Min(value, 32)); }}And use it like...this.Range = 256; // Automatically clamp to 32.this.Range = 0; // Automatically clamp to 10.As opposed to just making some variable named Range public. In general OOP practice, it is a bad idea to expose variables by making them public. Properties let you expose variables to the public in a friendly interface but do your own magic behind the scenes if needed. I recommend reading the mutator method article on wikipedia that I linked above for more information on why they are handy.   ;  See: Properties (C# Programming Guide).   ;Quote:Original post by ValkoranFor instance, if you had a range that you always wanted to be between 10 and 32, you would write...Personally, I strongly dislike this. There is nothing more frustrating than having code like this:foo.value = 20;printf(foo.value);// prints 4Quote:In general OOP practice, it is a bad idea to expose variables by making them public.It's much better to just be explicit:foo.setClampedValue(20);// orfoo.tryAndSet(20);// orfoo.setClamped(value, 0, 20);or similar.Getters and setters are sadly a concept which is obsolete, yet sadly found abundantly in C# and Java, as well as Delphi.Most of the time, if setters/getters are non-trivial, they should be used to augment the expected functionality, not modify it. Perhaps log data, write to database or such, but retain the expected behavior of set/get.   ;Quote:Original post by AntheusPersonally, I strongly dislike this. There is nothing more frustrating than having code like this:foo.value = 20;printf(foo.value);// prints 4that would confuse me so much its retarded, tbh even if it printed 20 i still dont see why you would use get/set to setup a simple variable... i'm still learning this stuff (on my own, not going to school for this) and its confusing why people wont set up a class to get the variables you want, or just explicitly set a value to a variablelike i said that MSDN tutorial really doesnt help :/ its using so much math just to get the value u pass into the property, just to set it at the value you originally put into the property, wtf? (http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx)   ;Quote:Original post by Stuart_Mastrgamrits confusing why people wont set up a class to get the variables you want, or just explicitly set a value to a variableBecause for 20 years, people have been mindlessly hammered into obedience by teaching them that encapsulation is good.Encapsulation *is* good, but since majority of software written is CRUD applications built on top of ORM libraries, setters/getters had to be invented to keep what is plain data that should simply be public properly "encapsulated".There are vague arguments that it protects from code changes, but reality is that unit testing, automated refactoring in IDEs and similar techniques make that point moot.It's just the way C# and Java worlds work. Too much cargo cult, but desperately needed in lowest bidder business world. So keep writing properties just in case someone else sees your code, since they will likely start whining about lack of "proper OOP".   ;Quote:Original post by Stuart_Mastrgamrlike i said that MSDN tutorial really doesnt help :/ its using so much math just to get the value u pass into the property, just to set it at the value you originally put into the property, wtf?It's not the greatest example, admittedly. Properties have several advantages over fields - you could add code to the setter to fire an event to indicate that the property has changed or you could make the getter public and the setter private to make it effectively read-only to anything outside that class, for example. Changing a field into a property at a later date changes the class definition and may cause versioning problems down the line (for example, you can't use a property as a ref or out parameter) so it's generally recommended to not expose public/protected fields. Properties are also understood as being, well, properties of the object and the .NET class library has been designed with that in mind (see the PropertyGrid control or XmlSerializer class, for example, both of which deal with reading and writing properties).   ;  Not everything needs a property but that doesn't mean all properties are useless. A few examples:// an externally readonly value that can// be modified by this class and subclassespublic int Foo{  get { return foo; }  protected set { foo = value; }}// an angle that makes sense to wrap so// we don't get into floating point// precision issues from lots of rotationpublic float Rotation{   get { return rotation; }   set { rotation = MathHelper.WrapAngle(value); }}// properties can return something that// isn't even a field but has access that// looks like it.public Matrix View{   get { return Matrix.CreateLookAt(position, target, up); }}There are merits to properties and there are cases for just making fields public; it's all up to the developer(s) of a piece of code to decide on.   ;  Properties can also be used polymorphically (and can be defined in interfaces).  This is extremely handy in certain cases.   ;Quote:Original post by AntheusQuote:Original post by ValkoranFor instance, if you had a range that you always wanted to be between 10 and 32, you would write...Personally, I strongly dislike this. There is nothing more frustrating than having code like this:foo.value = 20;printf(foo.value);// prints 4Quote:In general OOP practice, it is a bad idea to expose variables by making them public.It's much better to just be explicit:foo.setClampedValue(20);// orfoo.tryAndSet(20);// orfoo.setClamped(value, 0, 20);or similar.Getters and setters are sadly a concept which is obsolete, yet sadly found abundantly in C# and Java, as well as Delphi.Most of the time, if setters/getters are non-trivial, they should be used to augment the expected functionality, not modify it. Perhaps log data, write to database or such, but retain the expected behavior of set/get.While I tend to agree with you, I do not believe that it would be a problem in many contexts. The example that I provided was purely that; an example. Perhaps a better example would be a floating point alpha value, which is typically 0.0f - 1.0f. Surely the following wouldn't be frustrating?foo.Alpha = 20.f;Console.WriteLine(foo.Alpha.ToString()); // Print 1.0f;Personally, I would be more concerned over the fact that the simple interface could hide the fact that something potentially expensive is going on in the background. Someone is probably more likely to use foo.Value more carelessly than foo.ConnectAndGetValueFromDatabase().   