Things change?

Consider a trivial to-do list. You can click on the 'completed' checkbox. So the 'completed' field has chaged.

Or, you can say ooops I mistyped the label. So you change the label.

Is there anything wrong with that?

I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects.

I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".

> I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects.

I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".

I do not understand your point. First you claim that we should not mutate the field, then you claim that we should mutate the field.

Which one is it? Mutate or not?

Generally not mutate. And if we must mutate, mutate in a batch with a single method with a descriptive name.

We should generally not use goto or local variables either. Avoid reaching for these constructs first. But if it's by far the cleanest, and simplest way of solving the problem - which it usually isn't - go ahead and do it.

Let's say I have an object representing a file in the file system, and I'm writing a file browser. I give the user the ability to rename the file.

I would say that at that point, it ceases to be a simple setter method (or set property). It's not a simple case of mutating some element of a data structure of filenames as strings. There'd be some validation and error handling involved. It's a perfectly valid high level message to send a file object.

As an aside, I'd probably make a method called "rename" that does this, as opposed to something like "setName".