I think the best takeaway from the “Doing it wrong…” post is that exposing public accessors without a good reason breaks encapsulation by giving external classes the ability to modify and inspect state that ought not be made public. It’s just expressed in an absolutist fashion (I’d argue if you have a Contact object, and want to put that contact’s name on a label for an address book application, at some point Contact will probably have to expose its name to another object). Regardless, no matter what the language, making accessors available without thought is going to break encapsulation and lead to tight coupling.

This is orthogonal to the best practice in Objective-C of using accessors for all (at least most) instance variable access. No where does Objective-C recommend making all your accessors publicly visible. Often you will have a class extension visible only to the class’s own implementation that defines most of its instance variables and then the class’s own implementation uses the accessors. And certainly, external code should always use the accessors – but they still should only be made visible to external code if absolutely necessary.

Setters and getters are the technology that came from visual basic properties in 1980’s. Since they’re often used together with the programming techniques that also come from same place, it’s considered bad practise. Problem with getters and setters is that the behaviour of the class gets moved to the user of the class, and class no longer handles it’s own behaviour; but supports any behaviour possible. This does not create a good class, since it’s not doing the decisions that are normally part of class’ responsibility.

As a C# developer, I use getters/setters all the time. Since I rarely (but still do) use C++, I might could offer a different perspective on this one.

To my eye, the bulk of difference of acceptability between C++ and C# has been due to conventions between users of a language (though there are others I’ll get to later…). Most of the time in C++, I just don’t need to use a getter/setter because it is not encouraged to do so. Unlike the blog post, I don’t even view it as a matter of ‘right way to code’ or ‘wrong way to code.’ It’s a convention that allows other humans to make heads or tails of what I’ve written/maintained.

C# does not mitigate that need, and as far as I’ve seen, there’s no evidence to say that getters/setters in C# are any more or less peformant than methods in C++ (I would assume they’re on roughly the same order, but that’s a gut feeling, there.) Yet, the general feeling in the C# community is that, while methods are preferable, properties are great for taking methods like:

public string GetName()
{
    return _lastName + ", " + _firstName + " " + _middleInitial;
}

public string SetName(string fullName)
{
    // Assumptions are made here; this is just example code!
    string[] frags = fullName.Split(' ');
    _firstName = frags[0];
    _middleName = frags[1];
    _lastName = frags[2];
}

and creating a slightly ‘shorter’, different, but reasonably readable syntax like:

public string Name
{
    get { return _lastName + ", " + _firstName + " " + _middleInitial; }
    private set 
    {
        string[] frags = value.Split(' ');
        _firstName = frags[0];
        _middleName = frags[1];
        _lastName = frags[2];
    }
}

You could say that to a C# or Java programmer, we view properties as syntactic sugar for simple methods, since that’s all a getter/setter really is: a method.

Another wrinkle in the technologies lies in various frameworks. For instance, in my current shop, our MVC projects are set up such that we’re more or less required to use getters and setters by NHibernate and the MVC framework itself. We’ve had conversations about the perceived overabundance of properties in our app, but in the end we had no technical recourse to revise those to simple methods. We have to use properties because reflection is used to retrieve properties, and thus their contents. Our code would be bigger and nastier without them, so no one really complains all that much.

To finally answer your question, though, I think that dives to the heart of the matter.

A C++ programmer expects to need the deep technical details of a given operation; instead of obscuring this machination with syntactic sugar, it’s more understandable to just bite the bullet and do the work. It’s not that C++ programmers are averse to syntactic sugar at all (in fact, I find myself yearning for better ways to express my C++ code when I use it…), but the things you turn to C++ for and the things you use properties for typically don’t mesh well on a practical level*.

A C# or Java programmer is taking advantage of the virtual machine interposed between the physical layer and our high-level code; we lose little by utilizing the syntactic sugar, and in return gain (slightly) improved readability without wholly violating encapsulation…providing the getters/setters are implemented correctly. The things you turn to C# or Java for do mesh well with properties on a practical level.

*: Note that I’m not a frequent C++ user! I beg for correction, if anyone has any to give.