   Private variables and accessors
  I keep seeing this in code:class MyClass{    private int MyVar;    public int MyVar    {   get{return MyVar;}   set{MyVar = value;}    }}What's the point of having a private variable if you're just going to completely expose it with accessors? Isn't this just making encapsulation redundant?   
  Yes, I think it's kind of redundant, but at the same time it makes it really clear which fields are publicly accessible and which are private, which I find kinda nice.  Plus the Intellisense gives them the same little icon.  I only wish you could initialize them, something like this:class MyClass{    public int MyVar = 42    {   get;   set;    }}Oh, and just so you know, you're going to have to change the capitalization/spelling in one of those fields in order to get that original code to compile.   ;Quote:Original post by slayeminIsn't this just making encapsulation redundant?Yes. You usually see this kind of code written by programmers who haven't grasped the essence of OO yet.   ;  1. Certain reflection features of .NET only work on properties, not public member variables.2. The programmer might want to add checks later on. (This is a rather silly reason, for various reasons, but it's the most commonly given one so I'll list it here.)3. "Because it ain't OOP unless everything's encapsulated."   ;Quote:Original post by slayeminIsn't this just making encapsulation redundant?No, encapsulation isn't just about hiding away those dangerous variables in order to maintain invariants, it's also about protecting the consumer from changes in internal implementation by providing a stable interface.Suppose we had a class called Interval with, like in your example, a get-able and set-able property called Range. One sensible implementation might be to have two private variables: start and length, in this case the Range property can simply get/set length, much like the example you gave - is this redundant?In the future the implementation might change, this time the private variables become start and end, now Range gets and sets the difference between them.An observation to be made here is that the implementation changed but the class's public signature, it's interface, remained the same, in both cases all that was publically exposed was a Range property.   ;  Don't forget "it shuts up FxCop".   ;Quote:Original post by dmatterQuote:Original post by slayeminIsn't this just making encapsulation redundant?No, encapsulation isn't just about hiding away those dangerous variables in order to maintain invariants, it's also about protecting the consumer from changes in internal implementation by providing a stable interface.Suppose we had a class called Interval with, like in your example, a get-able and set-able property called Range. One sensible implementation might be to have two private variables: start and length, in this case the Range property can simply get/set length, much like the example you gave - is this redundant?In the future the implementation might change, this time the private variables become start and end, now Range gets and sets the difference between them.An observation to be made here is that the implementation changed but the class's public signature, it's interface, remained the same, in both cases all that was publically exposed was a Range property.This is the most excellent argument in favor of redundant encapsulation. I like it.   