Should I use a Field or Property within the class to set values

Question

So I got into a friendly argument with a co-worker over a piece of code:

public sealed class NewObject
{
    private string _stuff = string.Empty;

    public string Stuff
    {
        get { return GetAllStuff(); }
    }

    private string GetAllStuff()
    {
        //Heavy string manipulation of _stuff
    }

    public NewObject(string stuffToStartWith)
    {
        _stuff = stuffToStartWith;
    }

    public static NewObject operator +(NewObject obj1, NewObject obj2)
    {
        if (obj1 == null)
            throw new ArgumentNullException();

        if (obj2 == null)
            throw new ArgumentNullException();

        NewObject result = new NewObject(string.Empty);
        result._stuff = String.Concat(obj1._stuff, obj2._stuff);

        return result;
    }
}

The argument was over the operator override. My co-worker feels that it's not best programming practice to set values of private fields anywhere but the constructor. The solution proposed by my co-worker was to refactor the name of the Stuff property to AllStuff and add a property, Stuff, that has a get AND set accessor and use the new Stuff property in the operator override. Making it look like this:

    public static NewObject operator +(NewObject obj1, NewObject obj2)
    {
        if (obj1 == null)
            throw new ArgumentNullException();

        if (obj2 == null)
            throw new ArgumentNullException();

        NewObject result = new NewObject(string.Empty);
        result.Stuff = String.Concat(obj1.Stuff, obj2.Stuff);

        return result;
    }

I disagree. I feel the first way is better since it keeps the property read-only outside the class. My question is, which way is the best practice for object-oriented design?

Answer 1

You could give yourself a private set on the property (which would retain visibility or lack thereof while allowing you to use property syntax), but that doesn't really address the point.

Within the class, I say that variables are fair game. Anywhere outside, including inherited classes, should get and set the property, but within the declaring class I say it's OK to assign the private member.

Answer 2

You're right

err... to elaborate, your private variables are yours to do as you please. If someone does an operation on you that changes the value of the object, (especially something like +), theres nothing wrong with modifying the value outside of the constructor. Thats the whole point of them being private.

Unless you want it immutable...

Update
The more i think about it, the more I believe your co-worker is confusing 'private' variables with 'constant' ones - or perhaps merging the two concepts. There is no reason that private variables have to remain the same throughout the life of the object, which is what your friend seems to be implying. const is for unchanging, private is for the object only, they are two very distinct patterns.

Update2
Also, his design falls apart if suddenly your object has more than just a string - and the variables are intertwined (think of a string object, that has a char* and a len, and must be maintained together). The last thing you want is for the user to have to deal with internal variables of an object. Let the object be an object and maintain its own internal values and present a single entity to the user.