Earlier quoted context omitted.
Why have a mutable class to represent temperature - a simple value class with two fields? Why not just construct a new Temperature? I mean if performance was an issue, you'd just use plain doubles instead, right? I'm open to the idea that setters do have a use case, but I'm not seeing one here.
How about a class that stores temperature and the current state of the satellite? It's easy to come up with circumstances where requirements change.
class Satellite {
Coordinates coordinates;
double celcius;
/*** constructors, etc ***/
public double Celcius() { ... }
public double Kelvins() { ... }
public void Move(...) { /* modifies state */ }
}
You could make the argument that I do have a getter there, Celcius. But at the risk of pedantry I'd argue it isn't so. The name doesn't imply that it's retrieving the value of a field - ie the internal representation could easily change to Kelvin or Fahrenheit - where as "getCelcius" definitely tells me there's a field there called Celcius.
Hmm, after writing that I wonder what the definition of a setter actually is. I have no problem with a method that just returns a field, as long as it doesn't go out of its way to tell me that's exactly what it's doing. Maybe the distinction I am making is too subtle.