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.
Then I would implement it as a "real" class, not a data one.
class Satellite {
Coordinates coordinates;
double celcius;
/*** constructors, etc ***/
public double Celcius() { ... }
public double Kelvins() { ... }
public void Move(...) { /* modifies state */ }
}
Note how none of the methods make any mention of low level operations like setting/getting internal fields.
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.
Celcius is definitely a getter. The name absolutely implies that it's retrieving a value because it's name is not a verb or action.
Properties in C#, for example, really just remove the ambiguity in this exact situation. Is it object.Celcius or object.Celcius()? A good C# programmer would use the former. A method would be object.RaiseTemp().
It looks like I have a really different definition of "getter" than some people here. I would only call something a getter if it explicitly makes reference and effectively exposes an internal field. Just giving a method a noun name is not enough to make it a getter, in my mind. It's the "get" prefix that says 'hey there is definitely a field in here called Foo that we think we're encapsulating but we're really not'.
Your definition of getter and setter are way too narrow. You exclude all getXX() and setXX() methods that don't directly manipulate a field and all C# property get/set the same way.
The getter or setter is part of the public interface of the object. The public interface makes no guarantees about implementation -- encapsulation is one of the fundamental principles of OOP. It is only supposed to appear from outside that you are getting/setting some internal property of the object. And that is the simplest implementation. However, the value of encapsulation is that it really doesn't have to implemented that way. Or the implementation could change entirely as long that public interface works the same way.
> I would only call something a getter if it explicitly makes reference and effectively exposes an internal field.
I think you're original question is "Why would anyone use a getter/setter if they could just a public field?" But your definition excludes all the reasons why someone would do it! If getters/setters just exposed internal fields and never anything else then they really serve no purpose.
There simply isn't a better domain method term for moving data from one place to another than get/set. You could invent alternatives but they're just more confusing.
And even that linked comment addresses modification not retrieval. Sometimes you just want a value out of an object -- a getter.
I think understand the point that you're trying to make; the idea that an object just accepts messages that alter it's internal state but otherwise keep it completely hidden is a pervasive one. Exposing internal state can lead to coupling or violate the single responsibility principle. But that model is too simple, plenty of objects are just containers. And not dumb containers that are just bundles of simple fields but smart containers with data that isn't entirely internal.
The scenario being discussed was a class which changed its internal representation without breaking it's public api.
A getter can then by definition not simply refer to only a field anymore as that field is gone. It might have done so in the first version of the class where Fahrenhet() simply returned your fahrenheit field(a getter) but now we've removed that field and replaced it with a celcius field. That means Fahrenheit() doesn't just return a plain field anymore, there is some transformation going on. It's still considered a getter.
The concept of getters & setters exist in languages where it's not conventional to write them as methods named getX() or setX(y).
Writing the that example in C#, you'd likely have
public double Kelvins {get; set;};
public double Celsius {
get { ... };
set { ... };
}
and [modern] Javascript could have
let kelvins;
get celsius() { ... };
set celsius(c) { ... };
And you'd set both of them with [eg] s.celsius = 5. This is how getters/setter look when a language supports them.
Writing and using methods named 'getX' and 'setX' is conventional in Java because support for this feature doesn't exist at the language level, but is essentially implemented by the common IDEs. Probably not the ideal situation, but that's where Java is at.
I'm open to the idea that setters do have a use case, but I'm not seeing one here.