Calls to mutate state, such as changing the name field, should be rare. I don't see the value in adding syntactic sugar to make it easier to mutate state.
He means you'd call `increment(25)` to say you've got 25 more, or `employee.suspend()` instead of `employee.setAccess(SUSPENDED); employee.setPay(0); employee.setBenefits(NONE);`
a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.
> a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.
Yeah I want to say that for us developers, "rare" is not something that we can code, without some serious sophistication.
More likely we code "if" and it is either "yes" or no".
To capture "rare", we need some serious tools - statistics, analytics etc etc. That is way beyond the regular developer toolset.
Something like obj.rename(newName). This might seem like a trivial change, but the underlying idea is that we're no longer dealing with a setter only affecting one particular field, but an abstract message that may affect arbitrary internal state.
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?
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.
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.
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".