4 ms·

It would probably look exactly like setName(newName). For me a better question is - why is the name being changed? What high level goal are you trying to accom

It would probably look exactly like setName(newName). For me a better question is - why is the name being changed? What high level goal are you trying to accomplish that truly needs you to to directly mutate internal fields, after the object has already been created? Could the object - or system of objects - have been designed with a higher level interface, so that the outside world didn't have to concern itself with such things?

st3v3r 10y ago
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.
- lacampbell 10y ago
  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".
carterehsmith 10y ago
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?
- lacampbell 10y ago
  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".
  - carterehsmith 10y ago
    > 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?
    - lacampbell 10y ago
      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.

st3v3r 10y ago

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.

lacampbell 10y ago
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".

carterehsmith 10y ago

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?

lacampbell 10y ago
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".
- carterehsmith 10y ago
  > 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?
  - lacampbell 10y ago
    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.