But Bad Programmers Will Abuse It!

I recently had an interesting argument with some collegues about the merits of properties as a language-supported construct. If you haven’t heard of the property (or “smart field”) concept before, here’s a quick intro:

A property is a class field that acts like a variable, but encapsulate get and set methods. This means that from the outside, you can do something like:

a.field = 10;

but what actually happens is that the method “field set()” runs:

public int field {
    set {
        m_field = value;
    }
}

If you want a more exhaustive look at properties there’s a good explanation of C# properties at C# Station.

Ever since my days long ago coding Visual Basic (ugh), I’ve been a fan of the property concept. In my view, it provides language support for something we do anyway — providing accessor methods for private data fields, doing away with something that breaks the natural expectation of how to do things… normally I assign a value using the assignment operator, now I have to call a set function.

Worse, without properties you’re in a situation where you have to either provide set and get methods for all fields for consistency, or start out with public data fields and be ready to change all calling code if you need to do some additional checking on the value being set. Nearly everyone goes with option 1, so we end up doing the tedious extra work of typing out default get and set methods, or using refactoring tools to write them for us. Either way, the code gets cluttered with stuff we didn’t really have a specific use for.

So coming back to the discussion we had about properties, what are the reasons that people don’t like them? The argument can basically be summed up as this: “But people can put all kinds of stuff in that method. If I assign a variable, I assume it’s only going to save a value, not do something heavyweight.”

So essentially, bad programmers will abuse the feature, thus it’s bad. Well… we already do this, it’s just not built into the language. Someone can calculate the next unknown digit of π or brute force a solution to a 1024-bit RSA key in your setField() method just as they can in the field set() method. In both cases, you’re going to expect a simple value assignment, possibly with some safety checks.

The bottom line is, no language is going to protect you from the abuse done by unskilled programmers. Funnily, the argument tends to come from coders who work primarily in C++, which must be the best language possible if you’re looking to set traps for yourself. You can do really horrible things to your fellow C++ coders using operator overloading, but that doesn’t make operator overloading a bad feature.

1 Comment

• 

  By Paul Evans, Monday, February 9, 2009 @ 9:49

  Amen (and + 1 subscription for you)

Other Links to this Post

RSS feed for comments on this post. TrackBack URI

Leave a comment