Question

In C# you can create getter/setters in a simpler way than other languages:

public int FooBar { get; set; }

This creates an internal private variable which you can’t address directly, with the external property ‘FooBar’ to access it directly.

My question is – how often do you see this abused? It seems like it has a high potential to violate encapsulation best-practices often. Don’t get me wrong, I use it as appropriate, and partial variations of it for read-only write-only types of properties, but what are your unpleasant experiences with it from other authors in your code base?

Clarification: the intended definition of abuse would indeed be creating such a property when private variables are appropriate.

Answer 1

I’ve seen it abused (in my opinion). In particular, when the developer would normally write:

private readonly int foo;
public int Foo
{ 
    get 
    { 
        return foo;
    }
}

they’ll sometimes write:

public int Foo { get; private set; }

Yes, it’s shorter. Yes, from outside the class it has the same appearance – but I don’t view these as the same thing, as the latter form allows the property to be set elsewhere in the same class. It also means that there’s no warning if the property isn’t set in the constructor, and the field isn’t readonly for the CLR. These are subtle differences, but just going for the second form because it’s simpler and ignoring the differences feels like abuse to me, even if it’s minor.

Fortunately, this is now available as of C# 6:

// Foo can only be set in the constructor, which corresponds to a direct field set
public int Foo { get; }