views:

197

answers:

4

If I have a simple class setup like this:

class MyClass
{
    private string _myName = string.Empty;

    public string MyName
    {
        get
        {
            return _myName;
        }
    }

    public void DoSomething()
    {
        // Get the name...
        string name = string.Empty;

        name = _myName;

        // OR

        name = MyName;

        // ...and do something with it...
    }
}

Which should I use, the public property, or the data member?

Obviously, in this example it doesn't make a difference, since they both just reference the same variable. But what about real world uses of Public Properties?

In general, do Public Properties perform very little, in which case it is OK to call them? Or do people put a lot of functionality into their Public Properties that should not be called by internal class references?

I saw something in another post about NOT putting lots of functionality into Properties, since examining them in the Debugger can perform unexpected results. Is that true?

+5  A: 

Use the property - any logic that may be encapsulated within the setters and getters ought to apply, even within the class itself. If there is no logic within the getters and setters it is still not safe to use the fields themselves because if at any point you wish to add logic around the access to those fields you will have to refactor much more.

Andrew Hare
perfect answer.
Stan R.
A: 

If I'm just returning the value of the internal variable, I make the variable public - there's no harm to doing so. I've always used Public Properties when I want to do something in response to either a viewing or a changing of the value - ie, write it to a database, set something else too (as in the second part of your example).

The question you have to ask is whether you want what happens inside your class to trigger these events. If you do, the same way an external caller would, then access the values via the property. If you just want to read the value, use the internal variable.

To answer your question, there's no harm to doing it either way - just consideration of the potential side-effects.

rwmnau
Public fields are a bad idea. They are an exposure of the class's state which breaks encapsulation. Why is this a bad thing? What happens when you want to add logic around the getting or setting of that field? You cannot do this since you have exposed the field itself.
Andrew Hare
Why couldn't you later convert the public field to a Property if you needed to add some logic? It just always seemed unnecessary to me when somebody uses a public property and doesn't need to - it seems like it would just add extra overhead. At least in VB, there's no quick "get-set" syntax, so making it a property seems to involve more code than it's worth. I'm happy to be wrong though, so fill me in!
rwmnau
+4  A: 

I believe that you should reference the property as a general practice. While in this particular example it really doesn't make much of a difference, the get/set accessors offer the ability to do a bit more work when grabbing a property. For example, many of our property "get" accessors perform some lookup within a more complex data structure or set default values if nothing has been defined. So that the rest of the class can take advantage of this logic, we make a habit of using the properties. Just so we don't have to think too hard about it, we try to generalize the practice.

There may be instances in which we want to directly access the underlying data member, but then that is a conscious decision with a specific reason and it tends to be the exception.

James Conigliaro
+2  A: 

I prefer properties because they easily handle read-only situations and it's easy to wrap them with any basic validation you might need to do.

Keith